Possible to use SSO without disabling signup and registration spam checks?


(Jeff Widman) #1

Is there a way to enable SSO without disabling all the content spam checks/tools?

I own a community website that’s open to the public with 200K+ users, and while our SSO app stops bots pretty effectively on the registration form, we still get several human spammers successfully registering every day. It’s pretty much impossible to differentiate them from normal users until they post profile spam, threads, etc.

I saw this comment from @riking that all of Discourse’s anti-spam stuff is disabled when SSO is turned on.

Is it possible to turn a lot of that back on and still use SSO?

I trust that a user who successfully registers is a human, but I don’t trust them to not spam. So I still want the content-spam stuff like rate-limiting, sock-puppet checks, etc happening.

Since the code is already written, seems like a no-brainer to leverage it.

We have several other custom-built apps specific to the site’s topic, so that’s why we use SSO. I suppose we could hack things such that Discourse is the SSO gateway for the other apps, but it’s a lot cleaner to stay with a dedicated SSO app outside of Discourse.

It’d also be handy if there was an endpoint where the SSO app can check if Discourse thinks someone is a spammer–then the SSO app can freeze their account across the entire site until the user record is manually reviewed by a moderator.

Overview: Single Sign-On (SSO) / OAuth2 (is this chart correct?)
(Jeff Atwood) #2

I think you might have misunderstood, or maybe @riking wasn’t clear. (I’ll edit your title so nobody gets confused.)

The only thing skipped with SSO enabled are signup and registration checks.

For example the thing @molly_cushing was complaining about was that the email / IP blacklist wasn’t being respected. That’s because the email and IP blacklists only apply at the time of signup, and from our perspective when we get a user via SSO, they’re already a user, they never “signed up” or “registered” via Discourse, they just magically arrive via teleportation on the site.

SSO users will still be trust level 0 users and are subject to all the other sandbox stuff we do for trust level 0 users.

(Jeff Widman) #3

Great news, I probably just misunderstood his comment. Thanks Jeff.

(Jeff Atwood) #4

We did make it so some of the primary checks, like IP restriction bans and email address bans, are enforced on SSO now.

Long story, but we had a customer where they had SSO but were unable or unwilling to enforce these checks on their side, so now they are enforced unconditionally on our side just in case.

(Dean Taylor) #5

Is there a check that can be done to see if these effect existing installations?

Perhaps a rails command / DB query that would highlight if these changes have an impact on an installation?

Perhaps say where IP bans may arise because several / all users have the same IP.

(cpradio) #6

Has this changed? Ever since Sitepoint moved to SSO, the Registration IP into Discourse has been missing.

This is not a censored screenshot, there literally is nothing in the Registration IP Address.

Likewise, we’ve noticed Sock-Puppet detection isn’t happening. I have a feeling that it may be related to the Registration IP not being there, but this is becoming to be a larger problem for us.

From a recent conversation (at Sitepoint):

Three new members involved, all signed up from 110.93.X.X (if you need the actual IP, I can PM it) and all posting from that address, but no flags were raised.

So with all that said, I’ve been throwing these discussions off based on our switch to SSO, but from the above discussion, it seems a lot of this is supposed to still be working. So now I’m confused as to what should be working with SSO and what shouldn’t be.

cc @nec286

Oh and it seems our Blocked IPs are not being utilized anymore either, which I can only assume is also related to the Registration IP not coming into Discourse due to us enabling SSO.

(TechnoBear) #7

It appears that the system does still “check” the blocked IP list, but doesn’t prevent the account creation. So the “last matched” date and time is the last time an account was created at that address.

(Jeff Atwood) #8

Any ideas on places to look here @sam?

(Sam Saffron) #9

I need to add a test to ensure that field is correctly populated for SSO cases.