[imanimanyara]

Summary

Password login read the email input and looked the account up on the email column, so an
account that signs in with a username could not sign in at all. This names the columns instead.

// config/laranail/authkit.php — the shipped default
'login' => [
    'field'       => 'email',
    'identifiers' => ['email'],
],

Add 'username' to identifiers to accept either. field is the request input the identifier
arrives in; it stays email so existing forms and API clients are untouched.

The open design decision, closed

The issue asks whether username login should be an independently enabled feature or a configurable
email-or-username identifier. It is a configurable identifier.

A separate feature flag means a second login path — its own action, request and controller — kept
in step with the first for ever, and an abstraction whose every branch has exactly one
implementation. One path reading an ordered list is the plain version, and email-only remains the
default either way.

Three things worth reviewing

Validation is derived from the identifier list, not configured beside it. With email alone the
identifier is still validated as an address — byte-identical to before. Any wider set drops that
rule, because a username is not an address and validating one as an address rejects every username
before the lookup runs. Deriving it means a rule cannot describe a mode the lookup does not
implement.

The lookup is one single-column query per identifier, not one or query. EloquentUserProvider
would accept a closure credential expressing the or, but DatabaseUserProvider and any provider
an application has substituted need not — and going through the provider at all is pointless if the
call only works for one of them.

The password is checked per candidate, not only against the first row found. Nothing stops one
account's username from equalling another's address; checking each candidate keeps the username's
owner able to sign in, and makes a failed attempt cost the same number of hash comparisons whichever
column the identifier belongs to.

Who owns the column

The application. AuthKit resolves whatever user model is configured and does not own the users
table, so it ships no migration for one — adding username, its uniqueness constraint and its
registration validation is the application's job. That is the question the issue asks to be
documented, and it is now in docs/login.md.

The test harness adds the column in workbench/, not in a package migration, which makes that claim
executable: if the package ever started depending on a column it does not create, the suite would be
the only place that column existed.

CheckEmailExists is deliberately not widened — answering it for usernames would add a
username-enumeration surface nothing here asks for.

Verification

Suite	91 passed, 195 assertions (10 new)
laranail-pint --test	passed
Coverage asked for by the issue	email login, username login, unknown identifier, throttling — all present

Proven red before being relied on, three separate ways:

Break	Result
Hardcode the lookup back to the email column	2 failed
Always validate the identifier as an address	1 failed
Widen the shipped default to ['email', 'username']	3 failed
Restore	10 passed

Nothing renames. AttemptEmailPasswordLogin, its request, its interface, its abstract controller
and FindUserByEmail keep their names and behaviour; only the identifier set widens, and only when
configured. Renaming five public classes is a separate decision and would make this diff
unreviewable.

Closes #65.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota. Try requesting a review at a lower effort level.