Exact URL matching

I know there are tons of topics on this subject, but they are all old, and a lot has changed in the browser world. Further, I didn't see any fixes in those threads outside of "making sure the URL is precise as possible" which they are.

I have many different logons to various subdomains and subpaths to our corporate website, and they all show up upon auto-fill. How can I get an "exact match" to actually be an exact match? I tested in latest versions of both firefox (my main browser) and chrome.

I need it to give me the exact match under the following conditions...

  • www.mysite.com/login
  • www.mysite.com/otherlogin/
  • www.mysite.com/somepath/otherlogin.php
  • subdomain.mysite.com/whatever

Right now, if I have 4 different logons for each of the above domains/subdomains/paths, all 4 show up even though the path is precisely exactly as it shows in browser.


1Password Version: 6.8.492
Extension Version: 4.6.12.90
OS Version: Windows 10
Sync Type: default?

«1

Comments

  • DaltonDDaltonD

    Team Member

    Thanks for getting in touch, @syntax53! 1Password displays matches based on the domain and subdomain. When visiting subdomain.mysite.com/whatever, your Login for this specific subdomain should be displayed at the top of the list. When visiting all paths on the mysite.com domain, all Login items related to that domain should be listed.

    Hopefully that clears things up for you. Let us know if you have any questions! :)

  • So you can't further match against path??? Is that something in the works? I just came from LastPass and this is a pretty big missing feature if that's the case.

  • DaltonDDaltonD

    Team Member

    @syntax53: It's not currently possible to match a Login with a specific URL path and that functionality isn't something we're currently working on. Jamie, one of our extension developers, has shared further details regarding this type of matching in the past. His explanation is still current:

    https://discussions.agilebits.com/discussion/comment/348474#Comment_348474

    If you have any further questions, be sure to let us know.

  • syntax53syntax53
    edited January 2018

    I see the logic and understand the reasoning. However, it seems like you could still accomplish both goals of keeping data encryption and storing only hashes, albeit possibly using a tiny bit more memory. You could at least store the beginning 1 or 2 folders as part of the hash, or as an additional hash.

    So with the following URL, "www.mysite.com/somepath/login.php", I assume you store two hashes based on what I read:
    1 hash corresponding to "www.mysite.com" and 1 hash corresponding to "mysite.com".

    What I am proposing would be to store at least 1 additional hash, corresponding to "www.mysite.com/somepath" (the first folder or file level) as that is most likely what is going to be initially different and help the majority of users. I can't imagine that would be very hard to code an additional hash to store in memory and then match against.

    If this is not the right place to post an enhancement request, where would one do so?

  • jxpx777jxpx777 Code Wrangler 1Password Alumni

    You're right, @syntax53. We could technically do what you're describing. We could probably even get away with not storing any additional hashes and bubble up path matches after we've decrypted the Logins that we match by the hashes, i.e. find the Logins that match the current site by hash, decrypt those Logins' overviews and then further sort by how well they match the path.1 So, what you're talking about (or something similar) is not impossible by any means, and actually sounds like it would be a fun bit of functionality to build when I consider it at the surface.

    But, what's more challenging is making the behavior intuitive and describable to users. I've been working on 1Password for almost ten years now, so I have some benefit of having seen what this might look like. The comment that Dalton linked to gives more detail about this and how we handled it in 1Password 2. We know that users are already confused by the current behavior, especially when they bump into the fringes of the logic such as how herokuapp.com is treated. And the handful of us that have been around 1Password long enough remember that the 1Password 2 behavior was even more confusing to users. And then we have to factor in that more modern versions of 1Password allow multiple URLs for an item, and it can be confusing for users if some URL far down the list either is or isn't taken into account when sorting the list.

    The "obvious" and "simple" answer is to just have 1Password do the right thing and always choose the correct Login, without any settings to control this behavior and without any indicators that indicate 1Password's understanding of how your particular set of Logins matches the current page. Unfortunately, there are lots of edge cases to consider.

    Here's one scenario that would not be at all uncommon: Many sites have multiple sign in pages that will accept the same credentials. If I save my American Airlines frequent flyer information from the home page and my wife saves hers with the dedicated sign in page and we share our Logins with each other, then when I press Command-\ when I visit the homepage, my Login would be filled, but when my session times out and I want to sign back in, Command-\ actually fills my wife's Login! Obviously this isn't the right thing to do, but with URL path matching (and no additional complexity such as tracking which Login was used within a given tab in the extension), 1Password is behaving properly but totally confusing the user. I have access to the source code but if I'm in travel planning mode and not in developer brain mode, I myself might be peeved at the behavior even though I should know what to expect!

    It's not easy for us to say "no" to ideas that are not technically impossible, and as a user, it's not fun to hear "no" when you ask for something. We really do value and carefully consider all feedback and ideas. Much of what 1Password is today is because of passionate users like you.2 But, I hope this makes sense and gives some insight into the kind of real thought we've put into this question not just in the year since the comment Dalton linked was written but in the decade plus that we've been building 1Password and trying to make it useful and convenient enough to make secure behavior the default for the greatest possible number of people.

    --
    Jamie Phelps
    Code Wrangler @ AgileBits
    Fort Worth, Texas


    1. I'm setting aside for now the slippery slope of starting with something like a first path component match and having users ask for full paths and then query strings. One of our internal tools would actually be quite nice to filter against query string… :smile: ↩︎

    2. A fairly recent and prominent example: one of the reasons the 1Password.com service exists is because of ideas and pain shared with us by friends in corporate environments who were 1Password fans but were forced to use a competing product at work because the standalone app didn't have some of the management features that were required. ↩︎

  • Firstly @jxpx777, I appreciate the detailed response.

    I am also a software/web developer (no longer my full-time gig as I am now a net admin) and my initial reaction regarding creating features / options that "confuse users" is to just figure out a way to implement them or describe them better so that they don't. If you have people asking for a feature (evident by the number of posts on this topic) it's unfathomable to me that one of your primary reasons for not implementing such a feature is that you can't figure out a way to do so without confusing users. A potential solution to that is to make "more exact" URL matching an advanced option. Something people need to turn on themselves to give them advanced capabilities.

    Regarding your example scenario, there are solutions there too.

    • First of all, with your current implementation of 1Password using the same exact scenario, wouldn't control+\ currently pop up a window asking which logon to use since there would be multiple domain matches? I've rarely use the command+\ shortcut as I find it easier to keep my hand on my mouse (right click -> 1 password in the context menu) then to switch to a keyboard and back while web browsing. However, I just tested it out with various sites and I see it does auto-fill and then login, but only for sites where there is only 1 match.
    • So with that said, a simple solution to your scenario while implementing my request of advanced URL matching, simply retain your current method of only auto-filling automatically if there is only 1 domain match. And then if there are more than 1 domain match, show the same pop up, but put the exact URL match(es) first.

    Lastly, to be clear, none of what I am referring to was the quick automatic fill. Right now on my corporate website I have 22 different logons for different accounts and paths. I have favorited the ones I use the most which helps, but it's still a PIA every time I need sift through the list. I usually resort to typing a partial match for the logon I know I want to use to filter it further.

  • jxpx777jxpx777 Code Wrangler 1Password Alumni

    A potential solution to that is to make "more exact" URL matching an advanced option. Something people need to turn on themselves to give them advanced capabilities.

    This is actually what we have in 1Password for Mac right now and it actually creates more confusion rather than less. I've said before that I don't like the label we have for that setting. (I'll head this off at the pass and tell you this does the opposite of what you're asking for. :wink: I'm glad we don't have a setting for this in 1Password 6 for Windows.)

    Simply changing the order of the offered Logins isn't a complete solution either. I'm thinking of some of my freelance clients and how they would react to seeing the order of their Logins change in the frequent flyer scenario I mentioned above. "Why is my Login first on this page and their Login is first on the second page?" Even that little bit of inconsistency would lead to confusion and worse yet, interrupted muscle memory that would make using 1Password have more friction than we want. If you have to choose from a list each time, at least if the Login you want is at the top, you can just press the return key and move along.

    What we have found from experience is that in general, users don't really pay that close attention to what URL they're on when a Login gets saved or where redirects eventually land them. Another scenario would be when someone has https://www.gmail.com in their Login's website field. If they go to their browser and type www.gmail.com, that eventually lands them on accounts.google.com So, even though they typed in gmail.com and their Login has gmail.com, we're not going to bubble that up to the top.

    I'm sure I could think of more scenarios than this too and I'm even more sure that there are still more scenarios I wouldn't think up until a user contacted us. But all of this doesn't actually help with the problem that you have, which is that you have many Logins for the same hostname and presumably no ability or inclination to have those live at different hostnames. There are a few strategies that might be able to help:

    1. Use the same username and password for each of these Logins, particularly for any test accounts. This isn't exactly advocating for password reuse since they are all for the same site but different applications.
    2. Hide the Logins you use very infrequently from the extension listing. You can do this by editing the Login and unchecking the Display checkbox. (On Mac, this is a drop down list with "Never" in it, for uninteresting historical reasons.) This doesn't mean that you can't use the Login to sign in to the application; when you need to use that Login for that application, you can use open and fill from the main 1Password application by clicking the URL from the item's details.
    3. Organize the Logins into separate vaults. For instance, if some of these Logins are for testing, you could put the test accounts into a vault dedicated to testing. Exclude this vault from All Vaults and then you'll only see your normal browsing Logins in the normal course of things and can switch to the testing vault when you need to use those Logins. You can also still use open and fill from this vault as well.

    I hope those options help alleviate the struggle you have with this large list of Logins. Again, we definitely appreciate hearing from you and hope you'll continue to share your challenges and ideas for how 1Password can be a better tool for you. We know that users like you find these rough spots because you're really putting 1Password to use in heavy duty ways and relying on it to help you get your work done. Sometimes such unusual circumstances (in the grand scheme, not just among us developers) reveal something we should be doing differently and sometimes they necessitate slightly adjusted workflows to help mitigate the friction. I really think this is probably more the latter than the former, but we'll keep listening. As we're fond of saying around here, "No decision is final." :chuffed:

    --
    Jamie Phelps
    Code Wrangler @ AgileBits
    Fort Worth, Texas

  • I just want to add my voice to list of users.
    We desperately need this, especially in a systems admin role.

  • jxpx777jxpx777 Code Wrangler 1Password Alumni

    Thanks!

  • I hate filling up threads like this with "+1"'s, but this behavior is something that really drives me nuts with 1Password.

    I use a number of sites with reverse proxies with different logins across multiple urls, but same domain. In some cases, I have 11 items to choose from when trying to fill a login. Not a great user experience. :(

  • Greetings @tkeeler,

    While I can sympathise that it will feel frustrating, your scenario is not a common one. This doesn't mean your point of view will be disregarded but decisions and impacts have to be justified. If a change helps a very small percentage of power users but has the potential to confuse the larger userbase then it is extremely unlikely the change will gain the support needed. Even small things, like whether we call the key associated with 1Password accounts the account key or the secret key has a massive impact and that's just a single word.

    The discussion is not closed but we do have to consider the entire userbase when making decisions.

  • +1ing this as well. This is driving the crazy. I have had to recently go through all my logins and rename them so I know which sub site or third level that specific "admin" account is for.

  • jxpx777jxpx777 Code Wrangler 1Password Alumni

    Thanks for your input, @crkinard!

  • edited June 2018

    Popping in to add my +1 to this request. I have several servers with a few apps running on a single domain/subdomain that require separate logins. I had been dealing with it, but it has become an annoyance so I went looking for the solution, which led me here. For some reason I remember a per login setting that was something like "Match only this URL" in a previous version of 1Password. Thanks for the detailed responses, and for always listening to customers on the forum, AgileBits folks.

  • Greetings @fatherfork,

    I don't have any recollection of that particular option but it's one I've seen Jamie refer to and from reading his replies here and those linked to from this thread the feeling was that it caused a lot of confusion and that's why we got rid of it. You also have to factor in a changing user base. I've seen Dave say back in the very early days of 1Password support was a lot easier as password managers were mostly used be the very tech savvy and the typical user solved a lot of their own questions with sparse documentation. Things have changed a lot and a password manager is something that needs to be accessible to everybody, nobody can afford to be without one. So if the exact URL matching was causing confusion back with the much smaller user base of 1Password 2 where the average user was quite tech savvy, what kind if impact would it have on a much more diverse range of comfort levels? In 1Password 7 we got rid of the option that allowed disabling preferred ordering for exact FQDN (Fully Qualified Domain Name) over those that just matched the registered domain because we only ever saw it causing trouble. If we added an option and didn't get it just right we're risking causing huge amounts of frustration that outweighs the gain for the small group of people that would see value. This isn't to say an outright no, but simply adding another option can have a serious impact if not done carefully.

  • @littlebobbytables

    I appreciate this balance you refer to and understand the reasoning behind the current set of options. Thanks for having this discussion and considering our views. I've been a 1Passwd user for a long time and will continue to be because I trust you as a company. This cannot be overstated.

    I'm not really going anywhere with this. Just, thanks.

  • It's all good feedback @fatherfork :smile: Learning where 1Password might be lacking is important and it might be we need to reevaluate our decision here. Learning how important it is and how many are affected is certainly a factor in any decision.

  • Just popping in to add my $0.02. What about an alternate approach? Instead of trying to automatically detect what situations do or don't require a stricter form of URL matching, why not just add a global "exact URL" list, where users can map URLs to an existing logins on a one-to-one basis? Then if the current URL is found in the list, its corresponding login would be raised to the top. In the situation mentioned above with various different localhost domains, you could just have (localhost/foo -> Login 1), (localhost/bar -> Login 2), in your URL list.

    It seems to me that this would allow at least some of the functionality people are looking for without introducing unnecessary confusion, because its scope would be narrow enough that it would never show up unwanted.

    The downside is that the user would have to manually define the mapping for each URL, but it sounds like most of the people asking for this feature (in this thread at least) would be willing to do that.

  • I’m completely on board with @jfmonty2’s proposed solution.

  • brentybrenty

    Team Member

    I guess I can see the appeal for folks who just have a few logins they'd like to do this with, but the people we usually hear from requesting something like this tend to have a ton (e.g. web devs or admins). So it seems like this would be only marginally useful to the primary intended audience (at least from what I've seen). It's definitely an interesting idea, but it seems like a huge compromise — and one that could also cause confusion for people not at all interested in this feature. It's something we can consider, but we want to do what we can to ensure that changes to 1Password's core functionality — login filling — are a net gain. And I'm not sure this is a win. Food for thought.

  • I don't think this works:

    When visiting subdomain.mysite.com/whatever, your Login for this specific subdomain should be displayed at the top of the list.

    Because when I visit "test.something.com" the logins for "something.com" and also other subdomains like "yyy.something.com", "www.something.com" all appear above in the list.

    It's like it's reverse sorted with the most relevant result at the bottom. As a regular user I'd expect the most closely matched domain to be on top, then the general domain, and lastly the non matching subdomains with the same top domain.

    I'm using 1PasswordX on Chrome latest version.

  • Greetings @jenspa,

    1Password X is our newest offering and as it is a standalone extension its behaviour could differ from the native clients. Let's see if @DaltonD can shed any light on 1Password X's behaviour.

  • DaltonDDaltonD

    Team Member

    @jenspa: Since 1Password X was built independant of the other 1Password applications, we took a bit of a different approach and chose to initially display all Logins that match the current domain. This includes subdomains, so a.example.com and example.com will appear together. There are certainly some improvements to consider here, such as more convenient sorting, as the list is currently sorted alphabetically.

    I have no doubt that we'll revisit and iterate on this approach in the future, but in the meantime, I've found that searching (by typing into the active field) while the inline menu is open provides a quick way of narrowing down larger lists.

  • That explains it. And thanks for the tip about searching the drop-down.

  • brentybrenty

    Team Member

    :) :+1:

  • wiserwebwiserweb
    edited August 2018

    I think this needs to be changed ASAP, IMHO it is a BUG.

    1st I should be consistent across all clients.
    2nd, it's bad for the UI
    3rd, it's bad for the day-to-day usability
    4th, it's not a feature, it's a bug

    Allow me to illustrate, here's a common domain configuration for a small business.

    gitlab.company.com - user1
    gitlab.company.com - root user
    gitlab.company.com - employee login1

    projects.comanpy.com - user1
    projects.company.com - root user
    projects.company.com - backup user

    cdn.company.com - user1

    webmail.company.com - user1

    cloud1.company.com - ssh user
    cloud2.company.com - ssh user (x 10)

    kanban.company.com

    crm.company.com

    staging1.company.com
    dev1.company.com

    I could go on...

    This creates a nightmare when trying to use 1Password to choose the correct login for any domain when the list displays them all.

    Hypothetically speaking I'm unable to see a valuable use-case where any user would want to use the login credentials of another sub-domain.

    Practically speaking, in the 10,000's of logins I have done in the last several months I have not found a single instance where I would need to use anything other than the current domain's login credentials.

    This is why I would file this under a BUG.

    Do the other password managers out there provide users with a list of all subdomain logins that cannot be used to login on the current domain?

  • brentybrenty

    Team Member
    edited August 2018

    @wiserweb: Thanks for your feedback. It's good to know individual users' specific use cases. But this is not a bug.

    The reality is that your use case is not typical. For the vast majority login credentials do apply across whole domains — www.amazon.com, smile.amazon.com; www.apple.com, appleid.apple.com; mail.google.com, accounts.google.com; etc. are just a few of the extremely common examples which run counter to you being "unable to see a valuable use-case where any user would want to use the login credentials of another sub-domain". Most people simply don't spend their entire lives within a single domain, using subdomains of it with different accounts for completely different purposes.

    However, we do to some extent ourselves, with a ton of *.1password.com and *.agilebits.com subdomain logins. So this isn't something we're insensitive to. In fact, thats why, while it will display all logins matching the domain, 1Password mini puts subdomain matches for the current URL at the top, as mentioned above multiple times:

    Are you seeing something different? The only time I even need to use the mouse or keyboard to select between them before filling is when I have more than one match for the current subdomain.

  • You never know, I've already spent 20 years behind a few domains I own so it's not implausible that others will spend quite a bit of time under their own domains names, which would feel like a lifetime to some.

    I see what you're saying with amazon, but do you need 10 different logins to use their services. It's not important.

    Can't this be made configurable quite easily as we're dealing here with exact match and partial match logic?

  • brentybrenty

    Team Member
    edited August 2018

    You never know, I've already spent 20 years behind a few domains I own so it's not implausible that others will spend quite a bit of time under their own domains names, which would feel like a lifetime to some.

    @wiserweb: People do it. I'm saying that. We do here. It's certainly not uncommon in this field. But the vast majority of human beings on this planet, even those who use the internet and are in the market for a password manager to help with that, do not own their own domain names, and most that do don't host a bunch of discrete web services themselves as subdomains there. That's not to say your use case doesn't matter. It would be crazy for us to ignore, since ours is similar in some ways. But that's just not a situation most of our customers find themselves in, and we really need to design around broader usage since it benefits more of those people.

    I see what you're saying with amazon, but do you need 10 different logins to use their services. It's not important.

    "Not important" to whom? I know a lot of people have only one, but many still have multiple, especially folks who make heavy use of AWS and seller accounts. It's all relative. That's all I'm saying.

    Can't this be made configurable quite easily as we're dealing here with exact match and partial match logic?

    What exactly is the problem you're having? Do the subdomain matches not show at the top for you? I haven't heard any reports to the contrary, but it's certainly possible there's a bug somewhere.

  • I'm pointing to the fact that how we arrive to have multiple logins for a tld is not important. The point is that there's more than one use case where partial subdomain match is sub-optimal than an exact match.

    As I explained, for server.domain.com, the list should not show projects.domain.com as a login option. Period.

    But that's just not a situation most of our customers find themselves in, and we really need to design around broader usage since it benefits more of those people.

    IMHO this is flawed logic.

    Power user's (developers et al) experience does not have to be degraded in order to meet the needs of other users. An option to configure how sub-domain match is handled based on user's needs is how to remedy this issue so that all cases are gracefully handled.

    Asking the wrong questions gives you the wrong answers.

    The typical user does not perform nearly as many logins on a daily basis as a developer. So is 1Password designed to be used by users who login less frequently than users who login more frequently?

    The question is, who uses the autocomplete feature the most on a daily basis. The answer is, developers by any metric you can use.

    Therefore, make it correct for the developer then it will be definitely sufficient for any user.

    It just feels that you're telling me that 1Password is the wrong tool for me as a developer as it's designed for 'broader usage' since it benefits more those 'people'.

Leave a Comment

BoldItalicStrikethroughOrdered listUnordered list
Emoji
Image
Align leftAlign centerAlign rightToggle HTML viewToggle full pageToggle lights
Drop image/file