Hi Wichert, Thanks for the feedback.
On Sun, Aug 16, 2009 at 09:27:27AM +0200, Wichert Akkerman wrote: > On 2009-8-16 02:14, Maurits van Rees wrote: >> Hi all, >> >> Plip 9214, support logins using e-mail address instead of user id, is >> ready for review. >> >> Ticket: >> https://dev.plone.org/plone/ticket/9214 >> >> Accompanying notes: >> https://dev.plone.org/plone/browser/buildouts/plone-coredev/branches/4.0/plips/plip9214-emaillogins.txt > > Can you explain why using email addresses as login is a configuration > option in site_properties instead of on a PAS plugin? All authentication > configuration is on PAS plugins, so I would expect this to be there as > well. Mostly because what I did here was already working in the collective.emaillogin package that I created for a client together with Guido Wesdorp. This has worked for one and a half years now at that client, so I would say it is proven technology. Well, in that package the only 'configuration option' was: if you want email logins, install this package. :) But the real work was done not in a PAS plugin but by some patches. I think in whatever way you do it in the background (a plugin or some changes like I did now) you need a config option in the plone control panel. Based on this setting you can show something different in, for example, the registration and login forms. Turning this option on could instead set the priority of the plugins in the background (and get its value by checking this priority). Arguably you could make a small browser view or function to check if an emaillogin pas plugin is at the top and use that in the spots where I am now using the property setting. For me the property fits with the rest of the security control panel. I am aware of the recent betahaus.emaillogin package that does this as a PAS plugin. I have not tried it out, but last time I looked at the code it looked like it should work. I like my method more. Also, I am highly biased. :) > If you use the email address as login than user.getUserName() must also > return the email address, so the changes in PasswordResetTool should not > be needed. That only works as long as you have not changed your email address yet, as then the userid (member.getId()), login name and email address are still all the same. skins/PasswordReset/registered_notify_template.pt passes member.getId() to the requestReset method of PasswordResetTool. If you have changed your email address and then reset your password, then resetting will fail without these changes. When I remove those changes I indeed get a failing test in bin/test -s Products.CMFPlone -m testEmailLogin > Looking at the notes this PLIP is creating a situation where > a user logs in with something that is not the users login name, which is > a pretty big deviation from standard behaviour, and I am not sure if > that is desirable. Actually, logging in still only works with your login name. Without the use_email_as_login setting the login name is the same as the user id; with that setting the login name is the same as the email address. What can be strange, and that may be what you mean, is that changing this setting does not in fact change the current login name of existing users. That only happens after they save their personalize form. That is also mentioned on the security panel BTW. > I think 'Offer migration of current login names to > email addresses' item from the further-ideas list should be mandatory. I'll await comments from the framework team, but yes, I want to add this. Have not had time yet. > Looking at your further ideas: email addresses are defined to be case > sensitive in their local-part (not in the domain name), so lowercasing > will technically violate standards. In reality I don't think any MTA is > case sensitive (as witnessed by the fact that postmas...@domain works > everywhere while the RFC defines postmas...@domain) so this might still > be a good thing to do from a user experience perspective. It does > deserve a clear warning in the documentation. I wonder if we would be opening up security issue by allowing one user to have u...@example.org as login and another to have u...@example.org. But I cannot come up with a backdoor here. Being able to use these two address could be handy for admins if they have to test something (though admins probably have enough email addresses already), so we probably do not need to do any lowercasing here. Cheers, -- Maurits van Rees | http://maurits.vanrees.org/ Work | http://zestsoftware.nl/ "Yes, we study economics, got to make the money make some kind of sense." - Geoff Mann _______________________________________________ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
