Ability to log in using email address and user name request

[kiwimind]

I've just tried to log in to the back end of a Wagtail site and couldn't remember the exact credentials.

The forgot password helped out with that side of things, but I was then unable to log in using my email address.

If a user has forgotten their username, there is currently no way of logging in, as the email address is not (always) the username and there is no functionality to send a user their username by email.

In order to improve the login experience, users should be able to:

a) log in using their email address as well as their username
b) request their username be sent to their email address

[jsma]

I think the simplest way to resolve this issue is to make sure the forgot password email includes the value of USERNAME_FIELD which with classic Django User model would be your 'username' or with a custom user model might be your 'email'. This is how Django handles it with their email template. I have no idea wagtail overrides this email template instead of leveraging the one provided by Django, I'd vote to just remove Wagtail's version and go with Django's. Problem solved.

I'm not a core developer but I'm strongly -1 on (a) as this would make the authentication code a lot more complicated. Also, with classic Django User models, there is no guarantee of uniqueness on email. For example, you might have an admin account username, a 'regular' account username, etc. but using the same email address across all accounts, so there would be no way to clearly so in this case it would be unclear which username to send to the user at their email address.

Not only is there no guarantee of email uniqueness with classic Django User, there's actually no guarantee users will even have an email address in the database at all since this is not required by default in Django.

[thenewguy]

Keep in mind, you are not restricted to using the authentication that ships with wagtail. For example you could use something already available like django-allauth to allow social and/or local accounts.

[davecranwell]

I'm in favour of a). Wagtail's USP is it's friendliness and usability and I don't think we should be discounting valuable improvements in UX purely due to the complexity involved in the development.

[tmsndrs]

+1 Dave's comment

"Remembering an email address is easier than remembering a user name. User names can be unwieldy, and people remember their email address because they use email all the time. Give users the option to log in with their email address as well as a user name. The flexibility could save them the time and headache of recovering the user name if they forget it."

One of Wagtail's key offerings is hiding complexity from editors in favour of good UX.

What ships with Wagtail should reflect best UX practise.

[nealtodd]

@davecranwell don't forget that allowing login by email address means that you're effectively cutting your ties to the ability to have multiple accounts using the same email address (which can be a highly desirable requirement in some applications and/or Wagtail implementations). At least, not without some shim where you'd have to specify which account you want to log in to (and be sharing the password between them).

[davecranwell]

In what scenarios would you have multiple logins with the same email address? One I can think of is where a high-powered user is testing how something looks between two different roles, which seems like an edge-case. I'm struggling to think of a situation which isn't actually a sort of developer hack and which might apply to "ordinary" users.

In a duplicate email condition, one possible solution would just be a message stating "multiple accounts exist with that email address, please sign in with username instead". Given the kinds of user most likely to encounter it, I doubt it would be too much of a hurdle.

[gasman]

We basically can't make any assumptions whatsoever about the presence or uniqueness of email or username fields, because we need to support custom user models defined through AUTH_USER_MODEL too: https://groups.google.com/d/msg/wagtail/e8QzumWpfGQ/PSiD_R8C_ZkJ

(That doesn't mean we shouldn't try to provide the most intuitive / friendly setup out of the box, of course - but any solution we come up with has to account for alternative setups.)

[nealtodd]

One person wanting to behave differently (different roles/configuration) in different accounts but have all comms going to the same email address isn’t all that unusual (inside reference: you installed an application that supports that yesterday :), definitely not just a developer edge-case (although that is of course a common case, easily handled if your mail provider supports something like the ‘+’ convention).

I guess what I’m getting at is that it’s hard to second guess the requirements of all the potential Wagtail implementers, so if you default to how Django does it out-of-the-box then you’re a) less likely to confound expectation and b) not having to maintain a customised approach.

Doing a customisation as a contrib package might be a way to go though, to give an implementer the option of log-in-by-email (almost-)out-of-the-box?

On 27 Feb 2015, at 12:28, Dave Cranwell [email protected] wrote:

In what scenarios would you have multiple logins with the same email address? One I can think of is where a developer is testing how something looks between two different roles, which seems like an edge-case. I'm struggling to think of a situation which isn't actually a sort of developer hack.

In a duplicate email condition, one possible solution would just be a message stating "multiple accounts exist with that email address, please sign in with username instead". Given the people most likely to encounter it, I doubt it would be too much of a hurdle.

—
Reply to this email directly or view it on GitHub #722 (comment).

[davecranwell]

+1 for contrib package

[m-sanders]

Opinions as a soon-to-be-user who needs custom user model support and is keenly following this discussion.

I see myself working with Wagtail in conjunction with existing Django apps, most with their own user model. It will manage content and delegate to our existing libraries/apps. I have some quite strong opinions on what should be provided with Wagtail.

Wagtail should work out-of-the-box with django.contrib.auth.models.User. It must honour the contract of AbstractBaseUser and PermissionsMixin and should not rely on any implementation details of django.contrib.auth.models.User. A consumer of wagtail can then rely on the Django docs, 3rd party libraries and any of their existing code; all in the knowledge that they can integrate with Wagtail for its excellent CMS. Wagtail should not provide login as email as it is not unique out-of-the-box with Django.

Furthermore, If Wagtail is to provide a contrib package for auth related features, how far should it go? If it is just to add the email login then it isn't really bringing that much to the table. Also if I am going to alter auth or implement a custom user model I have already committed to implementing the various parts, just like with any other Django app. A wagtail.contrib package would just be duplicating effort on something that isn't content and adding its own opinions. I am not a fan of what I consider to be unnecessary bloat and feature creep. This fits in with the FAQ of 'Why doesn't Wagtail do X?'. Maybe a 3rd party package makes more sense, where it can be opinionated on authentication with Wagtail.

I would just add the value of USERNAME_FIELD to the e-mail. This covers the issue to some extent and how often do users really forget their usernames?

[thenewguy]

Why not use a 3rd party app that already covers all use cases instead of reinventing the wheel? I am currently using django-allauth with a custom user model with wagtail and it works well. https://github.com/pennersr/django-allauth It supports local and social accounts and allows multiple authentication techniques to be linked to a single user account. It has many configuration options which allow the authentication and user requirements to be tuned to business requirements.

[thenewguy]

Sorry for the duplicate post. I just saw I made this recommendation last year in earlier comment thread

[davecranwell]

Thanks for the feedback everyone, It's clearly an issue we need to treat with care.

On the one hand is the need for Wagtail to be un-opinionated, easily installed and interoperable with other auth systems. On the other, is the need for Wagtail to maintain a market position of providing the best experience for users who aren't developers. As Wagtail is used by several agencies now there are growing numbers in both groups.

We'll discuss this at our next meeting.

[tmsndrs]

Relevant article on designing a login process https://www.gosquared.com/blog/login-screen-design-flow

[chimeno]

IMHO, a good option would be:

1. Provide the default base installation as it is now,
2. Help developers that needs custom user model via code or 3rd party apps.

My case is trying to set up with Google Apps oAuth but didn't find the way after trying several times.
So a more customizable login with a basic default would be nice.