Option: Email address confirmation not required when using social account

[reezer]

Usually I do want the email address to be confirmed, however when this email address is taken from a social networking site the probability that this email address is valid is pretty high. Why would I still want to send out a confirmation link? It would be great if there would be a way to disable this, while leaving this functionality intact for non-social accounts.

[pennersr]

Unfortunately, it is not that trivial.

• OpenID: Several OpenID providers pass along unverified e-mail addresses during the OpenID handshake (e.g. largest Dutch OpenID provider Hyves.nl).
• Facebook: It is possible to create a verified account without verifying the e-mail address: Email from facebook cannot be considered verified bbangert/velruse#69
• Twitter: No e-mail address is passed
• Google: The profile info contains an email_verified flag, so it would be feasible here.
• LinkedIn/SoundCloud/GitHub: To be determined

I'll keep this ticket open. TODO:

• Document the above
• Support Google email verified

[reezer]

But if an option would be defined one could choose. Maybe on a per site basis?

[pennersr]

What do you mean? This is not something optional. If you set e-mail verification to mandatory then e-mails must be verified. If Facebook does not guarantee verified e-mails then the current behavior (sending out e-mail verifications) is correct. Making this optional somehow defeats the purpose of e-mail verification. In that case, simply turn e-mail verification off.

[johanneswilm]

I understand that email addresses from Facebook are not really verified while those from Google are. So you are probably right that only the Google addresss should be marked as verified.
But the point is that one oftentimes just wants to have some kind of link of the person be it to a social network or to an email account. The entire point is that it slows the creation of machine created fake accounts down considerably. So I would vote in favor of a feature to only have mandatory email verification in the case of normal signups, but have it turned off when entering using a social network account.

[pennersr]

I am not very fond of adding a setting that breaks the semantics of the e-mail verified flag. If stopping fake accounts is your goal, then please consider putting a captcha on your signup form. Making the user jump through hoops like handling verification mails when you are not really after a verified e-mail address does not seem very user friendly.

If you insist, we could pass along the social login to is_email_verified over at:
https://github.com/pennersr/django-allauth/blob/master/allauth/account/adapter.py#L15
Then, you could plug in your own adapter to accomplish what you want.

[johanneswilm]

mm, I think most websites with social signup work this way?: either you signup using an email account that you have to verify, or you sign up using a social networkign account. django-allauth is the only place this is different that I know about, so I don't think this is such a strange thing to e wondering about.

There are two parts to this as far a I can see: One part is that email addresses that are verified already are treated as if they were not. This is the case with Gmail at least and the current behavior of verifying gmail-addresses twice seems broken. In the case of Facebook, I would think someone would have to recheck the claim that they show nonverified emails. Maybe they changed some things around, but I have at least not been able to sign up for an acocunt and get it verified without clicking on the verification link. I could not find the part about a verified Faceook account not having a verified email address in the Facebook develoepr documentation either. I would really like to know how to do this.

The second part is to have an option to only require a verified email if you do traditional signup, which is what I gather from the above.

I haven't looked enough at the allauth code to say where one could do this, but if you say that the place to do this is in the adapter, then I would be all for this.

Thanks for taking the time looking into this!

[pennersr]

The reason I am cautious about the semantics of the verified flag is that there are production sites up and running that rely on it to be correct. For example, users that have a verified e-mail matching a certain domain automatically gain extra privileges. So it involves potential security problems.

It is still not clear to me why you are using email verification in the first place?

As for the points you make:

1. "most web sites..." -- I am not sure I agree. Most sites that are an interesting target for spammers that want to automatically create accounts use captchas in their signup form.

2. "verifying gmail-addresses" -- valid point -- this is why this ticket is still unsolved.

3. "recheck FB" -- valid, this will need a bit of research and experimentation. E.g. is it possible to signup and validate with your mobile phone etc. But I hope you understand I really want to tick this off before accepting FB e-mail addresses as verified.

4. "only require a verified e-mail if you do a traditional signup" -- here I would really like to understand the use case. What do you gain by doing so? Take Twitter for example, it does not hand over an e-mail address at all.
   If stopping fake accounts is the goal, then please consider adding a captcha. With e-mail verification you may be blocking a small fraction of your users whose mail is not delivered or ends up in a spam folder.

[johanneswilm]

As for the first three points we agree. As for the fourth point: A captcha
does not really do it, as I am talking about human generated accounts. It's
so one has a little bit of evidence to go by when determining whether an
account is purely fake if one can check whether their social networking
account exists. Same goes in the case of normal accounts and their verified
email. If someone has an email from hotmail or gmail that just consists of
a series of random letters, then most likely this person has no good
intentions.
On Jan 3, 2013 5:59 AM, "Raymond Penners" [email protected] wrote:

The reason I am cautious about the semantics of the verified flag is that
there are production sites up and running that rely on it to be correct.
For example, users that have a verified e-mail matching a certain domain
automatically gain extra privileges. So it involves potential security
problems.

It is still not clear to me why you are using email verification in the
first place?

As for the points you make:

1. "most web sites..." -- I am not sure I agree. Most sites that are an
   interesting target for spammers that want to automatically create accounts
   use captchas in their signup form.

2. "verifying gmail-addresses" -- valid point -- this is why this ticket
   is still unsolved.

3. "recheck FB" -- valid, this will need a bit of research and
   experimentation. E.g. is it possible to signup and validate with your
   mobile phone etc. But I hope you understand I really want to tick this off
   before accepting FB e-mail addresses as verified.

4. "only require a verified e-mail if you do a traditional signup" -- here
   I would really like to understand the use case. What do you gain by doing
   so? Take Twitter for example, it does not hand over an e-mail address at
   all.
   If stopping fake accounts is the goal, then please consider adding a
   captcha. With e-mail verification you may be blocking a small fraction of
   your users whose mail is not delivered or ends up in a spam folder.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/145#issuecomment-11837899.

[pennersr]

Just checking: suppose someone signs up with Twitter. No e-mail address is handed over by Twitter, so the user will need to fill it in after authenticating with Twitter. I assume that in this case the user has already shown that his account is not purely fake -- there is a valid Twitter account after all. So, there is no need for e-mail verification to kick in. Agreed?

This would mean that the requirement is not to stamp the e-mail address as "verified", but rather that you need some form of control over whether or not e-mail verification is to kick in in the first place...

[johanneswilm]

That specific use case would be us, correct. But additionally, say one
would want a verified email address no matter what. In that case it should
still not send another verification email to Gmail users and possibly not
to Facebook users either. We still need someone to open a Facebook account
using only a phone number, and still be able to supply an email to the
signin app. I failed at doing that and haven't found anyone else who was
able to do it either. If Yahoo is ever supported, those emails should be
automatically verified as well, I believe.
On Jan 5, 2013 6:27 PM, "Raymond Penners" [email protected] wrote:

Just checking: suppose someone signs up with Twitter. No e-mail address is
handed over by Twitter, so the user will need to fill it in after
authenticating with Twitter. I assume that in this case the user has
already shown that his account is not purely fake -- there is a valid
Twitter account after all. So, there is no need for e-mail verification to
kick in. Agreed?

This would mean that the requirement is not to stamp the e-mail address as
"verified", but rather that you need some form of control over whether or
not e-mail verification is to kick in in the first place...

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/145#issuecomment-11920178.

[pennersr]

I just checked the Facebook case, The documentation over at https://developers.facebook.com/docs/reference/api/user/ clearly mentions:

A user is considered verified if she takes any of the following actions:
Registers for mobile
Confirms her account via SMS
Enters a valid credit card

So verified=true over at Facebook does not imply email.verified=true for allauth.

[johanneswilm]

Ok, but have you tried whether it will return a non-verified email address
for you through the authentication process?

On Mon, Jan 7, 2013 at 5:09 PM, Raymond Penners [email protected]:

I just checked the Facebook case, The documentation over at
https://developers.facebook.com/docs/reference/api/user/ clearly mentions:

A user is considered verified if she takes any of the following actions:
Registers for mobile
Confirms her account via SMS
Enters a valid credit card

So verified=true over at Facebook does not imply email.verified=true for
allauth.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/145#issuecomment-11969020.

Johannes Wilm
http://www.johanneswilm.org
tel US: +1 (520) 399 8880
tel NO: +47 94109013
tel DE: +49 176 370 18082

[pennersr]

I haven't tried yet. Still, even if it works like that now, it is no guarantee that it stays that way as it is clearly not documented that way.

I am still pondering about an approach to move this forward. How about the following approach:

• A new method def get_email_verification_method(user, **kwargs) will be added to the account adapter.
• By default, this method returns settings.ACCOUNT_EMAIL_VERIFICATION
• You can override this method, inspecting user and/or kwargs['sociallogin'] to make up your own mind.

This way, you can add your own custom logic and return EmailVerificationMethod.NONE to bypass e-mail verification.

Would this suit your needs?

[pennersr]

Added a new FB provider setting: VERIFIED_EMAIL