Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[feature]: Single-screen login fast-path when password is the only enabled auth method

Open
  • Is something wrong?
#9,740 1 comment 0 reactions 2 assignees View on GitHub

Maintainers usually reply within 1 day

@vihar is already working on this.

Since Sep 2, 2026.

Assessment

This issue has not been assessed yet.

Description

✨feature plane
Is there an existing issue for this?
  • I have searched the existing issues
Summary
Summary

When an instance has only email+password enabled (magic login off, no OAuth providers), the identifier-first flow — email screen → backend emailCheck → password screen — adds a roundtrip and a screen for a decision that has exactly one outcome. Render email + password on one screen in that case.

Current behavior

auth-root.tsx always starts at EAuthSteps.EMAIL, submits the email to the emailCheck endpoint (auth.service.ts), and only then routes to EAuthSteps.PASSWORD / UNIQUE_CODE and SIGN_IN / SIGN_UP. This branching exists to pick between password, magic-code, and OAuth. On an instance where password is the sole method there is nothing to branch on, yet users still pay:

  • an extra network roundtrip and a second screen/click on every login;
  • flaky password-manager autofill — the password field isn't in the DOM at page load, so Bitwarden/1Password can't do a standard single-shot fill (see the companion autocomplete-token issue);
  • account enumeration: the emailCheck response distinguishes existing vs non-existing users before any credential is supplied, which lets an unauthenticated caller enumerate valid accounts. A combined email+password screen that returns a single generic "invalid email or password" removes that oracle.
Proposed behavior

Keep identifier-first whenever more than one auth method is enabled (magic-code and/or OAuth) — that's where it earns its keep. When the instance config exposes password as the only method (is_email_password_enabled === true && is_magic_login_enabled === false and no OAuth providers), render a single classic login form: email (autocomplete="username") + password (autocomplete="current-password") together, submitting directly.

This is:

  • backward compatible — multi-method instances are unchanged;
  • config-driven — decided from the same instance config auth-root.tsx already reads;
  • a security improvement — no pre-credential existence oracle on single-method instances.
Why should this be worked on?
Rationale

Self-hosted single-tenant instances are the common case, and many run password-only. For them the identifier-first machinery is friction with no upside: worse UX, broken autofill, and a user-enumeration surface. Gating it on "more than one method enabled" preserves the flexibility where it matters and drops the cost where it doesn't.

References
  • Companion bug #9739 : autocomplete tokens on auth inputs (autocomplete="off" from #8517 breaks password managers / fails WCAG 1.3.5)
Dominant language
TypeScript
Stars
60.7k
Forks
6k
Avg merge
1d 9h
Merged PRs (30d)
56

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from makeplane/plane

All issues in makeplane/plane

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.