Add the option to disable the default Email/Password authentication option #882

New Issue

OVERLORD · 2026-02-04T22:41:24+03:00

OVERLORD commented

2026-02-04 22:41:24 +03:00

Originally created by @tuaris on GitHub (Oct 25, 2018).

Describe the feature you'd like
Disable Registration form but keep the ability to use Social Registration only.

Describe the benefits this feature would bring to BookStack users
Forces the use of more secure authentication processes.

Additional context
Example: Google SSO is enabled and the administrator would like to enforce users to utilize Google SSO instead of local auth. Currently Bookstack's login and registration forms will have fields to enter username's/email and password in addition to the Social Login button.

The administrator should have an option to 'turn off' those fields and have only the social login/registration options available.

BONUS: The login and signup links can automatically use social login/register if there is only one enabled. Or the admin can set a preferred one if multiple are enabled.

Originally created by @tuaris on GitHub (Oct 25, 2018). **Describe the feature you'd like** Disable Registration form but keep the ability to use Social Registration only. **Describe the benefits this feature would bring to BookStack users** Forces the use of more secure authentication processes. **Additional context** Example: Google SSO is enabled and the administrator would like to enforce users to utilize Google SSO instead of local auth. Currently Bookstack's login and registration forms will have fields to enter username's/email and password in addition to the Social Login button. The administrator should have an option to 'turn off' those fields and have only the social login/registration options available. BONUS: The login and signup links can automatically use social login/register if there is only one enabled. Or the admin can set a preferred one if multiple are enabled.

OVERLORD added the 🛠️ Enhancement 🔨 Feature Request 🚪 Authentication 🏭 Back-End 💻 Front-End labels 2026-02-04 22:41:24 +03:00

OVERLORD commented

2026-02-04 22:41:30 +03:00

@tuaris commented on GitHub (Oct 25, 2018):

I currently 'hack' this using CSS

@tuaris commented on GitHub (Oct 25, 2018): I currently 'hack' this using CSS ![image](https://user-images.githubusercontent.com/5660265/47513872-220a9380-d84d-11e8-8b11-5a240ed9959b.png)

OVERLORD commented

2026-02-04 22:41:34 +03:00

@HitomiTenshi commented on GitHub (Nov 5, 2018):

I second this. I only allow login through our GitLab instance.

As a current workaround I use the following Custom HTML head content setting:

<style>
#login-form,
#login-form + hr {
  display: none;
}
</style>

Results in a clean login view:

@HitomiTenshi commented on GitHub (Nov 5, 2018): I second this. I only allow login through our GitLab instance. As a current workaround I use the following `Custom HTML head content` setting: ```HTML <style> #login-form, #login-form + hr { display: none; } </style> ``` Results in a clean login view: ![chrome_2018-11-05_02-11-07_v1s](https://user-images.githubusercontent.com/7304212/47972802-16666a80-e0a0-11e8-82bc-02e660fe175a.png)

OVERLORD commented

2026-02-04 22:41:39 +03:00

@pacroy commented on GitHub (Nov 9, 2018):

Here is how you disable the form on registration page:

<style>
form[action$="register"] {
  display: none;
}
form[action$="register"] + hr.margin-top {
  display: none;
}
</style>

@pacroy commented on GitHub (Nov 9, 2018): Here is how you disable the form on registration page: ``` <style> form[action$="register"] { display: none; } form[action$="register"] + hr.margin-top { display: none; } </style> ```

OVERLORD commented

2026-02-04 22:41:53 +03:00

@HitomiTenshi commented on GitHub (Nov 9, 2018):

@pacroy Your style doesn't disable the registration, it only removes the registration form from the DOM.

If you want to properly disable user registration you should disable it in the settings page:

@HitomiTenshi commented on GitHub (Nov 9, 2018): @pacroy Your style doesn't disable the registration, it only removes the registration form from the DOM. If you want to properly disable user registration you should disable it in the settings page: ![48279238-41f6a580-e450-11e8-84ad-cab7ac0f5c43](https://user-images.githubusercontent.com/7304212/48279354-a285e280-e450-11e8-8b5a-fdf3c63cc608.png) ![chrome_2018-11-09_18-47-47_0sc](https://user-images.githubusercontent.com/7304212/48279257-52a71b80-e450-11e8-85c5-a70c7d920f29.png)

OVERLORD commented

2026-02-04 22:41:59 +03:00

@pacroy commented on GitHub (Nov 9, 2018):

@HitomiTenshi I want to allow registration only thru the 3rd-party and disable the build-in one.

@pacroy commented on GitHub (Nov 9, 2018): @HitomiTenshi I want to allow registration only thru the 3rd-party and disable the build-in one.

OVERLORD commented

2026-02-04 22:42:06 +03:00

@HitomiTenshi commented on GitHub (Nov 9, 2018):

@pacroy See Automatic Registration & Email Confirmation in the Third Party Authentication page.

This will allow registration using these services even if registrations are disabled. It also allows registration if using LDAP as your main authentication option.

You'll have to edit your .env file to include this line:

{SERVICE}_AUTO_REGISTER=true

Replace {SERVICE} with your 3rd-party authentication service, e. g.:

GITLAB_AUTO_REGISTER=true

That way you can disable standard registration (email / password) in the settings and use the 3rd-party sign in button to automatically register the user. The user needs to confirm his email, but you can disable that as well and automatically accept the email provided by the 3rd-party authentication by adding another line to your .env file:

{SERVICE}_AUTO_CONFIRM_EMAIL=true

Replace {SERVICE} with your 3rd-party authentication service, e. g.:

GITLAB_AUTO_CONFIRM_EMAIL=true

The only thing that will remain is the standard login using email / password which I currently have to remove using the style I provided in my comment above.

@HitomiTenshi commented on GitHub (Nov 9, 2018): @pacroy See [Automatic Registration & Email Confirmation](https://www.bookstackapp.com/docs/admin/third-party-auth/#automatic-registration-email-confirmation) in the Third Party Authentication page. > This will allow registration using these services even if registrations are disabled. It also allows registration if using LDAP as your main authentication option. You'll have to edit your `.env` file to include this line: ``` {SERVICE}_AUTO_REGISTER=true ``` Replace `{SERVICE}` with your 3rd-party authentication service, e. g.: ``` GITLAB_AUTO_REGISTER=true ``` That way you can disable standard registration (email / password) in the settings and use the 3rd-party sign in button to automatically register the user. The user needs to confirm his email, but you can disable that as well and automatically accept the email provided by the 3rd-party authentication by adding another line to your `.env` file: ``` {SERVICE}_AUTO_CONFIRM_EMAIL=true ``` Replace `{SERVICE}` with your 3rd-party authentication service, e. g.: ``` GITLAB_AUTO_CONFIRM_EMAIL=true ``` The only thing that will remain is the standard login using email / password which I currently have to remove using the style I provided in my comment above.

OVERLORD commented

2026-02-04 22:42:10 +03:00

@ssddanbrown commented on GitHub (Nov 10, 2018):

Thank you very much @HitomiTenshi for your detailed instructions and work-arounds above.

@tuaris I've updated the title to be more specific of what needs to be implemented since the request in the previous title was already possible via the instructions posted above. Let me know if I'm mistaken though.

Implementation Notes

The following areas will need to updated to incorporate such a change:

Login & Registration front-end
Login & Registration back-end
User (Edit) profile page
"Forgot password" flow would need to be disabled

@ssddanbrown commented on GitHub (Nov 10, 2018): Thank you very much @HitomiTenshi for your detailed instructions and work-arounds above. @tuaris I've updated the title to be more specific of what needs to be implemented since the request in the previous title was already possible via the instructions posted above. Let me know if I'm mistaken though. ### Implementation Notes The following areas will need to updated to incorporate such a change: * Login & Registration front-end * Login & Registration back-end * User (Edit) profile page * "Forgot password" flow would need to be disabled

OVERLORD commented

2026-02-04 22:42:16 +03:00

@HitomiTenshi commented on GitHub (Nov 10, 2018):

@ssddanbrown "Forgot password" should be disabled, because it's clearly part of the standard email / password authentication. I would be confused seeing the forgot password flow on a site which I used 3rd-party authentication on.

@HitomiTenshi commented on GitHub (Nov 10, 2018): @ssddanbrown "Forgot password" should be disabled, because it's clearly part of the standard email / password authentication. I would be confused seeing the forgot password flow on a site which I used 3rd-party authentication on.

OVERLORD commented

2026-02-04 22:42:21 +03:00

@ssddanbrown commented on GitHub (Nov 10, 2018):

@HitomiTenshi Thanks for confirming that thought. I've updated my comment above to remove the question mark from that point.

@ssddanbrown commented on GitHub (Nov 10, 2018): @HitomiTenshi Thanks for confirming that thought. I've updated my comment above to remove the question mark from that point.

OVERLORD commented

2026-02-04 22:42:23 +03:00

@pacroy commented on GitHub (Nov 10, 2018):

@HitomiTenshi Thanks for that's very useful.
My scenario is:

First-time user can log on only with Social account
Existing user can log on with either Social account or username/password (if set)

Everything works fine now except user can change their email address in their profile. Is there a way to prevent from changing the email address?

@pacroy commented on GitHub (Nov 10, 2018): @HitomiTenshi Thanks for that's very useful. My scenario is: - First-time user can log on only with Social account - Existing user can log on with either Social account or username/password (if set) Everything works fine now except user can change their email address in their profile. Is there a way to prevent from changing the email address?

OVERLORD commented

2026-02-04 22:42:27 +03:00

@HitomiTenshi commented on GitHub (Nov 10, 2018):

@pacroy Currently there is no way to prevent the user from changing their email address. This could be a useful feature when using 3rd-party authentication. Although when the user changes their email in the 3rd-party site, it has to be synced somehow with bookstack.

I'd suggest creating a new issue for your feature reqeust "Prevent the user from changing their email when using OAuth".

@HitomiTenshi commented on GitHub (Nov 10, 2018): @pacroy Currently there is no way to prevent the user from changing their email address. This could be a useful feature when using 3rd-party authentication. Although when the user changes their email in the 3rd-party site, it has to be synced somehow with bookstack. I'd suggest creating a new issue for your feature reqeust "Prevent the user from changing their email when using OAuth".

OVERLORD commented

2026-02-04 22:42:29 +03:00

@gandarez commented on GitHub (Feb 20, 2019):

Need this feature either

@gandarez commented on GitHub (Feb 20, 2019): Need this feature either

OVERLORD commented

2026-02-04 22:42:31 +03:00

@nmehlei commented on GitHub (May 17, 2019):

Definitely would be useful as I have to keep reminding my users to use the button at the bottom and not the (more obvious / larger) login form.

@nmehlei commented on GitHub (May 17, 2019): Definitely would be useful as I have to keep reminding my users to use the button at the bottom and not the (more obvious / larger) login form.

OVERLORD commented

2026-02-04 22:42:35 +03:00

@prolane commented on GitHub (Nov 22, 2019):

If you sign in using an Oauth provider, you can't change your email address already, right? At least thats what I see using Google login.

Anyway, I'm looking forward to this feature as well. Its not just the password login and the 'forgot my password' options that would need switching off. Its also the ability to set a password on their profile page.

Thanks in advance!

@prolane commented on GitHub (Nov 22, 2019): If you sign in using an Oauth provider, you can't change your email address already, right? At least thats what I see using Google login. Anyway, I'm looking forward to this feature as well. Its not just the password login and the 'forgot my password' options that would need switching off. Its also the ability to set a password on their profile page. Thanks in advance!

OVERLORD commented

2026-02-04 22:42:38 +03:00

@gbuckingham89 commented on GitHub (Nov 24, 2021):

Hey @ssddanbrown!

I work for a web agency (local-ish to you, we're down in Bournemouth) and we recently stumbled across BookStack and are hoping to deploy it on behalf of one of our clients. They have some stricter than normal security requirements - and forcing social logins only (Google & Microsoft) is one of those.

It looks like this issue has been open for some time without much recent activity.

If we're in a position to do the work required and submit a PR, would you be wiling to merging such a PR?

Do you have any thoughts / opinions on how this should be implemented - or are you open to suggestions?

Thanks.

@gbuckingham89 commented on GitHub (Nov 24, 2021): Hey @ssddanbrown! I work for a web agency _(local-ish to you, we're down in Bournemouth)_ and we recently stumbled across BookStack and are hoping to deploy it on behalf of one of our clients. They have some stricter than normal security requirements - and forcing social logins only (Google & Microsoft) is one of those. It looks like this issue has been open for some time without much recent activity. If we're in a position to do the work required and submit a PR, would you be wiling to merging such a PR? Do you have any thoughts / opinions on how this should be implemented - or are you open to suggestions? Thanks.

OVERLORD commented

2026-02-04 22:42:40 +03:00

@ssddanbrown commented on GitHub (Nov 24, 2021):

Hi @gbuckingham89, Yeah, I have no real desire to work on this myself but I would accept a suitable PR request for such feature.

I'd generally want any implementations to be relatively option/logic-branch free, and simple, to ease maintenance. The only thing I'd expect should be required is setting AUTH_METHOD="" in the .env from an instance admin perspective (Or something along those lines). The trouble I've had before is thinking about recovery scenarios (How does a user or admin recover access if no other login option is present) where needed. Just edge cases like that need to be thought about. Ideally I'd want tests added within the PR.

@ssddanbrown commented on GitHub (Nov 24, 2021): Hi @gbuckingham89, Yeah, I have no real desire to work on this myself but I would accept a suitable PR request for such feature. I'd generally want any implementations to be relatively option/logic-branch free, and simple, to ease maintenance. The only thing I'd expect should be required is setting `AUTH_METHOD=""` in the `.env` from an instance admin perspective (Or something along those lines). The trouble I've had before is thinking about recovery scenarios (How does a user or admin recover access if no other login option is present) where needed. Just edge cases like that need to be thought about. Ideally I'd want tests added within the PR.

OVERLORD commented

2026-02-04 22:42:42 +03:00

@androbey commented on GitHub (Jan 11, 2022):

Hi all,

just wanted to add another small workaround to hide normal login form using the theme system. Maybe someone will find it useful.

Using the visual theme system you could override login.blade.php.
For example your updated component could wrap the form include in an if statement.

@includeWhen(app('request')->input('form') , 'auth.parts.login-form-' . $authMethod)

This hides the normal login form, but allows e.g. admin to still login via email/password if they specify URL param "form" ("https://mybookstack.com/login?form=1").

@androbey commented on GitHub (Jan 11, 2022): Hi all, just wanted to add another small workaround to hide normal login form using the theme system. Maybe someone will find it useful. Using the visual theme system you could override `login.blade.php`. For example your updated component could wrap the form include in an if statement. ``` @includeWhen(app('request')->input('form') , 'auth.parts.login-form-' . $authMethod) ``` This hides the normal login form, but allows e.g. admin to still login via email/password if they specify URL param "form" ("https://mybookstack.com/login?form=1").

OVERLORD commented

2026-02-04 22:42:53 +03:00

@kelvinq commented on GitHub (Jan 23, 2022):

Inspired by @pacroy, to ensure that users only use Google for registration and authentication/login, I added the following lines in "Custom HTML Head Content":

`<style>
form[action$="register"] {
display: none;
}

form[action$="login"] {
display: none;
}
</style>`

Just in case this is helpful for you.

@kelvinq commented on GitHub (Jan 23, 2022): Inspired by @pacroy, to ensure that users only use Google for registration and authentication/login, I added the following lines in "Custom HTML Head Content": `<style> form[action$="register"] { display: none; } form[action$="login"] { display: none; } </style>` <img width="728" alt="Screenshot 2022-01-23 at 11 37 42 AM" src="https://user-images.githubusercontent.com/15867/150663830-cc9c6288-8d5d-4657-a6d4-95d2f7aac700.png"> Just in case this is helpful for you.

OVERLORD commented

2026-02-04 22:42:56 +03:00

@cody0704 commented on GitHub (Nov 8, 2022):

Inspired by @pacroy, to ensure that users only use Google for registration and authentication/login, I added the following lines in "Custom HTML Head Content":

`<style> form[action$="register"] { display: none; }

form[action$="login"] { display: none; } </style>`

Just in case this is helpful for you.

Use your settings and cooperate with Nginx's settings to disable account and password login perfectly

Through the Nginx access log, it is found that the account and password login is through POST, while the third-party social login only uses GET

So I disabled login POST via Nginx

Nginx Config

...
location /login {
        if ($request_method = POST ) {
            return 444;
        }

        try_files $uri $uri/ /index.php?$query_string;
}
...

After testing, it is confirmed that the account and password login will return http code 444, and the third-party social login is normal.

@cody0704 commented on GitHub (Nov 8, 2022): > Inspired by @pacroy, to ensure that users only use Google for registration and authentication/login, I added the following lines in "Custom HTML Head Content": > > `<style> form[action$="register"] { display: none; } > > form[action$="login"] { display: none; } </style>` > > <img alt="Screenshot 2022-01-23 at 11 37 42 AM" width="728" src="https://user-images.githubusercontent.com/15867/150663830-cc9c6288-8d5d-4657-a6d4-95d2f7aac700.png"> > > Just in case this is helpful for you. Use your settings and cooperate with Nginx's settings to disable account and password login perfectly Through the Nginx access log, it is found that the account and password login is through POST, while the third-party social login only uses GET So I disabled login POST via Nginx * Nginx Config ```nginx ... location /login { if ($request_method = POST ) { return 444; } try_files $uri $uri/ /index.php?$query_string; } ... ``` After testing, it is confirmed that the account and password login will return http code 444, and the third-party social login is normal.

OVERLORD commented

2026-02-04 22:43:00 +03:00

@jhaisley commented on GitHub (Jan 28, 2023):

Inspired by @pacroy, to ensure that users only use Google for registration and authentication/login, I added the following lines in "Custom HTML Head Content":
<style> form[action$="register"] { display: none; } form[action$="login"] { display: none; } </style>

Just in case this is helpful for you.

Use your settings and cooperate with Nginx's settings to disable account and password login perfectly

Through the Nginx access log, it is found that the account and password login is through POST, while the third-party social login only uses GET

So I disabled login POST via Nginx

Nginx Config
...
location /login {
        if ($request_method = POST ) {
            return 444;
        }

        try_files $uri $uri/ /index.php?$query_string;
}
...
After testing, it is confirmed that the account and password login will return http code 444, and the third-party social login is normal.

You may want to update this to code http 405, which would mean that POST isn't allowed but GET is fine.

@jhaisley commented on GitHub (Jan 28, 2023): > > Inspired by @pacroy, to ensure that users only use Google for registration and authentication/login, I added the following lines in "Custom HTML Head Content": > > `<style> form[action$="register"] { display: none; } > > form[action$="login"] { display: none; } </style>` > > <img alt="Screenshot 2022-01-23 at 11 37 42 AM" width="728" src="https://user-images.githubusercontent.com/15867/150663830-cc9c6288-8d5d-4657-a6d4-95d2f7aac700.png"> > > Just in case this is helpful for you. > > Use your settings and cooperate with Nginx's settings to disable account and password login perfectly > > Through the Nginx access log, it is found that the account and password login is through POST, while the third-party social login only uses GET > > So I disabled login POST via Nginx > > * Nginx Config > > ```nginx > ... > location /login { > if ($request_method = POST ) { > return 444; > } > > try_files $uri $uri/ /index.php?$query_string; > } > ... > ``` > > After testing, it is confirmed that the account and password login will return http code 444, and the third-party social login is normal. You may want to update this to code http 405, which would mean that POST isn't allowed but GET is fine.

OVERLORD commented

2026-02-04 22:43:03 +03:00

@e3ndr commented on GitHub (Jun 6, 2023):

We use bookstack for internal company documentation (and it's great!), we've disabled registrations and I added the following custom head content to hide the email/password form from the login page:

<style>
#login-form {
  display: none; /* Use SSO instead. */
}
</style>
<script>
  console.log("Login form hidden, if you _really_ need it then run iNeedLoginsNow()");
  function iNeedLoginsNow() {
   document.querySelector("#login-form").style.display = "block"; 
  }
</script>

@e3ndr commented on GitHub (Jun 6, 2023): We use bookstack for internal company documentation (and it's great!), we've disabled registrations and I added the following custom head content to hide the email/password form from the login page: ```html <style> #login-form { display: none; /* Use SSO instead. */ } </style> <script> console.log("Login form hidden, if you _really_ need it then run iNeedLoginsNow()"); function iNeedLoginsNow() { document.querySelector("#login-form").style.display = "block"; } </script> ```

OVERLORD referenced this issue

2026-02-05 02:46:22 +03:00

Include video upload in 'insert/edit media' panel #2060

OVERLORD referenced this issue

2026-02-05 03:41:26 +03:00

Embedded Video wont play / Video upload as attachment fails #2327

OVERLORD referenced this issue

2026-02-05 04:44:31 +03:00

[Feature Request]: Video scrubbing #2661

Sign in to join this conversation.