Add the ability to disable unsecured HTTP page warning
I would like the ability to not have the unsecured HTTP page warning show up.
This is the warning in question:
It could be disabled on an item-by-item basis, or via trusting specific IPs/URLs, or globally disabled. Any would work for my use case.
The current behavior is not ideal for me because of the setup of an internal/selfhosted site. It is behind a reverse-proxy with SSL for HTTPs, but I also have a direct local connection to the machine which is only available via HTTP. The local connection is about 20 times faster, so using the HTTPs proxy connection is very much less than ideal.
One workaround would be to have two separate entries, one for the http connection, one for the https connection. But that partially of defeats the simplicity of having a password manager, as then I would have to manually synchronize credential changes between the entries.
Related topics + references
There are requests on reddit and the general questions about how to disable this warning:
I’d like to add my vote to this feature request.
We have multiple servers running in a secured environment, but with old software that does not support https, as such I see this prompt too many times during a day.
Otherwise I really like using bitwarden.
I’m a dev with the same issue on my local machine. Also, we use DNS to point dev.example.com back to my local dev machine while other subdomains are https, such as clientsite.example.com. That may make the solution more tricky.
I’ll add in here too - in some cases I’m accessing http sites via a self-managed VPN. The ability to disable this warning on a site by site / IP address range would be a great solution. Something similar to #36997
I don’t think excluding localhosts or even private ranges is the way to go here. I can think of plenty of situation that would not cover like local hostnames and vpn ip ranges.
I’d prefer having this warning/popup only when saving the password as I see little the point of warning me every time that i’m filling a password on the exact domain i have configured (whether that be https, http or any other protocol).
I’d love to understand your use-case a little bit better. Currently, if you have only a single URI saved on an item, and it is http, no warning will pop up when you fill the login. It’s only when you have an https URI saved to an item and fill on http that the warning displays. How frequently do you have multiple URIs, some with and some without https, saved on an item?
Thanks @Micah_Edelblut for the clarification on the dual http/https URI trigger for this warning. That explains the behaviour perfectly, and the implementation makes sense.
Bit different to brainslug, but the use-case that was triggering this for me was a local network hosted service that was http-only (home assistant), which is being proxied by nginx to https. So I had the split URIs for the same login.
Interesting just had a look and indeed an https link had sneaked in the credential websites, i was convinced was only http that was a mistaken assumption on my part. On further investigation it does look like this happens fairly frequently in my projects having both http and https urls.
My usecases where this happens are:
Building on a web framework, where i end up having tons of instances of the same code base, varying branches/version/changes but talking to the same database, for running specific debugging scenarios and experiments. These tend to be local with http but it does happen that something needs to be tested/reproduced specifically using https resulting in mixing the protocols.
Website debugging, where the initial URL would be https if it was a staging/production/vpn environment but also gets a local http address when the database gets pulled locally for further testing.
I’m running into this issue as well and my use case as a web developer is that I DO have a single item/entry applicable to multiple sites, some http (but local) and some https (remote). All the http hosts in this case are of the format of hostname.loc, e.g. client1.loc, client2.loc, etc. I use dnsmasq to route all *.loc hostnames to 127.0.0.1, with apache virtual hosts for the different sites I have to work on. But since my local version of a site is just a copy of the remote version, it makes sense to have a single entry applicable to all the different hostnames, using the same credentials.
So, what I need is to be able to tell Bitwarden, “Don’t bug me about http for *.loc hostnames, no matter what”. Thanks!
I use one login entry (user/pass) on a variety of local dns, public dns, local ip methods to access the same self-hosted service.
This feature needs to have some sort of boolean “disable this warning” checkbox on a per login basis to sufficiently cover all possible scenarios. Simply disabling on a local ip band, or on some local DNS format won’t cover all possible cases.