question: how to write username-or-email login field?
See original GitHub issueI see that we can use SECURITY_USER_IDENTITY_ATTRIBUTES
to set the identity attributes to something like ['email', 'username']
, but how do I render this for the login form? If I use the default template which defaults to ‘email’ I’m not able to use ‘username’ there, (“no such user”), so how do I utilize the USER_IDENTITY_ATTRIBUTES feature?
Issue Analytics
- State:
- Created 4 years ago
- Comments:9 (5 by maintainers)
Top Results From Across the Web
email field or username for logging in an application?
Neither is universally better, but you don't have to choose. Use both. It's trivial to test whether an input field is an email...
Read more >php - Fill in the login field with your username OR email
First when you post the form with 2 fields try to validate if input given is of type email or not; Here is...
Read more >How to Write Test Cases For a Login Page (Sample Scenarios)
Test Cases for Gmail Login page ; 1, Enter the valid email address & click next. Verify if the user gets an option...
Read more >Create a username - Gmail Help - Google Support
Create a username ... If you see "Username not allowed" when you sign up for your Google Account or Gmail, follow these guidelines....
Read more >Username and password authentication - QuestionPro
To enable username/password for authentication: Go to: Login » Surveys (select a survey) » Edit » Settings. Under Settings, you will see three...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Sounds like you have a good handle on the issues. Of course maintaining backwards compatability should always be on our mind. What I have done is - if a change would cause someones existing app to fail - then I either: a) add a new config variable to ENABLE it or b) if I think the new implementation should be the default, add a config to TURN OFF the new feature.
I like b) better since down the road (such as a 4.0) we can remove these old ‘disable’ flags…
The rendering of the form happens at request time - so I don’t see the issue - at that point you have app/request context and can make decisions based on app.config[].
As for naming - will take some thought - of course, given the current implementation - you COULD leave the field name ‘email’ and simply change the label/placeholder - but that would probably annoy password managers. Not sure how twitter works with password managers - it’s possible that the “session[username_or_email]” actually changes the form input name???
So - sure - take your time - lets communicate - put up an early PR (and label it WIP - work in progress) and we’ll go from there.
I have a PR that basically solves this by adding an entire new generalized login feature - which not only solves this problem but also add additional ways (SMS, authenticator) to authenticate.
Still interested in any comments/suggestions and of course documentation ideas.