Pull always show the full URI / URL. The user must go into EDIT mode to view full URI.
Looks like over one year ago the developer agreed it was a “pretty simple change.” and “Will be available next release.” but instead closed the previous case without ever implementing the actual fix.
Default to save FQDN for websites?
As seen in the attached images, the URI fields show the same content when viewing the card information, but when you go into Edit mode, the full URIs are correctly displayed.
This causes the problem that the user doesn’t know which website to Launch or Copy URI to.
Instead of having all URIs only showing the domain, it will now display all that is in the URI field.
This feature will make it faster for users to distinguish which URI they need to click on to Launch or Copy URI of.
If a user doesn’t want this function, then have a setting in the app preferences to toggle this on or off.
I completely agree with this. Having to hover over a URI to determine the full address makes figuring out what type of match will be performed very difficult.
I would also add that the default view mode should display the type of match that will be performed against said URI. This is a security flaw in my opinion because it is so difficult to determine when my passwords will auto-fill. In view mode we should see something like:
Website
https://discipletools.local/wp-login.php (Base domain)
Or maybe even better yet, also have the matching part of the URI colored when matching is for “Base domain” or “Host.” Then most users wouldn’t even need to consult the docs to figure out what is going to match.
It’s 2024 and still waiting for this change…
Seriously, why was this design decision made in the first place. Just display the actual field value. Some things are hard to go back and re-engineer. Having a tough time seeing that here…
Reading the thread from 2018 that was referenced in your 2019 top post of the current topic, it is clear that you misunderstood the earlier request, which has in fact been implemented. The 2018 request was for new login items created by the browser extension to set the item’s Name field to the FQDN (abc.example.com) instead of just the base domain (example.com), which was the original behavior. This was implemented (as promised by @kspearrin) in the next release, version 1.26.2 from April 19, 2018.
You (and @applepie) seem to be asking for a change to the way the individual URI fields stored within a login item are displayed when the item is opened for viewing its details. This is a valid request, but not that same thing that was discussed in the 2018 thread.
To avoid confusion, I have edited the title of your request (was: “Always show FULL URI / URL. Don’t truncate when saved”). To be clear, the URIs are not truncated when saved.
Finally, to add my own opinion, I would allow that it may be OK to display just the base domain (or host name), if and only if the URI match detection setting for that URI is “Base Domain” (or “Host”, respectively).
Any update to adding a way to always show full URLs?
We have taken to adding a prefix (e.g. ‘Prefix - https://url’) to the website URL so that we’re able to see the full URL in the field. It breaks the bitwarden functionality to open the URL (as you have to edit the window that opens to remove the prefix), but it’s a workaround.
@Navid_Hegan Welcome to the forum, and thank you for sharing your interesting work-around.
To clarify, the “prefix” inserted just before the protocol specifier (https:) must be something that is neither whitespace, nor a valid protocol specifier (e.g., ftp:). A single prefix character will suffice (e.g., /https://www.example.com/my/path/).
Besides the inability to use the “Launch” function, negative consequences of using this work-around also includes the complete loss of URI Matching functionality, which makes autofilling much harder and more risky.
For login items that do not have a large number of stored URLs, the following approach would take care of both of the issues:
icon next to the second URI only, and set its Match Detection method to “Never”With the above modifications, the launch functionality and URI Matching/autofill should work again. The only drawback is that when viewing the item, you will see both URL versions: first, the plain host name, and just below that, the full URL.
