[GH-ISSUE #727] [FEATURE] Allow logging in with email instead of username #262

New issue

Open

opened 2026-02-27 08:16:13 +03:00 by kerem · 3 comments

kerem commented

2026-02-27 08:16:13 +03:00

Owner

Originally created by @Cherryblue on GitHub (Nov 1, 2023).
Original GitHub issue: https://github.com/lldap/lldap/issues/727

Originally assigned to: @Copilot on GitHub.

Steps to reproduce :

I'm creating an account for a friend. He does know his own email, but not the ID I'll be giving him.
He is using the function "forgot your password ?", which accepts either ID or email
He gets the mail and token url, uses it, sets a new password for his account (whose ID he still doesn't know)
He then wants to connect. But connecting with his email doesn't work ; he has to put the ID this time

If email is defined, and is already used for creating the email token, why not allow its use to connect ?

We should expect having the same behavior for connection form and forgotten your password form.
Or at least, signaling to the user that using an email address for login is not accepted.

Originally created by @Cherryblue on GitHub (Nov 1, 2023). Original GitHub issue: https://github.com/lldap/lldap/issues/727 Originally assigned to: @Copilot on GitHub. Steps to reproduce : - I'm creating an account for a friend. He does know his own email, but not the ID I'll be giving him. - He is using the function "forgot your password ?", which accepts **either ID or email** - He gets the mail and token url, uses it, sets a new password for his account (whose ID he still doesn't know) - He then wants to connect. But **connecting with his email doesn't work ; he has to put the ID** this time **If email is defined, and is already used for creating the email token, why not allow its use to connect ?** We should **expect having the same behavior for connection form and forgotten your password form**. Or at least, signaling to the user that using an email address for login is not accepted.

kerem added the

labels

2026-02-27 08:16:13 +03:00

kerem commented

2026-02-27 08:16:14 +03:00

Author

Owner

@thielj commented on GitHub (Sep 4, 2025):

This is normally implemented on the LDAP client side, by searching both the username and the email. Authelia for example uses these defaults for LLDAP: "(&(|({username_attribute}={input})({mail_attribute}={input}))(objectClass=person))"

github.com/authelia/authelia@6601a20748/internal/configuration/schema/authentication.go (L350)

@thielj commented on GitHub (Sep 4, 2025): This is normally implemented on the LDAP client side, by searching both the username and the email. Authelia for example uses these defaults for LLDAP: "(&(|({username_attribute}={input})({mail_attribute}={input}))(objectClass=person))" https://github.com/authelia/authelia/blob/6601a20748eb3cfc85352f8ae03d99c58fd24f99/internal/configuration/schema/authentication.go#L350

kerem commented

2026-02-27 08:16:14 +03:00

Author

Owner

@nitnelave commented on GitHub (Sep 4, 2025):

@thielj I think @Cherryblue means in LLDAP's web UI, not through LDAP.

@nitnelave commented on GitHub (Sep 4, 2025): @thielj I think @Cherryblue means in LLDAP's web UI, not through LDAP.

kerem commented

2026-02-27 08:16:14 +03:00

Author

Owner

@nitnelave commented on GitHub (Sep 4, 2025):

We need to modify the backend, when receiving a login request, try to interpret it as a username and fallback to an email if there are no matches.

@nitnelave commented on GitHub (Sep 4, 2025): We need to modify the backend, when receiving a login request, try to interpret it as a username and fallback to an email if there are no matches.