1Password isn't filling in properly on many sites in Safari

MikeT

This discussion was created from comments split from: Form fills out form but doesn't login.

Moocher

I've been having the same problem with many websites. If I use the safari extension it is somehow read incorrectly by the site I'm trying to log into or it is not read at all. The former is much worse because after trying a couple times using autofill or cutting and pasting, some sites deactivate my account figuring that I'm trying to hack in. I'm having the problem is with at least 1/2 dozen sites and it seems to be increasing. This is causing me a problem with accounts I need to access to pay bills and to banks. It's almost like it's incorrectly entering the user name and password or there's a translater between Safari and 1Password that is causing what I see on the screen to be different than what is actually being sent.

(1Password 5.1, Safari 8.0.3, and OSX 10.10.2 Notice a trend here? BTW, I've used 1Password for years on Macs, iPads, and iPhones. I'm not a novice at this.)

Moocher

MikeT

Hi @Moocher,

I've split your posts from other threads in order for us to keep track of your issues. Please do not duplicate your posts, it makes it difficult for us to provide support for you.

Can you tell me what 1Password extension version is installed in Safari? To find out, open Safari, go to the Safari Menu > Preferences > Extensions, select 1Password on the left sidebar and the version should then show up on the right.

We're overhauling our filling system in the next extension version that's in the beta testing right now, and if you're using the beta versions, you might be affected by some of the changes we're making.

Also, can you tell me how you're invoking 1Password to fill in, are you clicking on sites from 1Password to open in your browser or are you manually opening sites first in your browser before pressing the 1Password icon or 1Password shortcut to fill in?

Moocher

Thanks for your response. Even though I'm using 1Password software version 5.1, the extension is listed as version 4.2.5. The disparity seems strange to me and I can't explain it. If the extension is an older version, please let me know how to install the current one.

I have used all of the techniques for using the software; cut and paste into the website, clicking on the icon in the toolbar of Safari, and clicking on the URL from within the app itself to open the page through Safari.

Mooch

MikeT

Hi @Moocher,

That's fine, the extension and the main app will have their own version. 1Password 4 and 5 for Mac and 1Password 4 for Windows uses the same extensions.

cut and paste into the website, clicking on the icon in the toolbar of Safari, and clicking on the URL from within the app itself to open the page through Safari.

I'm a little confused, you're saying if you're copying and pasting into the site, it will still fail? In that case, it sounds like your credential is wrong since 1Password is not involved when you copy/paste into the site.

Is it possible in this specific case, the site has a password length restriction and 1Password has the one that's exceeding the restriction? To test this theory, try typing the password in and see if it works.

Moocher

It's not just one website, nor is it a website that I have been unable to log into in the past. I'm baffled. It's like the computer is translating the password into something else. The only idea I have is a possible conflict with other software or OSX features in the latest version of 1Password, but I wouldn't know where to start to track the problem down. I've done similar investigations in the past, but due to chronic problems, I have trouble concentrating long enough systematically turn off, move, and rule out every program and extension that always runs. This morning I successfully logged into a key site for me using auto fill in 1Password. I've been less occupied with the computer recently but I will keep track of future problems and try to give you more specific information.

What I hear you saying at this point is that you don't know of any similar problems and conflicts. Is that correct?

Drew_AG

Hi @Moocher,

I'm not aware of any problem in 1Password that would cause copy & paste to not work. If you copy & paste a password from 1Password into a text file or some other app, does the correct password get pasted there? Also, if your passwords are normally concealed in the 1Password app, go to the View menu and disable the option for Conceal Passwords. Are your passwords correct in your Login items?

Also, did you try this suggestion from MikeT:

Is it possible in this specific case, the site has a password length restriction and 1Password has the one that's exceeding the restriction? To test this theory, try typing the password in and see if it works.

Let us know if that works for you. Thanks!

Moocher

Checked the length and it's not an issue. I don't have 1Password set to conceal the passwords. The problem still exists, particularly with bank and brokerage sites.

rickfillion

Hi @Moocher,

Could you test pasting the password into something like a TextEdit document to ensure that what's getting pasted there is indeed the correct password?

Rick

almostthor

I believe I'm having this same problem too, both with the Chrome Extension (4.2.5.90) and Safari Extension (4.2.5). And like @Moocher, it only happens when autofilling in some of my saved passwords.

I typically do the following:

• manually go to the login page by typing in the url
• when the login page appears use CMD+OPT+\ to bring up the 1password
• filter the list (if needed) by typing in letters to find the exact password to fill
• press Return to fill

This is then when it fails.... however, if I then go back to the same password entry using the process above and copy the password and paste it into the password field it works (the username, of course, typically remains on the page after login failure, so I don't need to re-enter that).

Here's a video demonstrating in Chrome: http://screencast.com/t/fboKlKYB5

Hope this helps.

almostthor

One thing I failed to mention, I seem to have noticed this happing to entries where I've updated the password.

littlebobbytables

Hi @almostthor,

I think your second post there could prove insightful, let's see.

If you were to inspect a couple of the Login items where you know this is an issue, how does the web form details compare to the visible section of the Login item? My suspicion is you will find possibly the old password in the web form details.

Let me know if that's the case and we can cover as to why this might have happened. If the password is correct then we'll continue investigating.

almostthor

@littlebobbytables - indeed, you are correct. The "old" password is still set in the the 'password' field in the Web form details, while when the new password (which was auto-added by 1P after completing a password update webform) was added in the top password field, but placed in a webform field labeled p5. Looks like the 'Password' attribute is applied to multiple items, but the correct 'new' password does have the key icon next to it.

Image removed by AgileBits

The password update functionality used to work without issue, so I'd love to know why this might have happened.

Thank.s

littlebobbytables

Hi @almostthor,

I've removed the image you posted as I was concerned it displayed more information than you really wanted it to. I've kept a copy just for while I reply to your message and then I'll delete it too.

Websites, unsurprisingly, vary a lot in terms of complexity and I don't just mean from a user's perspective but even more so from the underlying code of the page.

Take amazon's login page, if you perform a manual or automated save using the extension the web form details records two fields titled email and password - nice and simple.

The one for the site you're dealing with has a bunch of what are most likely invisible fields, ones you aren't aware even exist. With sites like this we have to take our best guess at which field represents the username and which represents the password and we flag these using a small icon for a person and a key. In the image you posted the field p5 has been erroneously flagged as the password field. If you're thinking hang on, the fields titled password, p5 & p6 are all passwords - that's the field type and we pick that up from the webpage. So this login has at least 3 fields set using the password type and we have to guess which one is the real password field that you would type into. It's rare (thankfully) but I've seen some manual saves where the user enters the password and when we inspect the page the password is recorded in two places, like one has mirrored the other. I don't know why sites are constructed like this and I don't think you'll ever get a sensible answer.

Of course we're still left with the question, well what do I (you) do?

I would like you to edit the Login item in question and click on the show web form details button. I then want you to click on the drop down selector, the rightmost one for the line titled password and select the key icon. This will shift the key icon from the p5 line to the top line. You now want to copy your current password, either from the password field at the top of the page (the normally visible one) or from the p5 line and paste it over the old password in the password field in the web form details. After you click the Save button the Login should once again work and if you change your password in the future it should update properly.

So why did updating the password not work properly the first time? The little silhouette of the person (for your username) and the key icon link two fields in the web form details to the hardcoded username and password fields that are normally visible. When you change those hardcode fields it updates the two linked entries in the web form details and that's how updating a password is meant to work. 1Password updates the visible password field and the link updates the web form details. If the wrong field though has been linked it breaks down as instead of the password field in the web form details being updated, p5 was updated instead.

Hopefully that makes sense but if you have any questions do please ask.

Now, once you have a working Login item again I would strongly recommend you change that password now. There was a significant amount of the URL present and I just wouldn't want to see anything happen as a result of the troubleshooting. It will also give you a chance to see if the update works properly this time.

Let us know how you get along.

almostthor

@littlebobbytables - yes, making the changes as suggested has the auto-fill working again properly. Thank you.

So, it appears that 1P correctly choose the correct password when it was updated during the websites password change process because the key icon was next to the correct password (in the 'P5' line). Do we understand why it wasn't moved up to the password field so that it could actually be used to do auto-fills?

Thanks.

ps. PW has been changed, as recommended.

littlebobbytables

Hi @almostthor,

By your question I'm thinking you've got the ordering reversed in your head?

When 1Password updated the Login item it updated the visible, hardcoded password field at the top of the Login item. The key icon means that 1Password will update that web form details field to whatever is in the password field above. So as the key icon was opposite the p5 entry, p5 was updated at that time. If you were to manually alter the visible, hardcoded password field it would be reflected in the web form details section. The source of the issue is we took a guess at which of the many password fields on the page really represented where you, as the user, submit your password and we didn't get it right.

Does that help? sometimes getting quite right explanation can be tricky so do tell me if I need to rephrase some of it or if even worse, I'm misunderstanding what you're asking.

almostthor

Hey @littlebobbytables ,

OK. I think that makes sense... so, the pw reset form that I completed must have had a password form element with the id of p5 and what I completed to reset the password. Then 1P caught that event, prompted me to update my 1P database, and when I selected the correct entry from the drop down, it updated the password field and then also stored that value in the web form details section with under the node's id attribute p5.

But, when I go to use it, as there is no form field with an id of p5 on the actual login page that entry doesn't get use. Instead, because there is a form field with an id of password containing the 'old' password, it gets used instead.

Do I have that right?

littlebobbytables

Hi @almostthor,

You're almost right, well based on the assumptions I have to make having not inspected the specific login page.

When you created the Login item you did so using the extension and 1Password mini, all of the information in the web form details tells us that. All of those fields would have been present on the page you created the Login item from and many of them could still be there but are essentially invisible or maybe the page has changed over time. If you were to ask me why it has all of those p5 and p6 fields which you can't see? I can't give you a good answer, it might be they've got a single page that allows registration as well as logging in, maybe one side only being visible to the user if you click a button - there are so many 'interesting' ways to create a website it seems.

So prior to the fix your correct password could very well have been submitted to an invisible field titled p5 but as it wasn't being submitted to the 'correct one' it failed.

I believe our password updater works a little differently. My understanding is it's mostly based on the idea of your old password being present and two copies of a new password, all of the password type. When we see this we interpret it as a new password and update the Login item. If my understanding is correct we don't look at the field IDs, so it works on a sightly different level compared to filling.

Let me know what think :smile:

almostthor

Interesting. I did another reset of the password on that same 1P entry and using the same steps as before (when it incorrectly guessed), this time it worked. Now that I have a better understanding of what's going on, I'll do some investigation to try and figure out the state of the page that makes it difficult for 1P to guess correctly.

Thanks again @littlebobbytables for all the background and direction.

littlebobbytables

Glad we could be of help @almostthor :smile: