[GH-ISSUE #6109] Invited user signup while new user signup is disabled - Cannot easily access signup page when there is no SMTP #19115

Closed
opened 2026-04-25 21:32:57 -05:00 by GiteaMirror · 4 comments
Owner

Originally created by @anhyzer5525 on GitHub (Jul 28, 2025).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/6109

Prerequisites

Vaultwarden Support String

Your environment (Generated via diagnostics page)

  • Vaultwarden version: v1.34.2
  • Web-vault version: v2025.7.0
  • OS/Arch: linux/x86_64
  • Running within a container: true (Base: Debian)
  • Database type: SQLite
  • Database version: 3.50.2
  • Uses config.json: false
  • Uses a reverse proxy: true
  • IP Header check: true (X-Real-IP)
  • Internet access: true
  • Internet access via a proxy: false
  • DNS Check: true
  • Browser/Server Time Check: true
  • Server/NTP Time Check: true
  • Domain Configuration Check: true
  • HTTPS Check: true
  • Websocket Check: true
  • HTTP Response Checks: true

Config & Details (Generated via diagnostics page)

Show Config & Details

Config:

{
  "_duo_akey": null,
  "_enable_duo": true,
  "_enable_email_2fa": false,
  "_enable_smtp": false,
  "_enable_yubico": false,
  "_icon_service_csp": "",
  "_icon_service_url": "",
  "_ip_header_enabled": true,
  "_max_note_size": 10000,
  "_smtp_img_src": "***:",
  "admin_ratelimit_max_burst": 3,
  "admin_ratelimit_seconds": 300,
  "admin_session_lifetime": 20,
  "admin_token": "***",
  "allowed_connect_src": "",
  "allowed_iframe_ancestors": "",
  "attachments_folder": "data/attachments",
  "auth_request_purge_schedule": "30 * * * * *",
  "authenticator_disable_time_drift": false,
  "data_folder": "data",
  "database_conn_init": "",
  "database_max_conns": 10,
  "database_timeout": 30,
  "database_url": "***************",
  "db_connection_retries": 15,
  "disable_2fa_remember": false,
  "disable_admin_token": false,
  "disable_icon_download": false,
  "domain": "*****://************************",
  "domain_origin": "*****://************************",
  "domain_path": "",
  "domain_set": true,
  "duo_context_purge_schedule": "30 * * * * *",
  "duo_host": "api-c6e39a45.duosecurity.com",
  "duo_ikey": "DIA6ADA039JS6RWVKY4R",
  "duo_skey": "***",
  "duo_use_iframe": false,
  "email_2fa_auto_fallback": false,
  "email_2fa_enforce_on_verified_invite": false,
  "email_attempts_limit": 3,
  "email_change_allowed": true,
  "email_expiration_time": 600,
  "email_token_size": 6,
  "emergency_access_allowed": true,
  "emergency_notification_reminder_schedule": "0 3 * * * *",
  "emergency_request_timeout_schedule": "0 7 * * * *",
  "enable_db_wal": true,
  "enable_websocket": true,
  "enforce_single_org_with_reset_pw_policy": false,
  "event_cleanup_schedule": "0 10 0 * * *",
  "events_days_retain": 30,
  "experimental_client_feature_flags": "",
  "extended_logging": true,
  "helo_name": null,
  "hibp_api_key": null,
  "http_request_block_non_global_ips": true,
  "http_request_block_regex": null,
  "icon_blacklist_non_global_ips": true,
  "icon_blacklist_regex": null,
  "icon_cache_folder": "data/icon_cache",
  "icon_cache_negttl": 259200,
  "icon_cache_ttl": 2592000,
  "icon_download_timeout": 10,
  "icon_redirect_code": 302,
  "icon_service": "internal",
  "incomplete_2fa_schedule": "30 * * * * *",
  "incomplete_2fa_time_limit": 3,
  "increase_note_size_limit": false,
  "invitation_expiration_hours": 120,
  "invitation_org_name": "Vaultwarden",
  "invitations_allowed": true,
  "ip_header": "X-Real-IP",
  "job_poll_interval_ms": 30000,
  "log_file": null,
  "log_level": "info",
  "log_timestamp_format": "%Y-%m-%d %H:%M:%S.%3f",
  "login_ratelimit_max_burst": 10,
  "login_ratelimit_seconds": 60,
  "org_attachment_limit": null,
  "org_creation_users": "*********************,***********************",
  "org_events_enabled": true,
  "org_groups_enabled": false,
  "password_hints_allowed": false,
  "password_iterations": 600000,
  "push_enabled": true,
  "push_identity_uri": "https://identity.bitwarden.eu",
  "push_installation_id": "***",
  "push_installation_key": "***",
  "push_relay_uri": "https://api.bitwarden.eu",
  "reload_templates": false,
  "require_device_email": false,
  "rsa_key_filename": "data/rsa_key",
  "send_purge_schedule": "0 5 * * * *",
  "sendmail_command": null,
  "sends_allowed": true,
  "sends_folder": "data/sends",
  "show_password_hint": false,
  "signups_allowed": false,
  "signups_domains_whitelist": "",
  "signups_verify": false,
  "signups_verify_resend_limit": 6,
  "signups_verify_resend_time": 3600,
  "smtp_accept_invalid_certs": false,
  "smtp_accept_invalid_hostnames": false,
  "smtp_auth_mechanism": null,
  "smtp_debug": false,
  "smtp_embed_images": true,
  "smtp_explicit_tls": null,
  "smtp_from": "*********************",
  "smtp_from_name": "Vaultwarden",
  "smtp_host": "******************************************",
  "smtp_password": null,
  "smtp_port": 25,
  "smtp_security": "off",
  "smtp_ssl": null,
  "smtp_timeout": 15,
  "smtp_username": null,
  "templates_folder": "data/templates",
  "tmp_folder": "data/tmp",
  "trash_auto_delete_days": 30,
  "trash_purge_schedule": "0 5 0 * * *",
  "use_sendmail": false,
  "use_syslog": false,
  "user_attachment_limit": null,
  "user_send_limit": null,
  "web_vault_enabled": true,
  "web_vault_folder": "web-vault/",
  "yubico_client_id": null,
  "yubico_secret_key": null,
  "yubico_server": null
}

Vaultwarden Build Version

1.34.2

Deployment method

Official Container Image

Custom deployment method

No response

Reverse Proxy

haproxy 2.9.14-7c591d5

Host/Server Operating System

Linux

Operating System Version

Ubuntu 24.04

Clients

Web Vault

Client Version

2025.7.0

Steps To Reproduce

  1. Login to vaultwarden admin panel
  2. Settings > General Settings > Uncheck "Allow new signups" & Save
  3. Settings > SMTP Email Settings > Uncheck "Enabled"
  4. Users > Type in an email address to invite user & click invite
  5. Open browser and navigate to your vaultwarden webpage

Expected Result

Expected behavior without SMTP functionality:

  1. Signup link on the login page to be accessible even when new user signups are disabled.

Actual Result

No signup link on login page is present and the only way to access the signup page is by modifying the URL in your browser. The URL looks like https://yourdomainname.com/#/signup

Logs


Screenshots or Videos

Image

Additional Context

No response

Originally created by @anhyzer5525 on GitHub (Jul 28, 2025). Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/6109 ### Prerequisites - [x] I have searched the existing **Closed _AND_ Open** [Issues](https://github.com/dani-garcia/vaultwarden/issues?q=is%3Aissue%20) **_AND_** [Discussions](https://github.com/dani-garcia/vaultwarden/discussions?discussions_q=) - [x] I have searched and read the [documentation](https://github.com/dani-garcia/vaultwarden/wiki/) ### Vaultwarden Support String ### Your environment (Generated via diagnostics page) * Vaultwarden version: v1.34.2 * Web-vault version: v2025.7.0 * OS/Arch: linux/x86_64 * Running within a container: true (Base: Debian) * Database type: SQLite * Database version: 3.50.2 * Uses config.json: false * Uses a reverse proxy: true * IP Header check: true (X-Real-IP) * Internet access: true * Internet access via a proxy: false * DNS Check: true * Browser/Server Time Check: true * Server/NTP Time Check: true * Domain Configuration Check: true * HTTPS Check: true * Websocket Check: true * HTTP Response Checks: true ### Config & Details (Generated via diagnostics page) <details><summary>Show Config & Details</summary> **Config:** ```json { "_duo_akey": null, "_enable_duo": true, "_enable_email_2fa": false, "_enable_smtp": false, "_enable_yubico": false, "_icon_service_csp": "", "_icon_service_url": "", "_ip_header_enabled": true, "_max_note_size": 10000, "_smtp_img_src": "***:", "admin_ratelimit_max_burst": 3, "admin_ratelimit_seconds": 300, "admin_session_lifetime": 20, "admin_token": "***", "allowed_connect_src": "", "allowed_iframe_ancestors": "", "attachments_folder": "data/attachments", "auth_request_purge_schedule": "30 * * * * *", "authenticator_disable_time_drift": false, "data_folder": "data", "database_conn_init": "", "database_max_conns": 10, "database_timeout": 30, "database_url": "***************", "db_connection_retries": 15, "disable_2fa_remember": false, "disable_admin_token": false, "disable_icon_download": false, "domain": "*****://************************", "domain_origin": "*****://************************", "domain_path": "", "domain_set": true, "duo_context_purge_schedule": "30 * * * * *", "duo_host": "api-c6e39a45.duosecurity.com", "duo_ikey": "DIA6ADA039JS6RWVKY4R", "duo_skey": "***", "duo_use_iframe": false, "email_2fa_auto_fallback": false, "email_2fa_enforce_on_verified_invite": false, "email_attempts_limit": 3, "email_change_allowed": true, "email_expiration_time": 600, "email_token_size": 6, "emergency_access_allowed": true, "emergency_notification_reminder_schedule": "0 3 * * * *", "emergency_request_timeout_schedule": "0 7 * * * *", "enable_db_wal": true, "enable_websocket": true, "enforce_single_org_with_reset_pw_policy": false, "event_cleanup_schedule": "0 10 0 * * *", "events_days_retain": 30, "experimental_client_feature_flags": "", "extended_logging": true, "helo_name": null, "hibp_api_key": null, "http_request_block_non_global_ips": true, "http_request_block_regex": null, "icon_blacklist_non_global_ips": true, "icon_blacklist_regex": null, "icon_cache_folder": "data/icon_cache", "icon_cache_negttl": 259200, "icon_cache_ttl": 2592000, "icon_download_timeout": 10, "icon_redirect_code": 302, "icon_service": "internal", "incomplete_2fa_schedule": "30 * * * * *", "incomplete_2fa_time_limit": 3, "increase_note_size_limit": false, "invitation_expiration_hours": 120, "invitation_org_name": "Vaultwarden", "invitations_allowed": true, "ip_header": "X-Real-IP", "job_poll_interval_ms": 30000, "log_file": null, "log_level": "info", "log_timestamp_format": "%Y-%m-%d %H:%M:%S.%3f", "login_ratelimit_max_burst": 10, "login_ratelimit_seconds": 60, "org_attachment_limit": null, "org_creation_users": "*********************,***********************", "org_events_enabled": true, "org_groups_enabled": false, "password_hints_allowed": false, "password_iterations": 600000, "push_enabled": true, "push_identity_uri": "https://identity.bitwarden.eu", "push_installation_id": "***", "push_installation_key": "***", "push_relay_uri": "https://api.bitwarden.eu", "reload_templates": false, "require_device_email": false, "rsa_key_filename": "data/rsa_key", "send_purge_schedule": "0 5 * * * *", "sendmail_command": null, "sends_allowed": true, "sends_folder": "data/sends", "show_password_hint": false, "signups_allowed": false, "signups_domains_whitelist": "", "signups_verify": false, "signups_verify_resend_limit": 6, "signups_verify_resend_time": 3600, "smtp_accept_invalid_certs": false, "smtp_accept_invalid_hostnames": false, "smtp_auth_mechanism": null, "smtp_debug": false, "smtp_embed_images": true, "smtp_explicit_tls": null, "smtp_from": "*********************", "smtp_from_name": "Vaultwarden", "smtp_host": "******************************************", "smtp_password": null, "smtp_port": 25, "smtp_security": "off", "smtp_ssl": null, "smtp_timeout": 15, "smtp_username": null, "templates_folder": "data/templates", "tmp_folder": "data/tmp", "trash_auto_delete_days": 30, "trash_purge_schedule": "0 5 0 * * *", "use_sendmail": false, "use_syslog": false, "user_attachment_limit": null, "user_send_limit": null, "web_vault_enabled": true, "web_vault_folder": "web-vault/", "yubico_client_id": null, "yubico_secret_key": null, "yubico_server": null } ``` </details> ### Vaultwarden Build Version 1.34.2 ### Deployment method Official Container Image ### Custom deployment method _No response_ ### Reverse Proxy haproxy 2.9.14-7c591d5 ### Host/Server Operating System Linux ### Operating System Version Ubuntu 24.04 ### Clients Web Vault ### Client Version 2025.7.0 ### Steps To Reproduce 1. Login to vaultwarden admin panel 2. Settings > General Settings > Uncheck "Allow new signups" & Save 3. Settings > SMTP Email Settings > Uncheck "Enabled" 4. Users > Type in an email address to invite user & click invite 5. Open browser and navigate to your vaultwarden webpage ### Expected Result Expected behavior without SMTP functionality: 1. Signup link on the login page to be accessible even when new user signups are disabled. ### Actual Result No signup link on login page is present and the only way to access the signup page is by modifying the URL in your browser. The URL looks like https://yourdomainname.com/#/signup ### Logs ```text ``` ### Screenshots or Videos <img width="1040" height="617" alt="Image" src="https://github.com/user-attachments/assets/3962503f-2eb9-4304-bbd8-5dd27a442c74" /> ### Additional Context _No response_
GiteaMirror added the bug label 2026-04-25 21:32:57 -05:00
Author
Owner

@stefan0xC commented on GitHub (Jul 28, 2025):

Well, I kinda disagree that this should be the case because when signup is disabled that means that random visitors should not see the form and thus the link should not be shown by the client due to a server setting. For this to work we would have to tell the client that the setting disableUserRegistration should be false even though we have actually disabled it.

0db4b00007/src/api/core/mod.rs (L227-L229)

While technically we could change this so this also takes into account if mail is disabled and invitations are allowed as to make an exception for that case (because in general this should stay disabled if mail is enabled because then an invitation link is sent), I do think that adding the correct URI fragment to the URL (/#/signup) is easy enough that the current behavior does not need to be changed.

Maybe we could add a page in the wiki for a better documentation because there are a few others things that don't work if mail is disabled.

<!-- gh-comment-id:3129936533 --> @stefan0xC commented on GitHub (Jul 28, 2025): Well, I kinda disagree that this should be the case because when signup is disabled that means that random visitors should not see the form and thus the link should not be shown by the client due to a server setting. For this to work we would have to tell the client that the setting `disableUserRegistration` should be `false` even though we have actually disabled it. https://github.com/dani-garcia/vaultwarden/blob/0db4b00007ad1db53ca0f554d2c5298cdc001a8e/src/api/core/mod.rs#L227-L229 While technically we could change this so this also takes into account if mail is disabled and invitations are allowed as to make an exception for that case (because in general this should stay disabled if mail is enabled because then an invitation link is sent), I do think that adding the correct URI fragment to the URL (`/#/signup`) is **easy enough** that the current behavior does not need to be changed. Maybe we could add a page in the wiki for a better documentation because there are a few others things that don't work if mail is disabled.
Author
Owner

@anhyzer5525 commented on GitHub (Jul 28, 2025):

Well, I kinda disagree that this should be the case because when signup is disabled that means that random visitors should not see the form and thus the link should not be shown by the client due to a server setting. For this to work we would have to tell the client that the setting disableUserRegistration should be false even though we have actually disabled it.

vaultwarden/src/api/core/mod.rs

Lines 227 to 229 in 0db4b00

"settings": {
"disableUserRegistration": !crate::CONFIG.signups_allowed() && crate::CONFIG.signups_domains_whitelist().is_empty(),
},
While technically we could change this so this also takes into account if mail is disabled and invitations are allowed as to make an exception for that case (because in general this should stay disabled if mail is enabled because then an invitation link is sent), I do think that adding the correct URI fragment to the URL (/#/signup) is easy enough that the current behavior does not need to be changed.

Maybe we could add a page in the wiki for a better documentation because there are a few others things that don't work if mail is disabled.

I see your point here as well and I would agree in most situations. I also agree documentation is always the right answer.

Trying to run vaultwarden where you don't have an SMTP server makes things challenging to say the least as a few features either do not work at all or you have to go about things in a different way just to accomplish something that would normally be easy to do like adding(inviting) a user, or inviting a user into an organization.

I will say that when new signups are disabled, it does properly give an error and does not allow you to continue if you attempt to create an account that was not invited. I would think that would be enough to make it clear to any normal person that they are not allowed to signup. I see the point of just removing the link all together to prevent bot spamming or automated command injection preventions.

The reason why I raised the issue is this completely makes it inaccessible to all but the most knowledgeable people to figure out how to get to the signup page by manually manipulating the browser URL. I mean it took me all of 5 to 10 minutes to figure it out myself but what about the non-tech people that barely know what they are doing to begin with.

What about this suggestion: If SMTP and new signups are both disable, allow the admin from the admin pages the ability to create accounts and set the initial master password. Then upon initial login the account must set a new master password before they are allowed to save anything into their vaults. Maybe this could be a requirement as well before they are allowed to join any organization within vaultwarden as well.

Not trying to lower the security stance but at least make things a bit easier on both the end user and the administrators.

I hope this all makes sense and sorry for the long-winded response.

<!-- gh-comment-id:3129988191 --> @anhyzer5525 commented on GitHub (Jul 28, 2025): > Well, I kinda disagree that this should be the case because when signup is disabled that means that random visitors should not see the form and thus the link should not be shown by the client due to a server setting. For this to work we would have to tell the client that the setting `disableUserRegistration` should be `false` even though we have actually disabled it. > > [vaultwarden/src/api/core/mod.rs](https://github.com/dani-garcia/vaultwarden/blob/0db4b00007ad1db53ca0f554d2c5298cdc001a8e/src/api/core/mod.rs#L227-L229) > > Lines 227 to 229 in [0db4b00](/dani-garcia/vaultwarden/commit/0db4b00007ad1db53ca0f554d2c5298cdc001a8e) > > "settings": { > "disableUserRegistration": !crate::CONFIG.signups_allowed() && crate::CONFIG.signups_domains_whitelist().is_empty(), > }, > While technically we could change this so this also takes into account if mail is disabled and invitations are allowed as to make an exception for that case (because in general this should stay disabled if mail is enabled because then an invitation link is sent), I do think that adding the correct URI fragment to the URL (`/#/signup`) is **easy enough** that the current behavior does not need to be changed. > > Maybe we could add a page in the wiki for a better documentation because there are a few others things that don't work if mail is disabled. I see your point here as well and I would agree in most situations. I also agree documentation is always the right answer. Trying to run vaultwarden where you don't have an SMTP server makes things challenging to say the least as a few features either do not work at all or you have to go about things in a different way just to accomplish something that would normally be easy to do like adding(inviting) a user, or inviting a user into an organization. I will say that when new signups are disabled, it does properly give an error and does not allow you to continue if you attempt to create an account that was not invited. I would think that would be enough to make it clear to any normal person that they are not allowed to signup. I see the point of just removing the link all together to prevent bot spamming or automated command injection preventions. The reason why I raised the issue is this completely makes it inaccessible to all but the most knowledgeable people to figure out how to get to the signup page by manually manipulating the browser URL. I mean it took me all of 5 to 10 minutes to figure it out myself but what about the non-tech people that barely know what they are doing to begin with. What about this suggestion: If SMTP and new signups are both disable, allow the admin from the admin pages the ability to create accounts and set the initial master password. Then upon initial login the account must set a new master password before they are allowed to save anything into their vaults. Maybe this could be a requirement as well before they are allowed to join any organization within vaultwarden as well. Not trying to lower the security stance but at least make things a bit easier on both the end user and the administrators. I hope this all makes sense and sorry for the long-winded response.
Author
Owner

@BlackDex commented on GitHub (Jul 28, 2025):

You can't set an initial password via the admin unless you create the account fully your self.

Another option would be to not hide that link if smtp is also disabled.

<!-- gh-comment-id:3130008573 --> @BlackDex commented on GitHub (Jul 28, 2025): You can't set an initial password via the admin unless you create the account fully your self. Another option would be to not hide that link if smtp is also disabled.
Author
Owner

@stefan0xC commented on GitHub (Jul 29, 2025):

I think it's easier to hide the link via CSS if you don't want it shown than it is to display it if it has been disabled.
0db4b00007/src/static/templates/scss/vaultwarden.scss.hbs (L129-L131)
Maybe we could even simplify that by adding a custom css class to the link in the web-vault to make hiding it easier.

<!-- gh-comment-id:3130830370 --> @stefan0xC commented on GitHub (Jul 29, 2025): I think it's easier to hide the link via CSS if you don't want it shown than it is to display it if it has been disabled. https://github.com/dani-garcia/vaultwarden/blob/0db4b00007ad1db53ca0f554d2c5298cdc001a8e/src/static/templates/scss/vaultwarden.scss.hbs#L129-L131 Maybe we could even simplify that by adding a custom css class to the link in the web-vault to make hiding it easier.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/vaultwarden#19115