Basic Email Regex #20

Closed
bousquet opened this Issue Apr 4, 2013 · 10 comments

Projects

None yet

5 participants

@bousquet
Member
bousquet commented Apr 4, 2013

Need a way to give immediate feedback on the identity save that an email address is malformed. Doesn't need to check all the possible configurations (plus expansion, domain extensions, etc) but it should tell you if you leave out the @ symbol or put a username in instead of an email address format.

This is basically the level of validation I feel would be sufficient:
...stuff@stuff.stuff...

@phlipper phlipper was assigned Apr 4, 2013
@phlipper
Collaborator
phlipper commented Apr 8, 2013

After discussion with @bousquet, the current basic validations here are sufficient for now.

@phlipper phlipper closed this Apr 8, 2013
@kjohnston
Member

Can you guys post the reasons for this decision?

I know that the perfect email regex is a fabled creature and that emailed verification link is a much better way to validate an email address. However, format: /@/ is really lose and the databases will fill with unusable addresses that could be easily remedied with a less-lose regex such as one that would cover @bousquet's example.

@supernullset
Contributor

FWIW, here is the article which converted me to the /@/ camp:

@bousquet
Member
bousquet commented Apr 9, 2013

Yeah, valid email email syntax is very loose once you get into the specifics. I'm ok with just making sure it includes the @ symbol which would at least prevent people mistaking it for a username field.

@kjohnston
Member

@supernullset, funny article, thanks for sharing.

@bousquet, I think that catching the situation where the email field is mistaken for a username field is important. It's something you or I might benefit from as users completing a signup form - if a validation tells us to type an email address we'll probably not mess it up at that point. But, I would prefer to go a short distance further to mitigate the issues likely to arise given the user base some apps will have.

Think about the middle-aged marketing lady who enters mycatrules@AOL (without an extension). This would pass validation and she wouldn't think twice about how it might be invalid.

I think we should not get crazy, but have a simple regex that allows for [anything-at-all-including-tags]@[something].[anything-at-all-including-endless-weird-subdomains] - or, at least allow for the regex to be customized at the configuration level.

@elskwid
Contributor
elskwid commented Apr 9, 2013

I wouldn't bother with anything more intense than the /@/. The article that @supernullset linked to is right on the money. Our system is going to send them an email anyway.

If we have designed a sign up procedure or form that is confusing I would advocate for more information/guidance in that UI and perhaps even some client-side validation or light checks to make sure the simple cases are taken care of. For instance, a message that says, You've just entered your email as "mycatrules@AOL" are you sure that's your address? We're going to send a confirmation email to that address when you say "Yes".

@kjohnston
Member

I'm thinking something uber simple, like /^\S+@\S+.\S+$/.

Sending the user an email is ideal in terms of verification, no doubt about that. But verification requires a number of considerations and won't be needed in all applications. #21 will introduce the ability to disable verification.

I think of the owner of mycatrules@AOL as a person who thinks that that is a real email address, so rather than trying to solve the problem with additional UI, a simple regex can still go a long way.

If verification is left enabled, mycatrules@AOL won't receive the email and we'll need to ensure she sees messaging that informs her that if she didn't receive the message she needs to proceed to her profile (meaning she'll need to be logged in, we can't bar her from being logged in pre-verification, but may have to limit access) so that she may update her email, then either use a callback to resend the verification message or give her a button to press to do the same. Then we still have to worry about re-verification when she updates her email in the future - is it possible to replace a verified email with a new one if the user neglects to verify the new address?

@phlipper
Collaborator
phlipper commented Apr 9, 2013

@kjohnston your arguments provide a lot of "what-if" scenarios that I have not personally seen play out in practice when using this pattern.

I think that catching the situation where the email field is mistaken for a username field is important. It's something you or I might benefit from as users completing a signup form [...]

Sure, but we can give ourselves and our users some credit. We already:

  • place a label entitled 'email' vs. 'username'
  • place an email icon on the text box by default
  • provide an html widget that is an email type input providing direction and basic 'client side validation' already
  • display a rails validation warning for invalid email format if they try to simply type a username

Think about the middle-aged marketing lady who enters mycatrules@AOL (without an extension). This would pass validation and she wouldn't think twice about how it might be invalid.

This may be true, but FWIW, mycatrules@AOL is a valid email address format. So is root@localhost, and any number of other possible host-without-dots format.

If someone happened to type one of those combinations, they would simply not receive a confirmation email and would try again. We can provide other visual/verbal/written/whatever queues to ensure the requirements are clear without imposing extra technical or formatting restrictions on ourselves or our users.

But verification requires a number of considerations and won't be needed in all applications.

What are some of these considerations?

#21 will introduce the ability to disable verification.

True, but not the way you think. #21 will not be the primary workflow, it will simply provide an API for working with identities "out-of-band" from the standard signup process if you need to manually interact for some reason. A new user signup should always require a verification step.

If verification is left enabled, mycatrules@AOL won't receive the email and we'll need to ensure she sees messaging that informs her that if she didn't receive the message she needs to proceed to her profile (meaning she'll need to be logged in, we can't bar her from being logged in pre-verification, but may have to limit access) ...

Or we don't login users that haven't been verified, or they try to signup again, or any number of potential options that don't require more code, just more clarity.

FWIW, I've used this technique for a while and have never had problems, business, technical, or otherwise. Occasionally you may need to clean out a handful of records where you have a created_at and no verified_at (users bail sometimes, you can't fix that whether the email is valid or not), but I think this overall workflow provides a pretty solid balance of the functionality we're looking for.

You can always provide a pull request to sway us if you feel really strongly about it ;)

@bousquet
Member
bousquet commented Apr 9, 2013

@kjohnston, I agree with @phlipper on the less precise, but more accurate validation format. There too many potential valid characters in email addresses to require any more than an /@/.

Here's some global comments that will probably lead to other issues being defined, but somewhat relevant to the concerns mentioned in this thread:

One change I think would help to prevent verification from being a blocking event is to allow non-verified users to still be able to login (related to #21). Application logic can determine how to handle users without verified email addresses. The gem can basically provide an automatic verification process and a Identity#verified? status.

This would also allow an administrator to see and correct any incorrect new email addresses if the user somehow doesn't figure out their email address was wrong and need to be helped out. For apps with stricter requirements, or public signup, the verification status can be enforced.

For new user creation (related to #23), an invitation process will allow users to be created (with permissions assigned) and the response to the invite will be adequate email verification for the new identity. The new user can choose their own password as part of the invite acceptance workflow. This prevents the administrator from providing a password via email to a user which is a practice we should stop accepting as adequate.

@kjohnston
Member

@bousquet, great descriptions for how to handle #21 and #23, thanks! If we can go with those then I'm ok with the regex discussion being put to rest.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment