Trouble with ccTLD matching on 1100.com.au

WardenBrown

I saved a password for Dial Before You Dig, 1100.com.au (eleven hundred dot com dot au) from Firefox in March 2010 during the pre-release beta period. It was used successfully several times in 2010, but has not been used in 2011 or later.



I am now using 1P 1.0.9.273 with Chrome 16 (extension v[color=#000000][font=Arial, sans-serif][size=3]3.8.9.38999[/size][/font][/color]) or sometimes with Firefox 10.



The DBYD login works fine in Firefox 10, just like it did in 2010. But, it does not work in Chrome. In fact 1P (Chrome) doesn't even match it as a possible login for the site.



The existing login record (saved in 2010) has the following parameters:[list]

[*]Title: www.1100.com.au

[*]Location: [url="http://www.1100.com.au/default.aspx"]http://www.1100.com.au/default.aspx[/url]

[*]Submit: if auto-submit is ON

[*]Name: Username, Value: "my username", Type text, Designation: username

[*]Name: Password, Value: "my passord", Type password, Designation: password

[*]Name: agreed, Value: tick, Type checkbox, Designation: none

[*]Name: submit, Value:login, Type: image, Designation: none

[/list]

I deleted this record and tried saving a new record from Chrome. Filling and submitting the login form DID NOT result in a prompt to save a new record. So, I also tried filling the login form and then manually saving (+ button) with the plugin. This saved a new record. i then tried to login using the new record, (Ctrl+\) but 1p did not match the site with the new record ("No Logins saved for this site"). This new record does however work in Firefox. In Safari 5.1.1 (extension v[color=#000000][font=Arial, sans-serif][size=3]3.8.7.31126[/size][/font][/color]) behavior is the same as for Chrome. IE9 behavior is the same as for Firefox - except that an Error "1Password has encountered a problem" is displayed - "Internet Explorer is denying access to a <frame> because it is in another domain."



The new login record has the following parameters:[list]

[*]Title: www.1100.com.au

[*]Location: [url="http://www.1100.com.au/Portals/0/Skins/DBYD/login-request.php"]http://www.1100.com....gin-request.php[/url]

[*]Submit: if auto-submit is ON

[*]Name: Username, Value: "my username", Type text, Designation: username

[*]Name: Password, Value: "my passord", Type password, Designation: password

[*]Name: agreed, Value: tick, Type checkbox, Designation: none

[/list]

Looking at the site I notice that the login form is with an iFrame. If my memory is correct there was a problem with the site on early pre-release versions of 1P (0.9.x?). I would have reported that through the forum and Stefan fixed it. Can't check because the new forum doesn't go back that far. Anyway,I am thinking the the Chrome extension may need similar tweaking.

Stefan von Dutch

Domain matching for Chrome has been greatly improved in one of our latest BETA builds. You might want to remove our add-on from Chrome, and then re-install a BETA version of our Chrome add-on here: https://agilebits.com/extensions/win/index.html (please click on "allow beta extensions").

DBrown

Hi, Warden! Long time, no see. <img src='http://forum.agilebits.com/public/style_emoticons/<#EMO_DIR#>/smile.png' class='bbc_emoticon' alt=':)' />



Please let us know whether the Beta extension resolves the problem for you.

WardenBrown

I installed Chrome beta extension v3.9.0.39011 and this does NOT solve the problem.

khad

Unfortunately, I am not able to reproduce the problem using the 1Password extension 3.9.0.39011 in Chrome.



[img]https://img.skitch.com/20120203-ta1d73n57f8kxthmea9nf1peb8.png[/img]



I can't think of why it would matter, but now that you are using the beta extension with proper domain matching for ccTLDs such as [b]com.au, [/b]could you try creating a new Login item? I can't figure out why it would be working for me but not you.



[b]PLEASE NOTE:[/b] This [b]will not work[/b] in the current [b]stable version[/b] of the extension since ccTLD support was only added in the beta channel.



You need to be sure you are using and testing with the beta extension. Since you mentioned that you tested with 3.9.0.39011 in Chrome, I am a bit puzzled. Do you have any better luck in Safari with the beta extension there?



Make sure you restart your browser just to be safe. Please let me know how it goes.

WardenBrown

Thank for the insight Khad.



[quote name='khad' timestamp='1328241908' post='57954'] Unfortunately, I can't think of why it would matter, but now that you are using the beta extension with proper domain matching for ccTLDs such as [b]com.au, [/b]could you try creating a new Login item? I can't figure out why it would be working for me but not you. [/quote]



I deleted all login records for this site (the 2010 one and the one one I made before installing the beta extensions) and saved a new record from Chrome. IP now matches and the form gets filled. But 1P will NOT submit the form. Same behaviour occurs in Safari. However, However, if you fill the form from 1P and click on the Login button, the form submits and your are logged in.



I note the after clicking on Login a new tab is opened for the main site. On a hunch, I turned off popup blocking. This let 1P submit the form and a new tab was loaded. I guess 1P was actually submitting it and the browser was blocking the new tab. Turning off popup blocking is not viable in Safari (it is a global switch). Chrome lets you add and exception for the site (so that is OK).



I don't understand why this difference in behaviour:[list=1]

[*]when you auto-submit from 1P you get popup blocking.

[*]when you fill from 1P and click on the Login button you don't get blocked.

[/list]

Is this something that can be addressed in the extensions?

DBrown

Some sites just require an actual "click," Warden. You can make the behavior consistent by setting the Submit option for this Login item to "Never." (Of course, that's the opposite of what you'd [i]like[/i] to happen.)

WardenBrown

DBrown,



I understand that and have set auto-submit to never on some other sites (especially those that also require a capta). The current beta plugins for Chrome/Safari provide a workable solution and I could always use 1P in Firefox - it works flawlessly.



I guess my point was that the Chrome/Safari extensions are behaving differently to the Firefox plugin. All browser have pop-up blocking set. I am not convinced that the difference in behaviour experienced is due to browser architecture alone. Hence my question - "Is this something that can be addressed in the extensions?"

DBrown

Our extensions for Chrome and Safari are based on an entirely different technology than those for Internet Explorer and Firefox, so differences are to be expected.



They're also developed in a separate group and need to work with 1Password for Mac, as well as 1Password for Windows (also two very different programs), so it's not clear to me whether a solution can be "encoded" in the extensions.



Notifying us of the difference, as you've done, is the first step in the process of our finding the answer to that question. Thanks for your patience!