Multiple applications with separate authentication on same server with different context roots

Options
josha
josha
Community Member

I have looked through the forums and I haven't found out how to do this but I'm sure the application supports it, just confused at how to setup the password entry.

In my use case, I have a server that has multiple apps on it but they are different at each context root, ie:

https://servername/foo
https://servername/bar

I have an entry for both applications foo and bar, and they are different credentials with the fully qualified servername/foo or servername/bar contexts as the website url, however the iphone prompt that is using the 1password credentials always picks the wrong one because it just shortens it to the servername.

I can pick an option a few links lower that is just 1Password... that will list all of the applications with similar servernames and I can pick the correct password from there.

Is there a better way to setup the password entry so that 1Password will pick the right credentials based on the full URL?


1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided
Referrer: forum-search:context root

Comments

  • AGAlumB
    AGAlumB
    1Password Alumni
    edited March 2019
    Options

    @josha: I'm not sure why you're saying that 1Password "picks" anything. Certainly if both Login items have the same domain in the URL, both will be matches at that domain, but you'd need to select one. 1Password can only fill right away when you select it if there is only a single Login matching the current website; if there is more than one, it gives you a list to choose from. If you're seeing something else, there's probably something you're overlooking/not mentioning about the URLs that is different. It might be relevant, and necessary to really give an accurate answer.

  • josha
    josha
    Community Member
    Options

    I guess my point is the integration with an iphone doesn't cleanly pick the appropriate password when you have multiple applications on the same server/domain name with different context roots. I will take a screen shot of this the next time and hopefully it would provide better clarity of what I am seeing.

  • josha
    josha
    Community Member
    edited March 2019
    Options

    Using safari on the iphone, there are multiple apps at the jma.XXXXX.com domain name, which switch based on the context root /foo, /bar, etc that I was describing above. Each of the apps have a different password, and there is no usable way to use the pictured integration to use the appropriate password. Is there a way to have the integration take into account more of the URL? IE can it recognize the context root after the .com?

    [image removed by 1Password staff because it included personal information -- this is a public forum] 

  • AGAlumB
    AGAlumB
    1Password Alumni
    Options

    @josha: How do you anticipate 1Password "picking"?

    Bear in mind that for the vast majority of users and use cases, it would be a very bad thing to only show matches for an exact URL. Millions of people at https://appleid.apple.com/#!&page=signin would not be able to find a Login item that was saved at https://appleid.apple.com/account#!&page=create or another Apple subdomain/path in that case. I get where you're coming from, but we really need to consider the entire 1Password userbase.

    Anyway, that's why we do things the way we do in our extensions. But more relevant in this case is that 1Password doesn't handle any of this on iOS; the OS does, as iOS 12 Password Autofill is a system service. We wouldn't change this if we could, for the reasons above (though that's just scratching the surface with one example), but it isn't even under our control there. I'm sorry that isn't what you were hoping to hear, but hopefully it sheds some light on things.

    Note: We've removed the image from your post to protect your privacy, since it wasn't clear that it was test data. Please be careful what you share on a public forum. <3

This discussion has been closed.