SIGNUPS_ALLOWED not stopping new user creation #1128

New Issue

OVERLORD · 2026-02-04T23:58:45+03:00

OVERLORD commented

2026-02-04 23:58:45 +03:00

Originally created by @JBFUK on GitHub (Oct 8, 2021).

Subject of the issue

SIGNUPS_ALLOWED not stopping new user creation

Deployment environment

Latest Docker Image

Install method: Docker Compose
Clients used: Web-Vault
Reverse proxy and version: Nginx
MySQL/MariaDB or PostgreSQL version: MariaDB
Other relevant details:

Steps to reproduce

Set environment variable SIGNUPS_ALLOWED=false via docker-compose file

Expected behaviour

Expect new user creation from the main login page to fail with an error (as described in WIKI)

Actual behaviour

Allows new user creation and subsequent login

Originally created by @JBFUK on GitHub (Oct 8, 2021). ### Subject of the issue SIGNUPS_ALLOWED not stopping new user creation ### Deployment environment Latest Docker Image * Install method: Docker Compose * Clients used: Web-Vault * Reverse proxy and version: Nginx * MySQL/MariaDB or PostgreSQL version: MariaDB * Other relevant details: ### Steps to reproduce Set environment variable SIGNUPS_ALLOWED=false via docker-compose file ### Expected behaviour Expect new user creation from the main login page to fail with an error (as described in WIKI) ### Actual behaviour Allows new user creation and subsequent login

OVERLORD closed this issue

2026-02-04 23:58:46 +03:00

OVERLORD commented

2026-02-04 23:58:48 +03:00

@jjlin commented on GitHub (Oct 8, 2021):

You probably have SIGNUPS_DOMAINS_WHITELIST set as well.

See https://github.com/dani-garcia/vaultwarden/wiki/Disable-registration-of-new-users#restricting-registrations-to-certain-email-domains.

@jjlin commented on GitHub (Oct 8, 2021): You probably have `SIGNUPS_DOMAINS_WHITELIST` set as well. See https://github.com/dani-garcia/vaultwarden/wiki/Disable-registration-of-new-users#restricting-registrations-to-certain-email-domains.

OVERLORD commented

2026-02-04 23:58:55 +03:00

@pepa65 commented on GitHub (Oct 8, 2021):

So we have SIGNUPS_ALLOWED [S], INVITATIONS_ALLOWED [I], and SIGNUPS_DOMAINS_WHITELIST [W] all interacting with each other:

S I W Result
0 0 0 Self-signup and Invititations impossible
0 0 1 Self-signup and Invititations impossible
0 1 0 Invititations possible, unlimited
0 1 1 Invititations possible, limited by the Whitelist
1 0 0 Self-signup possible, unlimited
1 0 1 Self-signup possible, limited by the Whitelist
1 1 0 Self-signup and Invititations possible, unlimited
1 1 1 Self-signup and Invititations possible, limited by the Whitelist

The above is what makes logical sense. But you're saying that currently when SIGNUPS_DOMAINS_WHITELIST is set, it is like "Self-signup and Invititations possible, limited by the Whitelist"? If so, wouldn't it make sense to see that as a bug, and fix it??

@pepa65 commented on GitHub (Oct 8, 2021): So we have SIGNUPS_ALLOWED [S], INVITATIONS_ALLOWED [I], and SIGNUPS_DOMAINS_WHITELIST [W] all interacting with each other: S I W Result 0 0 0 Self-signup and Invititations impossible 0 0 1 Self-signup and Invititations impossible 0 1 0 Invititations possible, unlimited 0 1 1 Invititations possible, limited by the Whitelist 1 0 0 Self-signup possible, unlimited 1 0 1 Self-signup possible, limited by the Whitelist 1 1 0 Self-signup and Invititations possible, unlimited 1 1 1 Self-signup and Invititations possible, limited by the Whitelist The above is what makes logical sense. But you're saying that currently when SIGNUPS_DOMAINS_WHITELIST is set, it is like "Self-signup and Invititations possible, limited by the Whitelist"? If so, wouldn't it make sense to see that as a bug, and fix it??

OVERLORD commented

2026-02-04 23:58:57 +03:00

@jjlin commented on GitHub (Oct 8, 2021):

These settings were implemented by different people at different times, so the design is not always the most cohesive.

SIGNUPS_DOMAINS_WHITELIST is documented as

9930a0d752/.env.template (L179-L181)

The original implementation required SIGNUPS_ALLOWED=false to be set. Since the default is SIGNUPS_ALLOWED=true, a quite common issue was to set only SIGNUPS_DOMAINS_WHITELIST and expect that to limit the signups, which wasn't how it worked. So later SIGNUPS_DOMAINS_WHITELIST was changed to simply override SIGNUPS_ALLOWED, because why would you set SIGNUPS_DOMAINS_WHITELIST if you didn't expect that to control signups?

With this, you could think of it either as "signups allowed, but only from these domains" or "signups not allowed, except from these domains", both of which seem like logical interpretations to me.

If you're interested in proposing and implementing another design that is still backward compatible, feel free.

@jjlin commented on GitHub (Oct 8, 2021): These settings were implemented by different people at different times, so the design is not always the most cohesive. `SIGNUPS_DOMAINS_WHITELIST` is documented as https://github.com/dani-garcia/vaultwarden/blob/9930a0d75224202dbc355e945724aa545bedebe2/.env.template#L179-L181 The original implementation required `SIGNUPS_ALLOWED=false` to be set. Since the default is `SIGNUPS_ALLOWED=true`, a quite common issue was to set only `SIGNUPS_DOMAINS_WHITELIST` and expect that to limit the signups, which wasn't how it worked. So later `SIGNUPS_DOMAINS_WHITELIST` was changed to simply override `SIGNUPS_ALLOWED`, because why would you set `SIGNUPS_DOMAINS_WHITELIST` if you didn't expect that to control signups? With this, you could think of it either as "signups allowed, but only from these domains" or "signups not allowed, except from these domains", both of which seem like logical interpretations to me. If you're interested in proposing and implementing another design that is still backward compatible, feel free.

OVERLORD commented

2026-02-04 23:59:02 +03:00

@pepa65 commented on GitHub (Oct 8, 2021):

Backward compatible meaning: we keep the same variables and the current results need to stay as they are? And then introduce new variables to attain the same range of outcomes more sensibly??

I think the outcomes I listed are fairly useful, and with the 3 boolean variables, there are only 2 outcomes that are overlapping, ie. if SIGNUPS_ALLOWED [S] and INVITATIONS_ALLOWED are both false, the value of SIGNUPS_DOMAINS_WHITELIST is irrelevant, and that makes sense.

@jjlin My proposal would be along the lines of the list of outcomes in my previous post. Do you think that is workable?

@pepa65 commented on GitHub (Oct 8, 2021): Backward compatible meaning: we keep the same variables and the current results need to stay as they are? And then introduce new variables to attain the same range of outcomes more sensibly?? I think the outcomes I listed are fairly useful, and with the 3 boolean variables, there are only 2 outcomes that are overlapping, ie. if SIGNUPS_ALLOWED [S] and INVITATIONS_ALLOWED are both false, the value of SIGNUPS_DOMAINS_WHITELIST is irrelevant, and that makes sense. @jjlin My proposal would be along the lines of the list of outcomes in my previous post. Do you think that is workable?

OVERLORD commented

2026-02-04 23:59:06 +03:00

@jjlin commented on GitHub (Oct 8, 2021):

I would say backward compatible means something that is expected to remain working for the vast majority of existing deployments.

Given the existing constraints and the fact that people can achieve the desired results if they read the docs, I'm not sure polishing this a lot is worth the effort, and it's not work I'm personally interested in. But other people who feel strongly about it are certainly welcome to step up.

@jjlin commented on GitHub (Oct 8, 2021): I would say backward compatible means something that is expected to remain working for the vast majority of existing deployments. Given the existing constraints and the fact that people can achieve the desired results if they read the docs, I'm not sure polishing this a lot is worth the effort, and it's not work I'm personally interested in. But other people who feel strongly about it are certainly welcome to step up.

OVERLORD commented

2026-02-04 23:59:07 +03:00

@pepa65 commented on GitHub (Oct 8, 2021):

I guess the bug reporter here would need to set all 3 to FALSE to achieve his desired outcome.

I all desired outcomes are already achievable, we can let this rest, until someone want to achieve something that the current setup does not cater to. Example: wanting to allow invitations that are limited to the whitelist but no self-signup. Then it could be fixed, but warn people with existing installations that Vaultwarden got a bit more specific.

@pepa65 commented on GitHub (Oct 8, 2021): I guess the bug reporter here would need to set all 3 to FALSE to achieve his desired outcome. I all desired outcomes are already achievable, we can let this rest, until someone want to achieve something that the current setup does not cater to. Example: wanting to allow invitations that are limited to the whitelist but no self-signup. Then it could be fixed, but warn people with existing installations that Vaultwarden got a bit more specific.

OVERLORD commented

2026-02-04 23:59:12 +03:00

@BlackDex commented on GitHub (Oct 8, 2021):

There is no reason to set a whitelist and not have it able to allow signups or invites for that domain. If that is what someone intends to achieve then they need to clear all and add users manually via the admin interface. Setting the whitelist is as @jjlin already mentioned is a kind of boolean flag for SIGNUPS_ALLOWED at the same time.

I am also not interested into trying to iron this. It will probably break, and i also don't like adding more and more variables, that would make it even worse i think.

@BlackDex commented on GitHub (Oct 8, 2021): There is no reason to set a whitelist and not have it able to allow signups or invites for that domain. If that is what someone intends to achieve then they need to clear all and add users manually via the admin interface. Setting the whitelist is as @jjlin already mentioned is a kind of boolean flag for SIGNUPS_ALLOWED at the same time. I am also not interested into trying to iron this. It will probably break, and i also don't like adding more and more variables, that would make it even worse i think.

OVERLORD commented

2026-02-04 23:59:18 +03:00

@JBFUK commented on GitHub (Oct 8, 2021):

This is all I have sent for the vaultwarden container:

 environment:
   - "DATABASE_URL=mysql://${MYSQL_USER}:${MYSQL_PASSWORD}@mariadb/${MYSQL_DATABASE}"
   - "ADMIN_TOKEN=${ADMIN_TOKEN}"
   - "RUST_BACKTRACE=1"
   - "SIGNUPS_ALLOWED=false"

What I want is to allow invitations and users to sign up IF they are invited (regardless of domain) but to prevent Joe Public who just happened to find his way to my vault login page from signing up uninvited.

My understanding from the WIKI was that setting "SIGNUPS_ALLOWED=false" would achieve this.

@JBFUK commented on GitHub (Oct 8, 2021): This is all I have sent for the vaultwarden container: ``` environment: - "DATABASE_URL=mysql://${MYSQL_USER}:${MYSQL_PASSWORD}@mariadb/${MYSQL_DATABASE}" - "ADMIN_TOKEN=${ADMIN_TOKEN}" - "RUST_BACKTRACE=1" - "SIGNUPS_ALLOWED=false" ``` What I want is to allow invitations and users to sign up IF they are invited (regardless of domain) but to prevent Joe Public who just happened to find his way to my vault login page from signing up uninvited. My understanding from the WIKI was that setting "SIGNUPS_ALLOWED=false" would achieve this.

OVERLORD commented

2026-02-04 23:59:21 +03:00

@BlackDex commented on GitHub (Oct 8, 2021):

Did you do a docker-compose up -d after you modified it?
If not, these changes didn't had any effect.

Please go to /admin/diagnostics and generate a support string there, so that we can see the running config.

@BlackDex commented on GitHub (Oct 8, 2021): Did you do a `docker-compose up -d` after you modified it? If not, these changes didn't had any effect. Please go to `/admin/diagnostics` and generate a support string there, so that we can see the running config.

OVERLORD commented

2026-02-04 23:59:25 +03:00

@JBFUK commented on GitHub (Oct 8, 2021):

Yes I did. I actually did a docker-compose down followed by docker-compose up -d.

What I have noticed is that the https://myvault/admin/ interface under 'General Settings' shows signups allowed. I'm just going to try disabling from there to see whether that works. If so then it seems like the ENV variable is not being applied and/or overriding the admin setting?

[EDIT]

Confirmed, it works fine with signups disabled via the admin UI. Do you still want a support string dump?

@JBFUK commented on GitHub (Oct 8, 2021): Yes I did. I actually did a `docker-compose down` followed by `docker-compose up -d`. What I have noticed is that the https://myvault/admin/ interface under 'General Settings' shows signups allowed. I'm just going to try disabling from there to see whether that works. If so then it seems like the ENV variable is not being applied and/or overriding the admin setting? [EDIT] Confirmed, it works fine with signups disabled via the admin UI. Do you still want a support string dump?

OVERLORD commented

2026-02-04 23:59:31 +03:00

@BlackDex commented on GitHub (Oct 8, 2021):

I think you actually need to change your docker-compose file.

environment:
  - TZ=UTC
  - DOMAIN=https://my.domain.tld
  - SIGNUPS_ALLOWED=false
  - ADMIN_TOKEN=${SECRET_ADMIN_TOKEN}
  - RUST_BACKTRACE=1

You have quotes " around the whole values, i think that breaks it in some way.
And i even think it is not using MySQL this way, but that I'm not sure.

@BlackDex commented on GitHub (Oct 8, 2021): I think you actually need to change your docker-compose file. ```yml environment: - TZ=UTC - DOMAIN=https://my.domain.tld - SIGNUPS_ALLOWED=false - ADMIN_TOKEN=${SECRET_ADMIN_TOKEN} - RUST_BACKTRACE=1 ``` You have quotes `"` around the whole values, i think that breaks it in some way. And i even think it is not using MySQL this way, but that I'm not sure.

OVERLORD commented

2026-02-04 23:59:33 +03:00

@JBFUK commented on GitHub (Oct 8, 2021):

The admin token takes effect and database is working fine.

I take the point about the quotes around the variables. Usually I would not have these but in the interest of 'following the instructions' fully I included them - as this is what the vaultwarden wiki shows in its example docker-compose template [Here].

@JBFUK commented on GitHub (Oct 8, 2021): The admin token takes effect and database is working fine. I take the point about the quotes around the variables. Usually I would not have these but in the interest of 'following the instructions' fully I included them - as this is what the vaultwarden wiki shows in its example docker-compose template[ [Here].](https://github.com/dani-garcia/vaultwarden/wiki/Using-the-MariaDB-%28MySQL%29-Backend)

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/vaultwarden#1128