I’m setting up a WriteFreely instance for the users of my Mastodon instance, and I’m using the generic OAuth implementation to let them log in and create new accounts. One thing I noticed is that the binary open/closed registration toggle is a problem. Specifically:
if registration is “open” then yes people with a login to my Mastodon instance can create new accounts, but also anyone who hits the front page can create a new username through the standard user/pass account creation process
if registration is “closed” then people can’t use the front page to make new account (which is what I want), but also OAuth users can’t make new accounts
What I would like is for a setting that disables generic account creation but allows any OAuth user to make a new account. This is so that “strangers” can’t make an account, but people on my Mastodon server are free to do so.
I played with the idea of a new setting in config.ini that would go here (I’m referencing the PR where Matt created this feature for maximum context):
It would be a second boolean (allowOAuthRegistrationOverride or something) that if set to true would not trigger the code block highlighted above and a new user could be created regardless of the instance’s “closed” status.
But then I thought, well, what if you just made it so that OAuth was not gated by the closed/open status of the instance, and if an admin wanted to turn off OAuth they would just comment out the config.ini info for OAuth. But that goes against the idea of PR 303 above.
So basically this is a design question: how do we best enable my use case?
One idea I had was maybe to change the open/closed registration to two variables: AllowOAuthRegistration, AllowStandardRegistration. But that ruins the simplicity of an “on/off” switch for new accounts.
Hey @dariusk! Awesome that you’re setting up an instance.
I believe we have a config option for this, which was included with the changes in #317: disable_password_auth in the [app] section.
I believe if you set that to true and keep open_registration = true, you’ll keep the instance open to your Mastodon instance users, but closed to “strangers” who can’t authenticate that way.
The only thing here would be that users also can’t log in if the config is commented out. I think if we were going to add more granular control for supported OAuth providers, we might add a new config option to each one, e.g. allow_registration. (Then you might imagine a new config section for configuring username / password auth to go along with this, and moving the open_registration option there.)
We could definitely discuss that more if it’s necessary for certain use cases. But I’m not sure that it’ll be needed here.
Oh wow I totally missed open_registration for some reason!! That’s fine and totally addresses my issue.
I’m going to write a blog post on how to set up a Writefreely instance alongside Mastodon using OAuth for login, by the way. Should be up on my website later today I think. (I would put it on our WF instance but we are still debating as a group what to name it!)
Wait I was confused! I meant disable_password_auth is what I missed and, well, that’s not documented anywhere! I will update my open PR on the documentation to add that.