Email activation when using SSO

Contribute Feature
, ,

AI-generated summary

The discussion revolves around adding a feature to Discourse that allows site administrators to disable automatic email verification via Single Sign-On (SSO). Currently, Discourse trusts email addresses verified by the SSO provider, but some users want the option to require additional email verification.

@plkap74 suggests adding a switch to the SSO settings to disable automatic email verification, citing the example of an ecommerce store where email validation on account creation could negatively impact conversion.

@codinghorror agrees that having a second layer of protection doesn’t hurt, and a configurable option would make sense. @purldator also supports this idea, stating that trusting third-party sites to verify emails and have spam protection is not enough.

@nahtnam initially disagrees, stating that email verification should be the third-party site’s responsibility. However, they later agree with the idea as long as there is a way to turn it off.

@plkap74 submits a pull request for this feature, and @tobiaseigen suggests that it could also benefit other Discourse features, such as the invites system.

@codinghorror emphasizes that Discourse often gets blamed for spam problems caused by badly designed SSO from parent sites. However, @plkap74 disagrees, stating that other applications have different verification priorities.

@sam and @nahtnam discuss how some web merchants assume email addresses are valid and avoid email activation to speed up the purchase flow. @codinghorror questions how this works in practice, and @sam explains that customers can contact merchants via phone or order reference if issues arise.

The discussion concludes with @codinghorror questioning how single credit card payments work and whether they require a valid email address for any kind of account or identity.

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개의 좋아요
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: Add SSO setting to not trust emails automatically by paulkaplan · Pull Request #3476 · discourse/discourse · GitHub

2개의 좋아요
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개의 좋아요
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개의 좋아요
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개의 좋아요
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개의 좋아요
14

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

15

To the email address…

1개의 좋아요
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.