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:
Definitely! For me, as a web developer, completely broke my flow. Try to cycle through multiple logins for a website when every one of them shows alert
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.
This blocked my local development flow enough that i had to disable the browser extension altogether and go back to the web app Big up vote from me please make this opt-out!
Is there an option to downgrade the extensions in the mean time?
Downgrading to 2022.10.1 did the trick, hopefully this gets fixed soon
Another request for this as well. Lots of self-hosted stuff that I just access on http by IP address. Super annoying to have to cancel this prompt every time I access.
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
This sounds like it will not be enough for me. Seems like it will still give warnings on something like āhttp://server1.localā
I want to disable this in general or at worst I would accept a checkbox ādisable for this domain/url/IPā.
My browser is already warning me about http sites (without option to disable) and when individual addons will do the same on top of that it becomes really really annoying.
I get that you want to protect grandma but a lot of advanced/power users have absolutely no need for this as they are perfectly capable of knowing what they are doing and the risks they are taking.
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.
Big up vote from me please make this opt-out!