Core: Disable standard registration

[jordanjay29]

_3 Upvotes_ As per discussion: https://discuss.flarum.org/d/1501-disable-standard-account-registration

Disable the traditional-style registration (username/pass/email + email verification) in favor of SSO extensions as the sole means of registration. Either as part of Core or by making registration an extension like other SSO (Facebook/Twitter/etc) extensions that can be enabled/disabled at will.

[jberlyn]

+1

[moutonnoireu]

As i'm not 100% ok with disabling the "username/pass/e-mail" combo that should be kept if the community administrator want it ; the whole mail verification thingy - as stated in the discussion linked - is not to be used, a simple captcha verification (recaptcha for instance) could be sufficient at the signup screen.

'Was also thinking that i could be great to let the administrator of the community choose what identification he need for his community and also how did he want to secure this 'phase' : number of char. required in the password, captcha or no, only user/pass/email method or just twitter, etc...

[franzliedke]

Well, we can't remove this from core completely. Just imagine this extension not being enabled, and you trying to log in to install it, or one of the others. ;)

[dcsjapan]

Is there any reason you can't use the existing permission to disable registration ...

... and create an extension that would handle SSO account creation?

[luceos]

Maybe remove sign up as a right and simply add a checkbox style option that allows checking any of the authentication methods available, always showing username/password and always requiring one. Maybe a terminal command can re-enable/reset those options for when something goes amiss.

[tobyzerner]

@franzliedke and I discussed this and agree to adding a checkbox to enable/disable username/password authentication, with a warning that every existing user should be able to sign in with SSO. And as @Luceos said we can consider a terminal command/ mention in the documentation to revert the setting.

[moutonnoireu]

And as for the mail verification steps ? Could we also have a trigger to disable it and add a captcha to the registration phase ?

[tobyzerner]

@moutonnoireu Yes I think that's reasonable (agreed @franzliedke?) but you should create a separate issue for it :)

[franzliedke]

Is this about the confirmation email to the old address when changing email? Sure.

[tobyzerner]

I think he means the confirmation email when you initially sign up as well.

[franzliedke]

:+1: in that case.

[tarunmarkose]

+1

[dcsjapan]

Created separate issues for the features suggested by @moutonnoireu and added one of my own.

[wion]

Was happy to see this one. I started thinking it wold be important for us after I noticed WebFaction turned regular sign-up off on their community boards in favor of Twitter, GitHub, etc because the waves of spam accounts via regular sign up was burying them.

[dav-is]

Couldn't they just add a Google capita?

[wion]

I wouldn't know anything about it, but it got me thinking... maybe I want to leave it to Twitter and GitHub too. I don't want to spend 60% of my time suspending spam sign ups. The third-party route, depending on which ones, I guess, seems to cut that down significantly. I wouldn't add Facebook or G+ sign ups, personally, but mileage will vary depending on purpose and audience of a given board.

[dav-is]

If you get google recapcha you don't need to worry about that. Most sites that have issues with spam use some random garbage captcha. I've never had issues with bots getting through the Google recapcha. Plus it can be as simple as checking a box to prove you're human. https://www.google.com/recaptcha/intro/index.html

[wion]

@dav-is, thanks. I hope Flarum looks into it.

[sijad]

@wion @moutonnoireu there is an reCAPTCHA extension for Flarum now
https://discuss.flarum.org/d/3707-recaptcha
sorry for spamming

[rumblefrog]

Any idea why was it removed from beta7 milestone?

[dav-is]

@RumbleFrog They prioritized in order to push beta 7 out sooner.

[ed6767]

+1

[franzliedke]

Instead of a reminder, we should simply prohibit disabling this login method if there are user accounts relying on it.

[SampaioLeal]

So, what if you just hide the email and password inputs from login modal, and disable sign up from admin panel? (i have this idea, but im not locating the login modal in the source) :(

[sijad]

I really need it.
can I work on this one? if yes please share your thoughts about how should it be implemented?

[luceos]

What if we move the basic email authentication into its own bundled core extension and the modal to use an item list if not already so?

[JoshStrobl]

I hate to necro things, but I'd also like the ability to hide or disable standard email + password signup and login capabilities.

1. The Solus forums support both GitHub and Phabricator (via a modified version of the OAuth2 passport login extension) and those would really be our preferred ways of logging in to engage in the platform at this point.
2. We've been dealing with a lot of spam recently from various botnets, which are abusing the "traditional" login method to create accounts, filling in reCAPTCHA (and also not seemingly being a part of the Stop Forum Spam or Akismet databases, we use two extensions for this), so really we'd just like the raise the barrier of entry to not make it worth their while.
3. Building on that, we're more likely to be engaging with users that'd have accounts on our development tracker (Phabricator) and so it'd actually ease escalating certain support queries to tasks / issues on it, as we could eliminate the possibility of them signing up using traditional methods.

[barkinarga]

I hope there will be a simple way to disable it.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We do this to keep the amount of open issues to a manageable minimum.
In any case, thanks for taking an interest in this software and contributing by opening the issue in the first place!