Strange behavior of 1Password and TYPO3 6.2.11
![[Deleted User]](https://wa.vanillicon.com/v2/a6b889688698aa4706fad92b20a94f92.svg)
Logins saved in 1Password stopped working on TYPO3 6.2.11 websites. Strangely, copying user/password data from the 1Password browser extension to the clipboard and then pasting it into the login form "manually" still works. Even more strangely, editing and saving the 1Password entry (without actually changing anything, let alone user and password) seems to resolve the issue.
Encountered this with TYPO3 6.2.11 only. 1Password works beautifully with all other versions of that CMS as well as with all other websites I frequent.
Tested on several machines running OS X 10.10.2 (with AND without the recent security update 2015-003) / Safari 8.0.4 and Firefox 36.0.4 / 1Password 5.1 and browser extension 4.3.0.
Comments
-
That is odd @cooperate,
If you still have some Login items that are behaving this way I'd be very curious about something.
You would need to enable a particular option in 1Password's preferences. It's in the Advanced tab and it's called Show Item > Copy JSON menu item.
With that enabled, confirm a particular unedited item doesn't submit properly and then select the item in question in 1Password. Open the Item drop down menu and hold down the alt
⌥key. You should see an option titled Copy Extension JSON. Select that and paste the contents of the clipboard to a text editing program like TextWrangler (to name just one). Edit the item and save just as you've done before. Repeat the above and paste the new Extension JSON below the previous paste.Now we have a before and after. To be honest I would have expected them to be the same but if they're different we at least have an idea of why what you're doing has an effect. The next part is to understand what changed and why.
Depending on what changed you may or may not feel comfortable pasting that section here if there is indeed a difference at all. So please do keep us updated and if need be we can move it to email if discussing the details isn't something we want to do in a public forum.
0 -
@littlebobbytables Thanks for answering so quickly.
Mixed results:
A) There is one tiny change in the JSON string: Within "secureContents", the order of the "htmlAction" and "htmlMethod" entries is now reversed. Their contents stayed identical, however. So this can't really be of any consequence, I think. I'll check with my machine at home to make absolutely sure...B) I'm at a different Mac today. Here, the "edit & save" trick described above does not work.
Again, I'll check with my machine at home if I can reproduce it again (or whether dreamed it up).C) I use the same 1Password entry for two websites running different versions (4.5.40 LTS and 6.2.11 LTS respectively). Until recently both sites cooperated beautifully. Now, only the site running on 4.5.40 does. The site that has been updated from 6.2.9 to 6.2.11 stopped doing so. To me, this sounds like it's nothing 1Password or I myself have done. Rather, this seems to be a problem with TYPO3. Maybe some new input sanitation running amok? Only that their change log doesn't mention anything.
0 -
Hi @cooperate,
We'll certainly be interested in anything your investigation throws up. What might be curious is a comparison. If you create a new Login item using our Saving a Login Manually guide and it behaves, how does it compare against the non-functional one.
Now normally what breaks a Login item is a site changing their login page. Often the changes aren't visible and it's only if you compare the web form details between the old and new that you get an idea of what have altered under the hood. Sometimes even viewing just the web form details isn't enough to really tell. Certainly the change you detailed shouldn't be sufficient so it's very curious.
Please do keep us informed!
0 -
Sorry. Logins DO work - kind of. I stopped 1Password from firing the "send" button, and that helped.
Apparently, TYPO3 requires a certain amount of time to pass between filling out the login form and sending it. Is there a way for me to change the speed with which 1Password fills out & sends the login credentials?0 -
PS: The TYPO3 log file notes "Login-attempt from ... for username '...' with an empty password!". Obviously, 1Password is too fast.
0 -
Hi @cooperate,
So setting the submit option for that Login item to Never submit works but if it's set to Submit when enabled 1Password will fill in the two fields correctly yet the response you get back is no password was supplied (it was empty), is that correct?
I don't believe there is a way to add a delay between filling and submitting, either per item or globally. I don't know if we could add another option in the submit preference, something like Pause between fill and submit but I wonder how often such a feature would be needed. It might not be as convenient as having it submit but could Never submit for this particular Login be an acceptable solution?
0 -
This is really confusing and erratic.
Or maybe I'm lossing my mind?1) I changed the 1Password entry to "never submit" as mentioned above. The entry, as you may remeber, is for 2 sites. On the 1st site running TYPO3 4.5.40, the 1Password entry works as expected: Firing it form either the browser extension or 1Password mini does fill in the form fields but does not submit the form. On the 2nd site running TYPO3 6.2.11, however, the same 1Password entry behaves differently! It STILL submits the form. I triple-checked that "never submit" is selected! WTF? Here's what Copy Extension JSON shows:
{"uuid":"913A03FC3F514A6A807685BDF6A7F60B","nakedDomains":["domain1.net","domain2.net"],"overview":{"autosubmit":"never","title":"Domain1.net (user_name)","url":"http:\/\/www.domain1.net\/typo3\/index.php"},"secureContents":{"htmlForm":{"htmlAction":"http:\/\/www.domain1.netindex.php","htmlMethod":"post","htmlName":"loginform"},"fields":[{"value":"user_name","id":"t3-username","name":"username","type":"T","designation":"username"},{"value":"ASuperPassword!","id":"t3-password","name":"p_field","type":"P","designation":"password"},{"value":"Anmelden","id":"t3-login-submit","name":"commandLI","type":"I"}]}}2) As a last resort I deleted the entry from 1Password completely and created a new one. This new entry behaves as expected (i.e. never submit) on both sites. Hurrah! But why? Here's what Copy Extension JSON shows:
{"uuid":"9778F268416B4F739C3EEF5FD538E3CE","nakedDomains":["domain1.net","domain2.net"],"overview":{"title":"domain1.net (user_name)","url":"http:\/\/www.domain1.net\/typo3\/index.php","autosubmit":"never"},"secureContents":{"fields":[{"value":"user_name","name":"username","type":"T","designation":"username"},{"value":"ASuperPassword!","name":"password","type":"P","designation":"password"}]}}Btw: domain and username are edited, obviously. But I do have an underscore in my username and some orthographic characters (i.e. pound signs, colons) in my password, if you're curious.
3) And now for the really confusing part. I finally turned "Submit when enabled" back on for the new entry. And as if I had dreamed the whole thing, submitting now does work for both sites! Here's what Copy Extension JSON shows (it's almost identical to the code above):
{"uuid":"9778F268416B4F739C3EEF5FD538E3CE","nakedDomains":["domain1.net","domain2.net"],"overview":{"title":"domain1.net (user_name)","url":"http:\/\/www.domain1.net\/typo3\/index.php","autosubmit":"default"},"secureContents":{"fields":[{"value":"user_name","name":"username","type":"T","designation":"username"},{"value":"ASuperPassword!","name":"password","type":"P","designation":"password"}]}}Except, in 1Password, the URLs for domain1 and domain2 are now shown twice, so that I now have 4 websites for that entry.
Can you explain to me what happened here?0 -
@cooperate: Sorry for the confusion! We have to duplicate some data now because 1Password 5 for Mac added support for 'sections', which some versions do not know about. They just use the traditional 'fields', so for compatibility we keep both. I hope this helps! :)
0
