Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disable standard registration #641

Open
jordanjay29 opened this issue Nov 24, 2015 · 27 comments

Comments

@jordanjay29
Copy link
Member

commented Nov 24, 2015

_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

This comment has been minimized.

Copy link

commented Nov 24, 2015

+1

@moutonnoireu

This comment has been minimized.

Copy link

commented Nov 24, 2015

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

This comment has been minimized.

Copy link
Member

commented Dec 6, 2015

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

This comment has been minimized.

Copy link
Contributor

commented Dec 8, 2015

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

screenshot

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

@luceos

This comment has been minimized.

Copy link
Member

commented Dec 16, 2015

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

This comment has been minimized.

Copy link
Member

commented Jan 7, 2016

@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

This comment has been minimized.

Copy link

commented Jan 7, 2016

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

This comment has been minimized.

Copy link
Member

commented Jan 7, 2016

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

@franzliedke

This comment has been minimized.

Copy link
Member

commented Jan 7, 2016

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

@tobyzerner

This comment has been minimized.

Copy link
Member

commented Jan 7, 2016

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

@franzliedke

This comment has been minimized.

Copy link
Member

commented Jan 7, 2016

👍 in that case.

@luceos luceos added this to the 0.1.0-beta.6 milestone Jan 7, 2016

@tarunmarkose

This comment has been minimized.

Copy link

commented Jan 8, 2016

+1

@dcsjapan

This comment has been minimized.

Copy link
Contributor

commented Mar 20, 2016

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

@wion

This comment has been minimized.

Copy link

commented Jun 17, 2016

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

This comment has been minimized.

Copy link
Contributor

commented Jun 17, 2016

Couldn't they just add a Google capita?

@wion

This comment has been minimized.

Copy link

commented Jun 17, 2016

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

This comment has been minimized.

Copy link
Contributor

commented Jun 17, 2016

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

This comment has been minimized.

Copy link

commented Jun 17, 2016

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

@luceos luceos assigned luceos and unassigned luceos Aug 2, 2016

@tobyzerner tobyzerner modified the milestones: 0.1.0-beta.7, 0.1.0-beta.6 Aug 23, 2016

@sijad

This comment has been minimized.

Copy link
Contributor

commented Sep 7, 2016

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

@tobyzerner tobyzerner removed this from the 0.1.0-beta.7 milestone Jul 22, 2017

@rumblefrog

This comment has been minimized.

Copy link

commented Aug 6, 2017

Any idea why was it removed from beta7 milestone?

@dav-is

This comment has been minimized.

Copy link
Contributor

commented Aug 6, 2017

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

@ed6767

This comment has been minimized.

Copy link

commented Jun 2, 2018

+1

@franzliedke

This comment has been minimized.

Copy link
Member

commented Jun 3, 2018

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

@SampaioLeal

This comment has been minimized.

Copy link

commented Mar 31, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Apr 2, 2019

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

@luceos

This comment has been minimized.

Copy link
Member

commented Apr 2, 2019

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

This comment has been minimized.

Copy link

commented Aug 9, 2019

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.