Dave, You brought up a great issue and I thought I would follow up with some testing I have been doing on how Web2py currently handles mixed case email addresses (which turns out to be perfectly, but this can cause end users some difficulties as many may not distinguish based on case. I have proposed a potential improvement at the end of the the email.
Dealing with email addresses can be more complex than one might first suspect. Wikipedia has some interesting things to say about valid email address formats in general and email validating in particular and is well worth the read. http://en.wikipedia.org/wiki/Email_address#Invalid_e-mail_addresses Our organization ran into some issues regarding the conversion of mixed case email addresses. The issue gets even more complex on an international level. For example: 반기...@unitednations.org Web2py accepts the first name "반" and a last name of "기문" but rejects the email address. Since EAI* is still being developed this is not surprising. banki-m...@unitednations.org Web2py accepts and stores this email address as entered, perfect! banki-m...@unitednations.org Web2py accepts and stores this email address as entered with no conflict with the address banki-m...@unitednations.org, perfect! banki-m...@unitednations.org By default, Web2py accepts and stores this email address as entered with no conflict for any of the above addresses, A+ for the development team! * When EAI is standardized, users will likely have a localized address in a native language script or character set, as well as an ASCII form for communicating with legacy systems or for script-independent use. Applications that recognize internationalized domain names and mail addresses must have facilities to convert these representations. If we only consider the currently "valid" email addresses such as: banki-m...@unitednations.org banki-m...@unitednations.org banki-m...@unitednations.org bankim...@unitednations.org # no hyphen here The Web2py registration system considers them to be four distinct email addresses which is great and indicates a perfect implementation but an inconsistent user could end up with four accounts or one account which they can not access;). They are confused because some applications and servers treat them as four different addresses, and others do not. We might find that Unix and nix like systems have no problems with all the above addresses but that some Python applications might have problems with the hyphen. We might find that some Windows / Microsoft systems treat some as being the same address / user account. Practically, many people (and perhaps many applications and some email servers) treat the first three addresses as if they are all lower case, but others do not. Users expect to be able to log on with either bobsm...@email.com or bobsm...@email.com so the technically perfect and legal and user expectations are in conflict. Possible ways of improving Web2py in this regard: During account creation and/sign on, one solution might be to run a query for similar email addresses. To limit unnecessary queries this could be run during registration or during sign on when no matching account is found. Would limiting the query to email addresses which differ in case only solve your issues? This would take care of our issue (users who do not consistently distinguish case). Chris On Sep 19, 10:41 am, "david.waldrop" <david.wald...@gmail.com> wrote: > HC thanks that worked like a charm. I must confess I think this > should be a bit more straightforward and I woiuld not have figured out > the separate places I needed to manipulate a users email address to > make this work. For others who may encounter this need here is a > consolidated summary of ensuring email matches across the built in > registration and login features of web2py: > > 1) add in a constraint to the email filed of auth.users by using a > requires (requires=IS_LOWER(),IS_EMAIL() ) . This ensures the email > is stored in lower case during registration and profile update. > > 2) defining a validation function that converts an email address to > lower case. (and knowing that it needed to receive a form as a > parameter,and it was possible to change the values of the submitted > form) > > # setup conversion of email address to lower case upon > clogin > def email_to_lower(form): > form.vars.email = form.vars.email.lower() > > 3) hooking the function defined in step 2 to be called after login and > changing the case of the email the user entered to lowercase (this > ensures it will match and make a better experience for the user). > This is done as follows: > > auth.settings.login_onvalidation = email_to_lower > > On Sep 18, 5:28 am, hcvst <hcv...@googlemail.com> wrote: > > > Hi David, > > > somehow, doesn't look pretty but this works. > > > def email_to_lower(form): > > form.vars.email = form.vars.email.lower() > > > auth.settings.login_onvalidation = email_to_lower > > > I guess the login form should not be case sensitive. (Or should it, > > Massimo?) > > > Regards, > > HC > >
