1Password Not Respecting Domain Exclusion List On Password Update

willhy

I had read previously that it was possible to exclude certain domains from 1Password's auto save prompt.

https://discussions.agilebits.com/discussion/18270/exclude-some-websites
https://discussions.agilebits.com/discussion/11054/any-way-to-tell-1password-to-ignore-specific-sites-domains
https://discussions.agilebits.com/discussion/28164/where-is-never-for-this-website-option-to-disable-auto-save
https://discussions.agilebits.com/discussion/28328/is-there-an-exception-list
https://discussions.agilebits.com/discussion/63995/is-there-any-way-to-stop-1password-from-storing-a-password-for-a-particular-site
https://discussions.agilebits.com/discussion/78890/can-i-stop-1password-mac-from-asking-me-to-save-passwords-on-certain-sites

I've done as directed, and I am excluding localhost in my domains list. It seems to work great for my login page, but not for my password update page.

If I remove the domain exclusion I get prompted when I log in at http://localhost. If I re-add the exclusion, the prompt goes away. So clearly the exclusion list works

However, that exclusion is not being respected when I update my password at http://localhost/profile.

I see the password input getting tagged with this attribute. data-com.agilebits.onepassword.user-edited="yes" on my /profile page.

I'm not sure what more I can do to get 1Password to ignore my domain for this subdirectory. This is probably only affecting me and is somehow related to my app, but would love any feedback. My site is a SPA if that may make a difference.

---

1Password Version: 6.8.3
Extension Version: Not Provided
OS Version: macOS 10.12.6
Sync Type: Not Provided

bundtkate

@willhy: A bit of a guess on my part here, but I'm wondering if 1Password is possibly interpreting http://localhost/profile as a separate domain because localhost itself isn't exactly a standard-formatted domain. The Mac app is actually what is handling the exclusion process and not the extension, and unfortunately our Mac developers are out for the day so I can't confirm my suspicions right now. Do you have other localhost pages with a sign-in or password change screen available to see if this extends beyond localhost/profile? If you add localhost/profile to your exclusion list, is it properly excluded? We definitely want 1Password to respect this exclusion across the domain, but this is at least a decent way to test my theory so I can pass along good info to the development team. Thanks! :chuffed:

willhy

Thanks @bundtkate. I tried adding localhost/profile as well, but no luck. I also tried variations on localhost (see attached). Unfortunately, none of them seem to work.

This only seems to happen on /profile, though I do have other pages with password update forms. I do not get the prompt on http://localhost/password-reset?action=set&token=eyJhbGciOiJBM...

On /profile, I get the prompt regardless of whether or not the update succeeds.

dalton

Thanks for those details and screenshots, @willhy! By adding localhost as an exception when saving new Logins, that should effectively cover all paths associated with localhost. It's odd that localhost/profile is specifically giving us trouble, though. Can you try adding 127.0.0.1 as an exception alongside localhost and see if that offers any improvements?

Thanks for trying out these suggestions! We appreciate you sticking with us here. :)

AGAlumB

@willhy: I apologize if I'm misunderstanding, but just to clarify: it sounds to me like you're saying that 1Password is offering to update saved logins. Is that correct? If so, that makes sense, as the "exclude" list is for saving new logins, not updating existing ones. But if I've completely misunderstood what you're talking about, let me know. I'm just not seeing this behaviour otherwise.

willhy

@DaltonD Thanks for the suggestions. I tried adding the loopback adapter to the exclusion list like you advised, but it made no difference. I tried killing/restarting 1Password and Chrome as I did my testing, but no luck. My app makes all network calls through localhost and shouldn't ever be talking over an IP, but I added it to the list all the same.

This is my current exclusion list.

localhost
localhost/profile
http://localhost/
http://localhost
http://localhost/profile
http://127.0.0.1
http://127.0.0.1/
http://127.0.0.1/profile

@brenty sorry, but that is not correct. 1Password is offering to save a new login, and not to update a saved login. I do not have any saved logins for localhost. When I hit the /login route on my app, 1Password seems to honor the exclude list and does not offer to save my credentials. However, it does ask to save my credentials when I use /profile.

If I remove the exclusion, it prompts me to save my credentials at both /profile and /login, so clearly the exclusion list works, but for whatever reason does not seem to be respected on my /profile page.

I tried to re-create the problem using a simple HTTP/server-based python app on my machine and I could not recreate the issue.

I also tried creating a demo single page app (I develop on Ember) and I could not recreate the issue.

It must be something specific to my app that's not playing well with 1Password. :-/

Since that seems to be the case, I guess I'd say not to worry about it too much. Hopefully I'm just a rare exception.

littlebobbytables

Hi @willhy,

Brenty's confusion was probably my fault. When I read your original post it was the phrase "on password update" that made me believe this was referring to a password change form. I have a request. I would be very interested in seeing the contents of a Login item saved from the problematic page. If you're interested can you:

1. Using dummy details, trigger the 1Password Save Login item prompt on the /profile page and save a Login item.
2. Enable the Copy JSON option in the Advanced tab of 1Password's preferences.
3. Select the Login item and use the menu option Item > Copy JSON. This will place a plaintext copy of the item in the JSON format into the macOS clipboard.
4. Paste that into a reply here so we can see what 1Password has saved.

Now if you're uneasy at all about pasting that here we can move to email if that would make you more comfortable and I'm more than happy to do so. Like yourself I would like to learn why the exclusion list isn't being triggered here if it isn't a change password form.

willhy

@littlebobbytables see below. I filled in some dummy data for the input values, but aside from that this is the exact content of the Copy JSON command after I saved my login item (and after running it through jq for pretty formatting).

It's interesting to see that, even though this was a Save Login item prompt, it saved all the fields on my /profile page. Old password, new password, username, email address. It took them all in, even though those fields are spread across two distinct form elements. You can see that both Save buttons are tracked below.

Form1 has inputs for the old password, new password, confirm password, and a <button> to trigger the AJAX action and handlers.

Form2 has inputs for the username, job title, email address, phone number, and a <button> to trigger the AJAX action and handlers.

{
  "sectionName": "L",
  "details": {
    "sections": [
      {
        "title": "Related Items",
        "name": "linked items"
      }
    ],
    "htmlForm": {
      "htmlMethod": "LB1"
    },
    "fields": [
      {
        "id": "ember393;opid=__0",
        "value": "Toggle navigation",
        "name": "",
        "type": "B"
      },
      {
        "id": "ember788-field;opid=__1",
        "value": "password",
        "type": "P",
        "name": "",
        "designation": "password"
      },
      {
        "id": "ember792-field;opid=__2",
        "value": "Password1",
        "name": "",
        "type": "P"
      },
      {
        "id": "ember796-field;opid=__3",
        "value": "Password1",
        "name": "",
        "type": "P"
      },
      {
        "id": "ember800;opid=__4",
        "value": "Save",
        "name": "",
        "type": "I"
      },
      {
        "id": "ember814-field;opid=__5",
        "value": "MySystem Admin",
        "name": "",
        "type": "T"
      },
      {
        "id": "ember818-field;opid=__6",
        "value": "",
        "name": "",
        "type": "T"
      },
      {
        "id": "ember822-field;opid=__7",
        "value": "admin@mysystem.com",
        "type": "T",
        "name": "",
        "designation": "username"
      },
      {
        "id": "ember826-field;opid=__8",
        "value": "",
        "name": "",
        "type": "T"
      },
      {
        "id": "ember830;opid=__9",
        "value": "Save",
        "name": "",
        "type": "I"
      }
    ]
  },
  "uuid": "hfkt3k5cnbdb5f2anbmtjsthia",
  "updatedAt": 1508768975,
  "createdAt": 1508768970,
  "categoryUUID": "001",
  "overview": {
    "title": "localhost",
    "url": "http://localhost/profile",
    "ainfo": "admin@mysystem.com",
    "ps": 1
  },
  "URLs": [
    {
      "overview": {
        "label": "website",
        "url": "http://localhost/profile"
      }
    }
  ]
}

littlebobbytables

Hello @willhy,

That's great, thank you for supplying that. Now I will need to verify with one of our Mac focussed developers but what I feel confident in saying is the extension will be seeing the three password fields and flagging this as a change password form. Where I will need confirmation is, my understanding is 1Password doesn't use the ignore list for change passwords and it isn't making the distinction between updating an existing Login item for a site you've added to the ignore list (for whatever reason) and for a site you really don't want 1Password bothering you about full stop and have no intention of creating a Login item for ever. So it looks like this page circumnavigates the ignore list because it looks like a change password form (3 password fields, two with the same password) and 1Password believes it should ask anyway. I'm not entirely sure of the full ramifications but maybe it could only ask if there is an existing Login item where the domain is one on the ignore list.

willhy

Thanks @littlebobbytables! I appreciate the efforts of you and everyone on the team. I'll be interested to hear what the Mac Devs come back with.

Lars

@willhy - thanks! Stay tuned... :)

MartinNuc

Any news?

littlebobbytables

Hello @MartinNuc,

I apologise, I forgot to follow this up. I don't have any news I'm afraid and I'm not sure what we'll do. Having gone back and re-read the entire conversation I am reminded of the fact that the page is designed in a way so that it looks like a change password form rather than a sign-in form. Sometimes a page just does something so unusual that trying to account for its behaviour would have a negative impact on too many other places and this might be one of them. It may be we decide that excluding a domain means we ignore any and all messages from the extension. I can't make up my mind which is better and I don't think it's the case of there being a right or wrong answer.

ref: apple-2216

MartinNuc

In my case I do a web development on localhost. I also run automatic tests and during these tests 1password pops up despite I have localhost in ignored domains. Also I have checked "Never save password for this site". After I dismiss it it stops appearing for some time.

littlebobbytables

Hello @MartinNuc,

Some days I wonder if I ever woke up properly. I've just realised that the first part of the conversation wasn't with you and that means the issue that willhy was facing may not apply to you. The issue they have is because that page looks exactly like a change password form and I would hope that most of the pages you're interacting with don't share this trait.

I'm trying to find a quick and easy way to test stuff on localhost that doesn't involve having to jump through lots of hoops with their "quick" install steps so I can make sure I can state something conclusively.

MartinNuc

Oh I see. Well my problem is just that having localhost on the list of excluded domains is ignored. Which is basically what title of this thread says :-) so I hoped it would help me.

littlebobbytables

Hi @MartinNuc,

I haven't forgotten about you but trying to find something easy to set up that runs as a local server is proving stupidly difficult. If you've got any suggestions for something that can be quickly fired up please let me know. It really shouldn't be difficult, I don't know why I'm managing to make such a meal of it.

johnog

@littlebobbytables This is biting our dev team every day. If I provided you a small app to run locally that would reproduce this problem would you be able to run it? Would require you to run something on the command line and install some dependancies. I would provide full instructions.

littlebobbytables

Hello @johnog,

I'm more than happy to give something a try and finally see if we can restore some sanity to your 1Password usage for you. I'll send an email and we can continue the conversation there. I just can't believe it's that hard to find something that runs locally with a sign-in page that doesn't require massive mucking about. I must be missing something obvious.

madsb

I'd love for this to get a resolution. It's biting me too.

littlebobbytables

Greetings @madsb,

In the end the best option we could suggest was to test in a separate Chrome profile, one where the 1Password extension is not installed. For one user they needed to run a battery of tests in the browser that included things like the change password form. As 1Password does not respect the ignore list for change passwords this caused a response. Proposals suggesting to simply ignore localhost completely were dismissed promptly so that possible approach has been eliminated. There also isn't any enthusiasm for having the ignore list apply equally to change password forms. Given all of that it seemed a separate Chrome profile was about the one route that would work for those affected based on how 1Password currently works.

BertC

Hello,
The above workaround dates from February this year. The original question dates from 2017.
Is this bug so hard to solve? It's very annoying for developers working with local webservers and local client app to have 1Password kick in every time you test something on your localhost dev-environment.
The Browser-tab in the Preferences is quite clear: "Detect new usernames and password", "except on the following domains".
So, what am I doing wrong in putting "localhost" in there?
Does that setting just not work for localhost?