Disable 2FA email setup button if email 2FA is disabled in admin settings

[OldScratchy]

I have a Vaultwarden instance and I noticed that the option to configure Two-Factor Authentication (2FA) via email is still visible and clickable from the user interface, even when this feature is disabled in the admin configuration.

When attempting to set it up, the system correctly shows an error message indicating that email 2FA is disabled. However, it would be a much better user experience if the email 2FA configuration option appeared grayed out or was otherwise marked as unavailable when the feature is turned off at the server level.

This change would improve clarity and reduce confusion for end users who might wonder why the option exists if it's not usable!

Thank you for your time! (VW is awesome✨)

Version: 1.33.2

[stefan0xC]

Seems like we only disable it if email is disabled:

vaultwarden/src/static/templates/scss/vaultwarden.scss.hbs

Lines 121 to 126 in 3b48e6e

	{{#unless mail_enabled}}
	/* Hide `Email` 2FA if mail is not enabled */
	.providers-2fa-1 {
	@extend %vw-hide;
	}
	{{/unless}}

I'll see if I can create PR to fix this but in the meantime you can disable it yourself via CSS by creating a file called data/templates/scss/user.vaultwarden.scss.hbs and just set it to

.providers-2fa-1 {
    extendend %vw-hide;
}

[tessus]

@stefan0xC I was looking at my config file for a while now, but there doesn't seem to be a config option to enable/disable email 2fa. (I also checked vw .env.template in the repo.)
But in the end I only found one in the admin interface.

Is it true that I have to use the admin interface? I actually wanted to avoid having vw create a config.json. May I ask why adding a config option was never done? Was it just overlooked?

Along the same line, there is no option for enabling/disbling email either. (But I can configure everything else regarding email, e.g. the smtp password, so it can't be a security reason.)

Why are these options missing? I am a bit puzzled by this.

[stefan0xC]

Is it true that I have to use the admin interface?

No. You can just set the following

_ENABLE_EMAIL_2FA=false

Why this is not in .env.template I don't know.

[tessus]

Thanks for the reply. So analogously this would mean I could also set _ENABLE_SMTP. Interesting.
Why the underscores? Usually an underscore denotes an internal variable.

Maybe we could create aliases without the underscore and add them to the .env.template. I am more than happy to create a PR, but I guess I need more info on why this was never done in the first place or why underscores were used. There must have been a reason, and most likely somebody opted for this design decision. Creating a PR w/o the project leaders' ok, makes not a lot of sense in this case.
@dani-garcia @BlackDex can you please shed some light on this?

[dani-garcia]

When I built the functionality for the enable flags it was for features like SMTP, where we would consider the feature enabled as long as you configured all the SMTP_* variables to be non-empty strings. This meant that the only option to disable the feature would be to set all the fields to empty, losing their previous values. The addition of the enable switches would allow users to disable the feature without losing their settings.

The reason for the underscore and them being undocummented was that I only meant for these config entries to be used from the UI and not directly as env variable. I figured whoever was using env variables wouldn't need an enable switch, they could just comment out all the options in their .env file or wherever. I also worried that it could cause confusion: while the UI clearly shows that the fields are disabled, I worried that in a large .env file it would be easy to miss a ENABLE_SMTP=false somewhere and people would wonder why the feature isn't working.

_ENABLE_EMAIL_2FA seems a bit different in that you can't just disable it by setting all the fields to an empty string, like is the case with SMTP config. I believe this one should have definitely not have used an underscore and should have been documented in the first place.

About the rest of the _ENABLE* features (SMTP, yubico, duo), I'm more indiferent about them. I don't see how they'd be useful outside the UI, but if someone has a good reason for them to be used as env variables, I'm alright with changing them too.

[tessus]

Thanks for the explanation. The reason why I personally don't like changing the settings in the admin interface is because it creates a config.json file, which settings take precedence. Thus, if I want the settings in the config file to be the source of truth at any point after using the admin interface, I either have to delete the config.json file or edit it and delete the key:value.

I use vw with a systemd file w/o docker. Thus I have all my settings in a /etc/vw/vw.cfg file and would like to be able to configure everything that I can configure in the UI in that config file as well.

Am I really the only person who wants to set all options of an app in a single file?