Email activation when using SSO

Feature
, ,
1

[@sam continuing our discussion]

What do you all think about adding a switch to the SSO settings to disable the automatic “trusting” of email addresses. That is, forcing users to activate their discourse account when it is created via SSO.

Right now I think the assumption is that the email verification is done by the provider, and so it can be skipped in discourse. However, we run an ecommerce store and email validation on account creation would negatively impact conversion.

I’m going to spend a little time trying to get into the code base today, but let me know if you think this would be an acceptable addition (or if I shouldn’t bother).

1 Like
2

It looks like the relevant SSO code is at discourse_single_sign_on:60-64

    # inside lookup_or_create_user
    if sso_record && (user = sso_record.user) && !user.active
      user.active = true
      user.save!
      (...)
    end

Would it be as simple as adding a setting to switch the user.active = true line to use the UserValidator ?

3

Submitted a PR for this: https://github.com/discourse/discourse/pull/3476

2 Likes
4

We have definitely seen people get in trouble when they enable SSO but do not validate emails or have a captcha on signup.

5

I feel like everything should be handled by third party and not by discourse. It should be the third party sites job to verify the email and have spam protection, not discourse’s.

1 Like
6

I disagree. A second layer of protection doesn’t hurt. This is especially true if it’s a Human spammer that uses a well-known spam domain, IP, ect.

But for those who don’t want the extra barrier, a configurable option would make more sense.

Basically, I would trust someone else as far as I can throw 'em, or be able to make dummy accounts on their network.

7

The problem is that the provider is not a forum, so it may have very different verification priorities. Spam is the priority for a forum, for which email verification is an appropriate solution. But other providers have different priorities (in our case, an ecommerce store).

It is more like a separation of concerns to allow Discourse to do it’s own types of verifications, without coupling itself to the third party provider.

1 Like
8

I’m fine with this idea as long as there is a way to turn it off…

9

The problem is that we, Discourse, get blamed for a “spam” problem when the root cause is badly designed SSO from the parent site that lets poorly vetted accounts through … This has come up a few times.

3 Likes
10

I really think that it isn’t “badly designed SSO”. Other applications are not forums and do not necessarily share the same concept of vetted accounts.

Yeah in my implementation there is a site setting that controls whether SSO trusts emails or not. Default would remain the same: all new accounts through SSO would be trusted.

11

This conversation reminds me of another one - discourse is doing so much better at all of this and is getting better all the time, while other platforms (like wordpress) are not keeping with the times. So it may be worthwhile to make it easier to use discourse as the SSO source… as part of the wp-discourse wordpress plugin, for example.

https://meta.discourse.org/t/discourse-as-sso-source-of-authority-for-wordpress/18400

But this idea of @plkap74 is also very interesting - why not just still keep that layer of validation in discourse so when the user comes over from the other site they can be verified again. Perhaps we could then also still benefit from other discourse features that we lose with SSO, like the invites system, which I sorely miss!

12

How can you have an account without a forgot password link? And where does this forgot password resolve to, exactly? Can you explain that to me?

13

I think that when people add credit cards it trumps email validation, when I buy plane tickets I am not held back on email validation

1 Like
14

Possibly but where do you send the credit card receipt for the purchase?

15

To the email address…

1 Like
16

For web merchants (for example Qantas ticketing etc.) the email is just assumed to be good. If they have issues the customer will contact them via a call with an order ref.

They avoid the activation of email so they do not slow down the purchase flow. (same as we do on www.discourse.org/buy)

Assume its the same issue for @plkap74 when people spend 800 bucks on X-Carve

17

That is exactly right Sam.

18

For the purposes of discussion, how does single credit card payment work? Does a user pay for each post and that is their “identity”?

What I am getting at is that there has to be some kind of account with a valid email to do anything beyond “buy this single item and never be seen again”. For example, collecting mileage points on that Quantas ticket you bought.

The case described only works if the customer buys once and walks away forever. Or buys so infrequently that they do not care. Neither of those are scenarios where Discourse would be of any use to that business whatsoever.