Hi.
I have successfully imported items from a CSV file.
I have used 4 identifiers:
name,login_uri,login_username,login_password
The CSV only contained domains in the “login-uri” column.
Example:
bugs.documentfoundation.org
Bitwarden added a “http://” during the import.
Can I prevent this addition of “http://”?
If I create an item manually and enter a domain in the field URI, Bitwarden does not add “http://”.
Thanks for your help.
I am not aware of any setting to change this.
But keep in mind that “login-uri” is not just a plain text. An URI - a “unique resource identifier” - must contain a scheme as well, like “http://”, “https://”, “ftp://” and so on. Otherwise it is not an URI but just text. So if you add a text without scheme, then this will be added and the default seems to be “http://”. Also see RFC 3986 - Uniform Resource Identifier (URI): Generic Syntax how “URI” is defined, in particular RFC 3986 - Uniform Resource Identifier (URI): Generic Syntax
Each URI begins with a scheme name, as defined in Section 3.1, (…)
Also don’t get confused by web browsers which omit the “https://” at the beginning in the UI - also a web browser will always use “http://domain.example” or “https://domain.example” and not just “domain.example”.
I would see it as a bug, if Bitwarden does not add a scheme when adding text to an URI field without scheme manually.
The default behaviour of browsers, when you enter just a domain is: adding “https://” automatically.
I prefer that behaviour.
In other words: when a user does not add a sheme, try "https:// first.
Evidently, the “Bitwarden (csv)” importer automatically adds a default https:http:// protocol if none is specified — unless the URI string contains no period characters (.).
Why do you want to store URI strings without a specified protocol?
Edit: Fixed typo.
In my case, “http://” was added and not “https://”.
Because each browser I know, adds “https://” automatically, wenn he get’s an URI without sheme.
Advantage:
Easier to read and edit of items, when they do not contain a sheme. In non standard cases, where you want a “ftp …” or “http …”, than the user is free to add that sheme.
Sorry, that was a typo on my part (I have edited by response to fix it).
Try using an Edge browser and navigating to the following links:
When viewing a vault item, the protocol prefix is not displayed (it is only displayed when editing the item).
This information should be added before importing the data.
The default-default is to match on “base domain”. Neither “base domain” nor “host” care about the scheme. Unless you start to do fancy stuff, such as “starts with”, “exact” or “regular expression”, there is no need to care what the scheme is.
I suggest to focus first on the important points.
There is an inconsistency in the import process of an item from a CSV with an URI without sheme and a manual creation of an item with URI without sheme. How do you justify that inconsistency please?
Importing of a CSV file requires conditioning of the data (i.e., ensuring that the data is formatted to meet the requirements of the import process). For example, to correctly import a custom field, the string in the field column must contain a colon character followed by a space character (: ). Similarly, to correctly import a URI field, the string in the login_uri column must include a protocol prefix in order to be properly imported.
So, the solution is to condition the CSV file to ensure that each URI value includes the desired protocol prefix (https://, http://, ftp://, etc.). If you need help with this, let us know.
Regardless, having the http:// prepended by default (for URI strings that are imported without a protocol specifier) should not cause any problems. Most browsers will automatically redirect an http: URL to the corresponding https: URL (if one exists), and the protocol prefix will be hidden when viewing the item details in any Bitwarden app (except the Web Vault).
I disagree.
Importing a valid domain name without a sheme does not need any conditioning.
Because: every browser can open the corresponding website with a valid domain name without a sheme. For the few exceptions of websites, where a user wants to force a website to open with “http” instead of “https”, he is free to add a sheme.
And this is apparently also the view of the developers of Bitdwarden - I suppose - when they build the process of manually creating an item.
They do not issue any warning “Incorrect conditioning, the sheme is missing, you may only save the item once you have added a sheme.”
Another indication that automatically adding a sheme is completely superfluous:
Two other popular password managers that I know of do not add a sheme when importing an item with a URI without a sheme from a CSV:
1Password
Apple App Passwords
Anyway: I’m just looking for a friendly constructive hint on something that I think could be improved. No offense : )
My point is, the behavior of the import tool seems to be intentional, so it is not a bug. Here’s my “friendly constructive hint”: if you wish for Bitwarden to behave differently, you should submit a feature request in the appropriate section of the forum.
