Ticket #13419 (closed PLIP: fixed)
Improvements for user ids and login names
Reported by: | maurits | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | 5.0 |
Component: | General | Version: | |
Keywords: | Cc: |
Description (last modified by maurits) (diff)
Proposer: Maurits van Rees
Seconder: Sean Upton
Motivation
Since Plone 4.0 you can configure Plone to allow users to login with their email address, using a setting in the Security control panel. This works fine out of the box, but some improvements can be made. There have been reports of problems with people trying to login with a mixed case email address. In collective.emaillogin (Plone 3) some changes have been done to make sure login names are always lowercase and that you can still login with lower or mixed case. No problems have been reported for a client of Zest Software that uses this, so that seems to work well and could be used in Plone 4.
Currently, when the email address is used as login name it is also used as user id. There is some discussion about whether that is good. The user id and therefore the email address is then shown in a few spots, like the url of the author page. Also, some valid email addresses cannot be used as user id. See ticket #11616. The user id need not be the same as the login name. We think it is better to create a user id based on the fullname or as a uuid.
There can be various considerations for deciding on a scheme for user id and login name. We want to make the code that decides this more pluggable, so integrators can use their own scheme or maybe site admins can choose a non-default strategy with a checkmark.
Assumptions
Proposal & Implementation
- We propose to automatically store lower case login names when email is used as login. Logging in with a mixed case login name will also work: the supplied login name will be lowercased before being compared to the stored login name. This will be based on functionality recently added to Products.PluggableAuthService, which was specifically added for this use case. An admin could also enable lowercase login names when not using email as login, by setting the login_transform method of acl_users/source_users to lower, but we do not expose that possibility in the Plone UI.
- We propose the following upgrade step for existing Plone sites: if email as login is already used in the site, we set login_transform to lower. This updates the existing login names. Note that this could give an error and quit the installation. Maybe we want to catch this and just log a warning.
- We propose to create a user id based on the given fullname when email is used as login. You get user ids like maurits-van-rees or maurits-van-rees-1 when the fullname is 'Maurits van Rees'. Existing user ids are not changed.
- We propose to add a setting in the Security control panel: use uuid as user id, by default False. When switched on, a uuid is generated as user id, regardless of whether email is used as login or not. We do not propose to switch this on by default, but a separate PLIP to that effect would become a trivial code change.
- We propose to introduce a utility that is queried to provide a user id. When such a utility is found, the generated user id is taken instead of the default user id. Note that the new 'use uuid as user id' setting would be ignored when such a utility exists. Plone does not register such a utility itself.
- We propose to introduce a utility that is queried to provide a login name. When such a utility is found, the generated login name is taken instead of the default login name. Plone does not register such a utility itself.
Deliverables
Updates to plone.app.users (mostly registration), plone.app.controlpanel (the security panel), and smaller changes in Products.CMFPlone (simplified set_own_login_name method) and plone.app.upgrade (migration code).
Documentation about the new features and behavior.
Progress
Products.PluggableAuthService (PAS) has gotten the necessary changes to support lowercasing login names. This is now released in version 1.10. I have updated plone-coredev 4.2 and 4.3 to use this.
A minor update to PlonePAS has already been done, so the mutable_properties plugin has two new methods, required by the updated IUserEnumerationPlugin interface in the new PAS. In the case of PlonePAS they do absolutely nothing. This avoids a warning by PAS when updating login names.
A temporary package collective.emaillogin4 has been created that has the needed patches. They simply need to be merged back to core Plone. This package can be used in current Plone 4.1, 4.2 and 4.3 for those eager to use it. You need to pin the new PAS version if you want it. Maurits has just released version 1.0 of this package. See PyPI and github.
Note that this package explicitly enables email as login name. This would not be done when merging this package back to core Plone.
For reviewing this PLIP, I propose to simply add collective.emaillogin4 to the plip config, as that has all the patches neatly separated by package, including updated tests.
Risks
For the upgrade step: when setting login_transform to lower all the existing login names will get lowercased. This could result in duplicates, which is an error and will quit the migration. Maybe we want to catch this, revert the already done login name changes, and just log a warning.
Participants
Change History
comment:1 Changed 3 years ago by maurits
- Type changed from Bug to PLIP
- Version 4.2 deleted
- Component changed from Unknown to General
- Milestone changed from 4.x to 4.4
comment:2 follow-up: ↓ 4 Changed 3 years ago by seanupton
Note: any migrations should also update local roles recursively. The trick here is that this very expensive to walk big sites for this purpose. We may need to explore optimizations for walking and updating __ac_local_roles__?
comment:4 in reply to: ↑ 2 Changed 3 years ago by maurits
Replying to seanupton:
Note: any migrations should also update local roles recursively. The trick here is that this very expensive to walk big sites for this purpose. We may need to explore optimizations for walking and updating __ac_local_roles__?
That would only be needed if we change existing user ids, which we do not. The user id changes are only for new users.
Thanks for seconding!
comment:5 Changed 3 years ago by maurits
I have added a plip config in the 4.3 core-dev buildout: https://github.com/plone/buildout.coredev/blob/4.3/plips/plip13419-userid-loginname.cfg
comment:7 Changed 3 years ago by maurits
- Description modified (diff)
Note in progress that Products.PluggableAuthService 1.10.0 has been released (today).
comment:8 Changed 3 years ago by gyst
PLIP 13419 Improvements for user ids and login names ====================================================
PLIP ticket: https://dev.plone.org/ticket/13419
Reviewed by Guido Stevens (guido.stevens@…, gyst on irc)
This PLIP was reviewed in a Ubuntu 12.10 (Precise) chroot using Python 2.7.3 and Firefox/Chromium.
Review steps
- Ran the plips/plip13419-userid-loginname.cfg buildout
- Examined the collective.emaillogin4 code
- Ran bin/test -m collective.emaillogin4 --coverage=var/coverage
- Ran bin/pliptest
- Created a new Plone site without the addon
- configured email
- added a user
- Installed the addon
- tested passwordreset old user
- tested login old user
- Created new users
- tested password reset new user
- tested login new user
- Configured "Use UUID user ids"
- created a test user
- password reset
- login
Notes and observations
- Test coverage is very good.
- All 39 robotsuite tests fail, I suspect my test setup is not complete.
- I get two additional test failures in Products.CMFPlone, both on unicode handling, both seem to be unrelated to this PLIP.
- PMI controlpanel and user login/passwordreset appears to work fine when exercised via browsers, for all userid variants: oldstyle, fullname-derived, UUID.
- Adding a user with fullname "Добавить комментарий" gives "Invalid text data" error on entry, but form submission succeeds. This is identical to the behaviour of an unpatched Plone 4.3 site. In the patched Plone site, a correct userid "dobavit-kommientarii" is derived.
- Apart from some minor PEP8 issues the code looks well-structured and clean.
- The code provides excellent inline documentation.
Conclusion
I'm not going to pretend I fully understand this implementation from reading the code. That said:
- The code looks clean, well-structured, well-tested, well-documented.
- The user experience appears to be flawless.
- The actual implementation is conform the PLIP proposal.
comment:9 Changed 3 years ago by rossp
+1 for merge:
https://github.com/plone/buildout.coredev/commit/fbf82b8f4e0505ca9621cf99306646b4636e80bf
Should merge into the core packages as a part of implementing the PLIP, but aside from that nice work!
comment:10 Changed 3 years ago by esteele
Maurits,
Your PLIP has been approved for merge by the Framework Team. Please merge it into the 4.4 buildout at your convenience.
comment:11 Changed 3 years ago by maurits
Thanks. It is on my radar, but there are currently so many failing tests in the 4.4 branch that I am reluctant to merge this plip. It makes it hard to say if my merge adds more testing failures or not.
Gosh, I may have to start fixing some of the existing failing tests first then. ;-) Well, I started a bit on that yesterday already.
comment:12 Changed 3 years ago by esteele
- Milestone changed from 4.4 to 5.0
The Framework Team has decided to move on to Plone 5. Updating milestones accordingly.
comment:13 Changed 2 years ago by maurits
- Status changed from confirmed to closed
- Resolution set to fixed
I have merged the changes to the master branch of all four related packages.