Browser: Subdomain support

[WardsParadox]

Hello,
Love Bitwarden and have swapped to it from Lastpass. I noticed that there is no support for separating sites based on the full domain. Bitwarden detects tech.example.com and forms.example.com to be the same site and offers both sets of logins for both sites. If a user could setup a URL rule to prevent this, that would be great.

[tmuka]

I agree. I use a lot of subdomains that don't share credentials with the parent domain, it's a hassle scrolling through my list to find the right subdomain. An improvement would be at least putting the exact matching subdomain credentials at the top of the list. Thanks!

[kspearrin]

Today bitwarden will compare the "base domain" when showing you suggested logins.

I am going to propose that we add a boolean (checkbox) option to each login "Use Full URI", defaulting to false. If a login has this option checked we will compare the full hostname (including any subdomains and ports) instead of the base domain.

Examples:

domain.com

domain.com (match)
sub.domain.com (no match)

sub.domain.com

domain.com (no match)
sub.domain.com (match)
sub2.domain.com (no match)
sub.domain.com:1234 (no match)

sub.sub2.domain.com

domain.com (no match)
sub.domain.com (no match)
sub.sub2.domain.com (match)
sub.sub3.domain.com (no match)

localhost:4000

localhost (no match)
sub.localhost (no match)
localhost:4000 (match)

[globau]

looks sane however aswww is a technically subdomain it may need special handling - i would expect www.example.com to match example.com even if "use full uri" is enabled.

[WardsParadox]

Any idea when this will actually make it to the extension? I don't seem to see this in the current release of the chrome browser extension.

[kspearrin]

@WardsParadox It hasn't been started yet. Hopefully sometime soon.

[WardsParadox]

Ah ok. I got misled by the merge. My bad. Thanks for the info 👍

[kmf]

Watching this ...

[guyspr]

Any progress on this? The direct matches on top works well, but I would prefer it if bitwarden would not display all options for a single domain.

[SylwesterZarebski]

@globau commented on 22 maj 2017, 19:41 CEST:

looks sane however aswww is a technically subdomain it may need special handling - i would expect www.example.com to match example.com even if "use full uri" is enabled.

I suggest another option for this - maybe something like:
Always handle this subdomain with parent domain: [www]
Which could be cleared, because www.doma.in may be different from doma.in, especially in Intranet webpages, where are multiple subdomains and multiple different credentials for each website.

[ChristianMartel]

Today bitwarden will compare the "base domain" when showing you suggested logins.

I am going to propose that we add a boolean (checkbox) option to each login "Use Full URI", defaulting to false. If a login has this option checked we will compare the full hostname (including any subdomains and ports) instead of the base domain.

@kspearrin
Don't forget to compare sites that have the same subdomains that could have many users :
https://domain.com/app1/...
https://domain.com/app2/...
http://localhost:8080/app1/...
http://localhost:8080/app2/...

I understand that it is not possible to match the "app1" on the .com and on the localhost, but it would be awesome to differentiate "app1" and "app2", like LastPass does.

Thanks.

[kspearrin]

@ChristianMartel Yea, my proposed solution would not work for that since it is not taking the URL path into account. Maybe we need something like "Use Full Hostname" (previous suggested solution) and a "Use Full URI" option (your suggestion)? "Use Full URI" would compare that the current browser URI starts with the stored URI.

For example, if you have stored "https://domain.com/app1" as the URI in your vault and selected "Use Full URI", the following would match:

• https://domain.com/app1
• https://domain.com/app1234
• https://domain.com/app1/something?sdfsdf=sd

Would not match:

• https://domain.com
• https://domain.com/app2
• https://domain.com/app

Also I am terrible at naming things so if anyone has better ideas on the labels for those checkboxes I'll take it :)

[ChristianMartel]

@kspearrin What you are suggesting would be better, but would not fit all of my use-cases.
For example, I need to be able to match :
https://sub.domain.com/app1/main/page (online main app, production database)
https://sub.domain.com/app1test/main/page (online dev app, dev db)
localhost:8080/app1/main/page (local main app, production db)
localhost:8080/app1test/main/page (local dev app, dev db)

And the same for app2, app3, app4 ...

[kspearrin]

Then you would save your URIs as "https://domain.com/app1/" and "https://domain.com/app1test/" (trailing slash)

[SylwesterZarebski]

Is there (or will be) possibility to add multiple URIs to one credential?

[kspearrin]

@SylwesterZarebski That is not planned at this time.

[SylwesterZarebski]

Thanks, making recognizing stricter with some hosts/addresses should be first priority, i think.

[piejanssens]

@SylwesterZarebski Check out "Equivalent Domains". Is this what you are looking for? https://vault.bitwarden.com/#/settings/domains

[todoleza]

@piejanssens the core issue here is quite the opposite, we need to differentiate between domains that are considered the same when matching. This https://github.com/bitwarden/browser/issues/77#issuecomment-303145336 describes the proposed feature very well.

[piejanssens]

You can also consider allowing /regex/ in the website+equivalent domain fields for advanced cases. Then you can match any URL.

[WoLpH]

@WardsParadox can you fix the typo in the subject please? For some reason it's annoying me a little ;)
s/subdomian/subdomain/g

[WardsParadox]

@WoLpH Yup. Didn't even notice. Would have bothered me too. Hopefully, this feature comes soon as since they introduced the sorted usernames, it has made the 9 logins I use that all share the same main domain, a nightmare.

[sebastian-burlacu]

@kspearrin does your solution take into account sub-pages with similarly named fields? For example, our ticketing application has a login page where I enter my email + password, but then when I open tickets that also have an email field for the customer, Bitwarden will auto fill my own email. If I could match on the full URI (https://ticketing.domain.com/login.html) that would be different from the ticket URI (https://ticketing.domain.com/ticket?id=1234) and would solve my problem.

Also wondering an approximate eta for this issue - it's literally the only complaint I have about Bitwarden at this time :)

[kspearrin]

@sebastian-burlacu Yes, that use case would be covered I believe. Maybe in the next month or two hopefully.

[ghost]

for the love of the gods, please fix this. I have 50+ logins for *.local.lan resources that all show up for every single web login page on those resource, where reality, there is only one valid login for that resource

[ghost]

or is there a work around, with the domain rules section?

[ghost]

@kspearrin In regards to https://github.com/bitwarden/browser/issues/77#issuecomment-332943662 , this is an insanely powerful feature that would great to have. Use case example: In a domain environment, say there is 30+ auth-walled resources. Say all those resources use windows authentication. Say domain policy requires accounts change password every 3 months. Each 3 month password change, I would have to edit 30 different Bitwarden login entries, changing the password from my previous domain password, to my new one.

Edit: Work around could be bulk password updating, and store all those login entries in a single folder. Not as direct, but might be easier to code in

[kspearrin]

@meffect This issue is about subdomains, not multiple domains. Please open another issue if necessary. Also, see https://blog.bitwarden.com/new-feature-equivalent-domains-dd29aa462bb7

[ghost]

Me know, just saw that gem and wanted to touch on it, cause lastpass has the same issue

[ghost]

I read the blog article . just my initial opinion but i'm on the fence about it. It would get the job done but kinda feels like using a feature outside it's scope, and would create somewhat of a maintenance issue in certain situations. and things like 2 factor no workie

[ghost]

For this issue, https://github.com/bitwarden/browser/issues/77 , seem's Lastpass has this functionality now. I love Bitwarden so much more. The 2 factor is awesome, and it's so much faster than Slowpass. Here's is Lastpass's Documentation on how they implemented this feature. Lastpass has a section called URL Rules , separate from Equivalent Domains. I did a quick test and it does work. I added resource.local.lan to the url rules and only 1 login entry showed up in the Lastpass menu for that resource.

Going to quote the link language for point in time persistence:

Does LastPass recognize different subdomains?

By default, LastPass uses the 2nd level domain name to decide if a site's credentials should be autofilled. For example, if you have saved a site with credentials for www.acme.com, then LastPass will consider all of the following URLs matches since they all have a 2nd level domain name of 'acme.com'.

www.acme.com

acme.com

login.acme.com

secure.login.acme.com

You can also choose to have LastPass only offer the logins saved to a particular URL. You can do this by setting a URL Rule with exact host matching. By setting this URL rule, LastPass will recognize any subdomains as part of the URL, and only offer the appropriate logins.

From the example above, if all the URLs shared the same login except secure.login.acme.com, you would want to set a URL Rule with exact host matching for secure.login.acme.com. This would ensure that only logins saved to that URl are offered for autofill or autologin on secure.login.acme.com.

Edit: Hmm. Lastpass has really improved lately... starting to like Lastpass more now

[Attoy]

Is there any news about adding subdomain support on Bitwarden? Not complaining, just asking. I switched from Lastpass and I miss this! :)

[kspearrin]

No news as of yet.

[kobelobster]

This is the only feature keeping me at LastPass. Would make a complete switch as soon as this implemented, because I badly need this.

Thanks for the awesome tool, though!

[Attoy]

@tzfrs Yeah, I'm subscribed to this issue just to know when @kspearrin will add this feature!

[dominicpratt]

+1, really miss this feature coming from LastPass

[psylenced]

I've just recently started making the switch and this is the number one issue for me.

Adding the ability to add servers and/or sub domains and/or paths to not join together is very important.

The company intranet has dozens of servers and applications on those servers that have no relevance to each other at all.

Imagine:
testserver01.dev.company.internal/app1
testserver01.dev.company.internal/app2
testserver01.dev.company.internal/app3

So I need to be able to add a list of domains, subdomains and paths to make sure they are not linked.

There needs to be the ability to add a list of servers (with wildcards) so that individual entries do not need to repeatedly be manually configured.

eg.

• *.company.internal
• *.sub.dev.company.internal
• dev.company.internal [x] include first path

Anything that matches those wildcard entries should enforce strict matching.

That being said, there needs to occasionally be a time where this can be configured on a single entry too. An example for this is a finance app where the login is email/password, but there is a 4 digit PIN check every time a transaction is made which is different from the login credentials.

Edit:

Also I note that this is the number one commented enhancement which is important for business and enterprise and the issue has remained open for approximately 12 months with no resolution. This does not provide a good look on behalf of the product.

[c0necto]

@psylenced I absolutely agree on your post.

We are currently switching over from LastPass, and the biggest issue right now is that there is no possibility to have different credentials on a subdomain and subdirectory basis (we need both).

[guyspr]

Exact url matching with a wildcard is a must for password managers imo. It's really bothering me lately since now the options for the same subdomain change order to the last one used at the top. Now I have to read the options every single time to find what I need.

A checkmark for a login with 'exact host match' would be enough. Add wildcard support %.domain.com or domain.com/app1/% and you got it covered.

[SylwesterZarebski]

@guyspr commented on 11 gru 2017, 14:12 CET:

Exact url matching with a wildcard is a must for password managers imo.

I would say regular expressions, because simple wildcards are very limited. Also regular expression is mature technology with great support in JS while wildcards are not.

[psylenced]

That would work, but people who are not programmers would be confused as anything understanding them.

A simple * is what a majority of people could understand and I think would handle 99% of situations.

That being said - if regex were added, it wouldn't bother me - just need something.

[SylwesterZarebski]

It is not so simple, because with wildcards You have to make many assumptions, like: whether * do or don't match dot in subdomain string - both options has problems with it, and You can't have both without more configuration options, and it is only an iceberg tip.
Contrary, regular expressions give right powers to user without more complicated solutions at addon side.
I understand that for most people, regular expressions are like magic, but most of people do not even need strict or multiple domain support (could be 99%), thus i opt for more elastic solution for the rest = more advanced users.
Of course, both solutions are fine by me :-).

[Attoy]

Iirc LastPass use a simple method to define subdomains. If you have an entry from domain.com it works for every subdomain with TLD domain.com. However if you have an entry with test.domain.com; the first entry still works for every subsomain with TLD domain.com but the specific test.domain.com. Shouldn't it be a viable compromise?
Dont' get me wrong, I know regex gives advanced users a fine-grained configuration capability.

[piejanssens]

Just a checkbox "Parse regex" could solve the debate between wildcard for noobs and regex for pro's...

[favadi]

Iirc LastPass use a simple method to define subdomains. If you have an entry from domain.com it works for every subdomain with TLD domain.com. However if you have an entry with test.domain.com; the first entry still works for every subsomain with TLD domain.com but the specific test.domain.com.

This sounds like an elegant way to deal with this isssue.

[kdar]

Running into this issue having multiple slack domains. But we definitely need a feature that is not limited to just subdomains.

[Wehrdo]

@Attoy I think that is similar to the behavior that I would expect:

Basically, the "most specific" saved credential gets priority. When you only have credentials for TLD.com, it will work for any subdomain of domain.com. But if you have saved credentials for sub.domain.com, then that is the more specific fitting credential when visiting any host that matches *.sub.domain.com.

With this, the www prefix will not cause any problems, unless the user specifically saves a separate credential for the www subdomain.

I find the subdomain issue crops up a lot, so I think it's an important feature to have handled somewhat automatically, if possible.

[fcartegnie]

Presenting all entries on a shared hosting domain and expecting the user to never leak credentials to another app by always clicking the correct one. What can go wrong.

[kobelobster]

@fcartegnie It's an opt-in option, so you would have to manually activate subdomain support. Per default it would be the same behaviour as it is now.

[zestysoft]

This is also what is keeping me and the rest of my family from switching to (and paying) Bitwarden. I've been using KeePass with the KeePassHttp plugin for this feature. I just have to enable the setting: "Return only best matching entries for an URL instead of all entries for the whole domain."

This shouldn't be a complex thing to solve-- if there are multiple matches in the password manager for a domain and there are entries that have more characters that match the current URL, use that credential instead.

Or just see how KeePassHttp is doing it -- it's open source: https://github.com/pfn/keepasshttp

[hellboyPS]

Really, this should be a key feature in my opinion.
I realize, that maybe most users don't absolutely require it, but there are definitely cases where this is needed very much.

I've been trying out bitwarden for close to a month now, and I have to manually type my password more often than not (this is no overstatement). Yes, I might be a special case in that I host a bunch of applications on the same domain (git.mydomain.org, chat.mydomain.org, and so on), but still. There is obviously some demand for this feature.

It also encourages me to use the same password for those different services (different subdomain) which is EXACTLY what I'm trying to avoid with a password manager like bitwarden (rather: use generated random password for each and every service).

So, +1 from me.

[Ranczo]

Exactly the same problem here: I have a lot of subdomains for different applications, Bitwarden is almost unusable for those.

I would appreciate it very much if you could implement this feature soon.

[piejanssens]

@kspearrin Any update on the plans to implement one of the suggested approaches?

[kspearrin]

The initial plan is to create a string prefix value you can append to the URL field to enable various scenarios described in this issue.

ex:

• fullhostname=https://sub.domain.com:123/
• fulluri=https://sub2.domain.com/somepath.html
• startswith=https://sub2.domain.com/somepath/
• basedomain=https://sub2.domain.com (default)

This negates the need for UI elements to control the functions and we can create many different rules internally. It also allows us to specify rules on individual URIs if/when we add the ability to store multiple URIs per login item.

We then plan to add a UI toggle (checkbox) for the most likely used case such as "Use Full Hostname".

[Attoy]

Thanks for the update Kyle! Is there a beta channel we can subscribe to and test this feature?

[kspearrin]

@Attoy No. You would have to build the extension locally or manually download our real-time dev builds at https://ci.appveyor.com/project/bitwarden/browser/build/artifacts

But this work hasn't been started yet.

[SylwesterZarebski]

Thanks, Will You also provide syntax with wildcards/regexps like: https://git.*.internal.local/ for multiple sites?

[kspearrin]

@SylwesterZarebski I suppose we can just add a regex=something option and you can create whatever wildcard scenario you like. Seems like it could get dangerous though.

[SylwesterZarebski]

True, sharp knives could cut ;-). Thanks a lot.

[piejanssens]

Yes! REGEX 🥇 I'm all for it.
regex=/something(/w+)is{0,4}regexinhere/

Couldn't you simply turn the string prefixes into a dropdown as a minimum for best UX?
So you choose from the dropdown which is shown right in front of the URL field. Internally the value of the dropdown can be concatenated with the URL text as fullhostname=https://sub.domain.com:123/ in your example. You can then add a ❔ icon to go to a wiki/help page where each of the option is explained.

fullhostname
fulluri
startswith
basedomain
regex

[kriswilk]

@kspearrin, I like the flexibility you're aiming for, but I feel @piejanssens has the right idea for the UI.

Adding a prefix within the URI field feels kludgy...mixing data with contextual info in a field that should probably only contain a URI. The field becomes a lot less portable with some proprietary prefix on it. For instance exported vault data would not be very friendly-looking to other apps.

But stepping back for a second...

Before you begin implementing more complicated options, maybe it's worth just changing the logic to the very simple "most specific" URI as described best by @wehrdo? Trying that out would not require any UI or structural changes but I think it would address the vast majority of cases immediately.

Keep up the great work!

[favadi]

I also think the regex might be too complicated for the value it will provide to users. The "most specific" strategy is enough for me.

[SylwesterZarebski]

Term "most specific" is too general to make any assumptions. For example, which of these definitions is most specific:

sub.domain.com/path/path2
www.sub.domain.com/path/

for address: www.sub.domain.com/path/path2/path3?

This 'most specifity' looks similar to CSS specificity which is very complex.

PS. It is fine by me, but will need to be documented extensively.

[favadi]

This task is about subdomain, so the latter is most specific in your case. Although, someone posted above that we should treat www as a special case.

[Fonant]

How about: Longest matching hostname or sub-hostname working from right to left. Followed by longest matching path or sub-path working left to right. If port number is specified, that has to match.

Different logins per host name are much more commonly found than different logins per path on the same host name.

Entries:

A: domain.com
B: www.domain.com
C: shop.domain.com
D: local.shop.domain.com
E: domain.com/testing
F: shop.domain.com/admin
G: domain.com/testing/results

Then:

http://www.domain.com/anything/here => B
http://www.domain.com/testing => B
http://www.domain.com/admin =>B
http://shop.domain.com/anything/here => C/F => C
http://shop.domain.com/testing => C/F => C
http://shop.domain.com/admin => C/F => F
http://domain.com/anything/here =>A/E/G => A
http://domain.com/testing =>A/E/G => E
http://domain.com/testing/anything =>A/E/G => E
http://domain.com/testing/results =>A/E/G => G

The logic could perhaps ignore "www." by stripping it off both the test URL and the stored hostnames, for the purposes of this logic?

[kriswilk]

Let's not make this seem more complicated than it needs to be...

1) Compare the visited HOSTNAME (x.y.z.tld) against each vault entry. Keep only the one(s) which match most closely, working from RIGHT TO LEFT (tld, then domain, then subdomains, ...)

2) If the visited site includes a specific PORT (80, 23, ...), reduce the matching pool further if any vault entries share the same port.

2) If multiple matches still exist, examine the PATH (/path1/path2/file.ext?blah=blah...) and determine which entr(y/ies) match by working LEFT to RIGHT, i.e. most matching characters.

Is this not enough??

[Fonant]

That was what I was getting at, although I got my "shortest" and "longest" the wrong way round... and I forgot about port numbers...

I've edited my post above to correct the wording.

[phynias]

just decide on a way and go with it. it's been a year. not trying to be rude, but even a basic option could have been done by now. i switched to bitwarden from lastpass but have to switch back. WAY to many subdomains at home and work to ever make this useable.

[Attoy]

@kspearrin do you have an ETA to share with us?

[psylenced]

The initial plan is to create a string prefix value you can append to the URL field to enable various scenarios described in this issue.

fullhostname, fulluri, startswith, basedomain

Just one further thing. I think there needs to be the ability to add certain domains / string matches to be "a domain that needs a prefix".

If you auto-add (via the standard dropdown bar) the site's name/description will default to the shortened version. You then will need to go search for it (often with dozens of matches), go into the entry and then manually add the prefix.

If I add workdomain.com to the "domain that needs a prefix" list - then when I auto-add, the UI will know to automatically open the "edit" version of that site, so I can add in the prefix.

I guess also the name value needs to change based on the prefix too, so every entry is not just workdomain.com, as there will by default be many matches all with the same name showing on the UI.

[mikemeier]

Where can we donate money to have this feature implemented? 🤔

[Attoy]

@mikemeier I think the best way to support BitWarden is subscribe to premium membership.
I hope @kspearrin will give us an ETA sooner than later :)

[samuelebistoletti]

Any news?

[dominicpratt]

I really hope this feature get's implemented soon... stuck on LastPass until then. :(

[kspearrin]

Now that the desktop app is released, this is being looked at again.

[Attoy]

Awesome!

[kspearrin]

Here's a quick screenshot of what's being built for this (also multi-uri support being added too). Does calling this "MatchAuto-fill Detection" make sense?

[psylenced]

Now this is being looked at again - just a comment.

I can see this being needed in 2 areas:

1) Editing an already saved login so it only shows as a candidate when the match passes.
2) Adding a global set of values, for a new added domain so it defaults correctly.
2b) Adding a global set of values so existing logins will only exactly match.

Also when adding a new login which falls under number 2 above - the name of the login should default to the matching segment (sub.domain.com:88/path) and not just domain.com.

[SylwesterZarebski]

For me, proposition looks great, just what i need.

[Attoy]

@kspearrin as "Auto-fill detection" I'd think something related to the detection of fields on the page to be auto-filled. I'd say "URL match detection" is a __better__ name. Just my 2 cent.

[talha131]

@kspearrin feature wise it looks great. Can't wait to have it.

But from end user POV, it is complicated. It's very technical. An end user is unaware of terms like base domain, hostname, and regular expression, much less understand them to make a choice.

Perhaps, hide these options under "Advanced URL match detection". Or highlight the matching part of the url when users selection changes. Like if "Base domain" is selected, then the base domain domain part of the url gets a different color. This will offer visual cue to the user.

[kspearrin]

@talha131 I agree but I am not sure how I can properly present that in the UI. Where would this advanced uri options button be? I don’t think it’s possible to selectively highlight uri text in an text input field.

[kspearrin]

@talha131 How about something like this?

[talha131]

@kspearrin Much better. And thanks for listening and responding to feedback so quickly. More power to you!

[kriswilk]

This looks like it will handle just about anyone's use pattern. I like it.

Perhaps instead of the gear icon you can put a "help" link next to the drop-down box which goes directly to a help page describing the various options. That would allow users to self-educate when they are curious. Personally I'd prefer not to have to click the gear just to see the option I had set for each URI.

Also, maybe I'm missing something but what's the logic behind the "do not enter" icon? I presume it's to delete an entry, but if so, I'd say you should use the same "X" icon that is used for custom fields...at least that's what I see in the chrome extension.

[kriswilk]

One other comment/question: how will this new functionality interact with the existing global equivalent domains feature?

[kspearrin]

@kriswilk Haven't got that far yet.

[kspearrin]

@kriswilk I made it so that the dropdown options are only hidden by default if there is no value set on them yet (default option). Once you set a value for them it will always show by default.

[kriswilk]

I made it so that the dropdown options are only hidden by default if there is no value set on them yet (default option). Once you set a value for them it will always show by default.

@kspearrin Now I understand the screenshot. Thanks for the clarification, that sounds good.

[kobelobster]

Thank you for the feedback, the support and the communication @kspearrin. Now my part is due as promised:

[kspearrin]

"Full Hostname" has been renamed to just "Host", which is the URL property that we are actually checking against. Defined here: https://developer.mozilla.org/en-US/docs/Web/API/HTMLHyperlinkElementUtils/host

Hostname doesn't include ports.

[zestysoft]

That URL doesn't contain "Full Hostname" anywhere in the text. Is that even a thing? Did you mean FQDN? I couldn't find "rename" either.

The URL you provided has examples that clearly show ports being used:

anchor.href = "https://developer.mozilla.org:4097/en-US/HTMLHyperlinkElementUtils.host"
anchor.host == "developer.mozilla.org:4097"

Did you mean to give this URL instead?
https://developer.mozilla.org/en-US/docs/Web/API/HTMLHyperlinkElementUtils/hostname

The "HTML Living Standard" specification link in that URL you provided, states this:

hyperlink . host
Returns the hyperlink's URL's host and port (if different from the default port for the scheme).

Can be set, to change the URL's host and port.

hyperlink . hostname
Returns the hyperlink's URL's host.

Can be set, to change the URL's host.

So which URL property is Bitwarden checking against? Host or hostname? Can't it choose one or the other?

[kspearrin]

As mentioned in the previous comment, we are using host, which is what I linked and why it was renamed from full hostname.

[zestysoft]

So if it's using host, then it can check for ports. I guess I'm confused why this is even being discussed -- you said:

Hostname doesn't include ports.

Yet you aren't using hostname. Did someone else here want to use that instead?

[kspearrin]

No, we were just trying to figure out what the proper name for the different options were. I didn’t originally know what the name for hostname + port was so I made up a name called “full hostname”.

[danh-fissara]

I'm not convinced the document linked above is definitive as to whether 'host' includes the port, as it's documenting browser behaviour, rather than the RFC that describes URIs.

These both specify 'host' as _not_ including the port:
https://en.wikipedia.org/wiki/Uniform_Resource_Identifier#Syntax
https://developer.mozilla.org/en-US/docs/Learn/Common_questions/What_is_a_URL

Either way, as this is a browser security extension I don't think it makes sense to compare the port - the relevant bits for TLS are the protocol and host (not including the port).

[kspearrin]

The behavior of the option is to match a resource where the URI's host[ + ':' + port] are the same. Browser APIs define this as the host of a URL (spec linked above, hostname[ + ':' + port]), so we are using that property here.

I don't know if there is an official term for this value, but since the browser APIs call it the "host" that is what I am currently going with. If someone has a better alternative term for this option in the dropdown menu I'm open for feedback.

[isobit]

FWIW the Web Location interface calls hostname+port "host":
https://developer.mozilla.org/en-US/docs/Web/API/Location

It's unfortunate RFC 3986 doesn't give a name for hostname+port.

[kspearrin]

Also, is there a proper term for the "Base Domain" (what I currently call the default option)? This is another term that I just made up. Ex:

https://google.com => google.com
https://sub.google.com => google.com
https://sub.sub2.google.com => google.com
https://sub.google.com:4000 => google.com
https://localhost => localhost

[zestysoft]

Either way, as this is a browser security extension I don't think it makes sense to compare the port - the relevant bits for TLS are the protocol and host (not including the port).

In the world of Docker and virtual machines, port redirection is a thing. Matching based on port is required in these circumstances.

[zestysoft]

Also, is there a proper name for the "Base Domain" (what I currently call the default option)?

That's how I've always understood it. The TLD (Top Level Domain) + a name.

I think giving examples is a great idea though -- I know that in some of the forms I've filled out, instead of the field being a blank white box, it has got some grey text examples that are immediately overwritten when typing into the box.

[zestysoft]

However, the "proper" term is second level domain:
https://icannwiki.org/SLD

I assume, however, that since this software is going to be written for the masses, using something like "base domain" might be more intuitive?

[kspearrin]

I'll just leave it called "Base Domain" since noone outside of a domain expert knows that it is really called "SLD + Period + TLD".

[kspearrin]

If anyone is curious, here is the implementation for each "match detection" option: https://github.com/bitwarden/jslib/blob/master/src/services/cipher.service.ts#L177

[kspearrin]

Browser extension implementation now done. Screenshots:

[kspearrin]

@kriswilk Equivalent domains only apply to the default "Base Domain" option. None of the other options will use them since those options have higher precedence.

[kspearrin]

Screenshot of web vault support:

[kriswilk]

Great progress. Looking forward to trying it out!

[kspearrin]

Closing this since it's done for next release. Thanks for the feedback all.

[DoCode]

Where are the preview bits?

[kspearrin]

For anyone interested in beta testing this:

1. Now available on Android through the Play Store Beta.
   
   
   
   • https://play.google.com/apps/testing/com.x8bit.bitwarden
   
   
2. You can side-load the latest browser extension dev build.
   
   
   
   • Prebuilt versions: https://ci.appveyor.com/project/bitwarden/browser/build/artifacts
     
     
     
     
     
     • Or follow instructions on this repo's readme: https://github.com/bitwarden/browser/blob/master/README.md#buildrun
     
     
     
   
   
3. Install dev builds of desktop app:
   
   
   
   • Pre-built windows: https://ci.appveyor.com/project/bitwarden/desktop/build/artifacts
   
   
   • Others: Manually build using repo readme: https://github.com/bitwarden/desktop/blob/master/README.md#buildrun
   
   
4. Web app
   
   
   
   • Build from source here: https://github.com/bitwarden/web/blob/master/README.md#buildrun
   
   

Please let me know if you find any problems.

[mbudde]

After having played with the Firefox extension a bit I'm overall pretty happy with how it works. I have a couple of comments:

• Adding an URL to a login with the 'Host' setting does not cause the whole hostname to be shown when viewing (not editing) the login as I would expect. E.g. adding 'foo.bar.baz.com' with the 'Host' settings is shown as 'baz.com'. Similarly for the 'Starts with' and 'Exact' settings I would expect the whole URL to be displayed.
• For the 'Regex' setting I wish there was some easy way to test the regex against an URL. I needed a couple of tries before I got it correct and each time it involved first finding the login in the vault then view, edit, save, check if it matches.

[DoCode]

Ok, thanks @kspearrin!

Any points:
1) The Desktop installer doesn't have the feature included
2) For my scenario, many unique subdomains (sub1.sub.company.com, sub2.sub.company.com, sub3.sub.company.com, ...) the Host settings with the entries see below, works very good! 👌
3) For 2), it would good when we can set the 'Host' settings as default and parse this automatically from the URI when a new site is added

[benshep]

When choosing between match detection types, it might be nice to have some additional text in the dropdown box showing how the "base domain" and "host" options (in particular, but maybe the others too) will be matched. Crude mockup:

[kspearrin]

Anyone able to test out the android beta with these features yet?

[DoCode]

@kspearrin, today evening. I send you feedback after 8 pm.

[benshep]

Signed up for the Android beta. But I can't see the option to change the match type in the edit dialog.

It reminded me though - in the Android browser (I'm using Jelly on LineageOS), I get a bitwarden notification but it never matches anything since it's trying to match on the app ID - tapping the notification takes me to "Items for org.lineageos.jelly" and I have to manually search for the site I want. I assume this is a known problem?

[kspearrin]

On android, press and hold around the label for context menu options.

[benshep]

OK, found it. Not as discoverable as in the browser extension.

[kspearrin]

@benshep I am not a personal Android user so I don't know a lot about usability patterns there, but is that not a common way of attaching options to a section of information?

[benshep]

Yes, long-press is fairly common. But I don't think there are any other long-press options on that screen, so the user does not expect one. In my opinion it would make more sense to have a 'gear' icon on the right (cf the icons for 'view password' etc) which would be the same as the browser extension.

[DoCode]

@kspearrin, so sorry. The settings in the android beta works fine. But I only had chrome beta and edge installed. And for both bitwarden not working 😩

[DoCode]

@kspearrin - when we can expect an official release with this feature included?

[KenJyn76]

@kspearrin I'm not understanding, how does this interact with Equivalent Domains? I understand what both are used for, but what's stopping me from, say, deleting the Google > Youtube ED, and have URI 1 as http://google.com and URI 2 as http://youtube.com?

[kspearrin]

@pokemontotalwar Nothing is stopping you from doing that. Eq domains are global. Multiple URIs are for each individual login.

[KenJyn76]

@kspearrin Okay, awesome, thank you! I wasn't sure if it would work and I didn't want to go deleting eq domains before knowing if the multiple URIs would work for it. So really the main use for eq domains now is for sites you have multiple logins for and maybe apps. Is there a way to edit eq domains in anything but the web vault as of yet?

[kspearrin]

You can only edit eq domains in the web vault.

[kspearrin]

ALL:

The updates for multiple URIs + match detection options are now rolling out. I have created a help article that covers this feature in detail.

See here: https://help.bitwarden.com/article/uri-match-detection/

Please let me know if you have any feedback on the help article.

[Attoy]

Hey @kspearrin I linked it in reddit too. Hope you don't mind.

[SylwesterZarebski]

Thanks a lot! It also works with HTTP Basic Auth (when credentials are set properly to be only one for site).

[kspearrin]

This feature is now available on all platforms. Thanks for the feedback all.

[wbconnor]

@kspearrin Base URI matching isn't working for me on the Chrome extension for the URI pantheonsite.io I've tried all manner of fidgeting to get the match and have not been successful.

[luckman212]

When I click on that site, it redirects to pantheon.io - is that part of the problem?

[wbconnor]

Possibly. The URI which I actually navigate to is something like featureBranch-organizationName.pantheonsite.io

[fthiery]

Hi; thanks for this feature. However, right now it's quite hard to use for the following use case; my company creates many customer-specific subdomains (ex: customer1.domain.com, customer2.domain.com) and for sharing administration passwords we want to use bitwarden.

However, in the current way that this feature is implemented, every time i add a new login/password for a new subdomain (e.g. customer3.domain.com), bitwarden uses the base domain as default url matching method, so basically i need to log once, edit the rule to e.g. startswith instead of base domain (the default).

Is it planned to define globally the default url matching rule for a specific base domain ? That would be the opposite of the currently available equivalent domains menu.

[kspearrin]

@fthiery Yes, it is planned to add a global option to change the default. I don't have a timeline available for that yet though.

[fthiery]

Great, thanks; is the spec defined yet in another issue (if i can bring my 2 cents) ?

[gene1wood]

For anyone (like me) that could only find this in the web (vault.bitwarden.com) but not in the browser extension, you can find it by going to

• Your browser extension vault
• The credential you want to edit
• Click Edit
• Within the credential where it shows the URI in the field URI 1, to the right is a gear icon
• Click the gear icon to get to this feature

[Crocmagnon]

@gene1wood it’s explained here : https://help.bitwarden.com/article/uri-match-detection/

« While editing a login you can adjust the match detection value for a given URI by selecting the ⚙️ Options button next to the URI’s value. »

[StefanoChiodino]

This is great! Would be nice to have it select the best options for known cases like slack!