Don't want one-time password filled


  • snowysnowy
    edited January 2019

    This is still persistent for me.
    1Password 7.2.4, macOS Mojave, Safari 12.0.2

    I have an entry with 6 websites. One requires OTP. I removed everything but the secret part in the URL for the OTP. Problem persists

    I also tried adding the longer URL in the 1P entry. Problem still persists

    The only oddity is the root URL is used as a re-direct for 2 sites one that requires OTP and the other does not.
    The one that doesn't require it. Always has the OTP pasted into UN and PW field.

    Entry in 1P (just URL that has issue)


    one site works and the other has the behavior described above.

  • brentybrenty

    Team Member

    @snowy: This discussion is about a resolved issue with an entirely different website. I'll split you off into a new discussion since your comments seem to be unrelated to that.

    It isn't possible for us to troubleshoot without any details, but if you'll let us know the actual URL involved along with the specific browser and extension versions you're using and steps to reproduce, we'll be happy to test it.

  • snowysnowy
    edited January 2019

    1Password 7.2.4, macOS Mojave, Safari 12.0.2

    The behavior below happens when using the keyboard shortcut or clicking the open and fill button.

    This one works as expected: (pastes username and password correctly and then copies OTP into clipboard after that)

    This one just pastes OTP into the username (even when clicking the open and fill option on top of that this site doesn't currently require or support OTP which makes it even more annoying...):

    1P Entry:
    OTP (for the first website that requires it)

    website entries(consolidated these further):

  • littlebobbytableslittlebobbytables

    Team Member
    edited January 2019

    Hello @snowy,

    So for some reason I can't load the first URL you supplied but as you say that one works I'm not too fussed that I can't reach the page. Thankfully the one you say doesn't work I could load and I can reproduce the bad behaviour.

    The only thing I've found that works I'm afraid is to separate from the 2FA from the Login item for the first stage and to maintain two. In fact the page teased all sorts of bad behaviour out of 1Password as I tested things so I think we need to use that page to refine a number of 1Password's behaviour.

    I apologise the only workaround I've found lacks any elegance but I hope it can help whilst we work on this.

    ref: xplatform/filling-issues#335
    ref: xplatform/filling-issues#336

  • i will do that for the meantime. i did have them separated, but since they used same password. i had joined them into single entry and discovered the bad behavior. better its only effecting one person. who understands things don't always work the way they are suppose to and hopefully you can fix that other "bad behavior".

    thanks for looking into this. great customer support! i am glad i switched to 1P.

    also if does get fixed in a new version of 1P. how would it be listed in the release notes so i know to try it again?

  • Hello @snowy,

    Just to ensure I didn't cause any misunderstanding, if all the URLs you supplied use the same account credentials meaning they're all tied to together by a single backend server than I would recommend one Login item for all of them, assuming you find that works. It would just be the 2FA field you would want to move to another Login item, one that doesn't record either a username or password along with it. That way when you fill the first stage it has no 2FA code to try and place and it does slightly better.

    I believe that any changelog entry should contain something along the lines of {!335} or {!336} or maybe even list both within a single set of curly braces. If it's been a while a nudge in this thread will attract our attention and we can let you know what the state of play is.

This discussion has been closed.