Bizarre Bug: 1Password crashes remote web server

ChrisKnight

Yes, this is indeed a weird one, and I'll grant that it is going to be difficult for the 1Password team to troubleshoot.



For several weeks I have been unable to log into the StrataScale admin console at Raging Wire. The URL is [url]https://secure.stratascale.com/[/url]



Whether I use auto-fill, or copy-and-past my credentials, the remote server blows chunks as I log in:



HTTP Status 500 -



type Exception report



message



description The server encountered an internal error () that prevented it from fulfilling this request.



exception



com.iplanet.jato.NavigationException: Exception encountered during forward

Root cause = [java.lang.IllegalArgumentException: Invalid child name [LoginURL]]



note The full stack traces of the exception and its root causes are available in the Sun GlassFish Enterprise Server v2.1 logs.

Sun GlassFish Enterprise Server v2.1



I had been assuming the server was having an issue with trying to serve up dynamic content based on the browser string, particularly OS X in the string, because I was having the same issue on Safari and Firefox. Until today, when I tried logging in from the guest account on my machine and had no problem. Then i uninstalled the 1Password browser extensions, and I also had no problem.



For whatever reason, having the 1Password browser extensions installed causes the secure.stratascale.com webserver to blow chunks when I try to log in.



I was able to log in at one point, using auto-fill. I apologize for not being able to pinpoint when this broke for me.

Nik

Sorry for the trouble, and thank you for the report. This is indeed a very strange case. What happens if you leave the 1Password extension enabled and use it to fill the login form, but disable autosubmit for that site?



1Password's autosubmit feature can be disabled globally, on a per-site basis, or on the fly:



Globally:

- Run 1Password and click 1Password > Preferences > Logins

- Disable the autosubmit option



Per-site basis:

- Run 1Password and find the site in question

- Click the Edit button

- Change its Submit setting to Never and save your changes



On the fly:

- Hold down the option key while selecting a login from the 1Password menu. You'll see the word "Fill" appear next to its name, indicating that it will fill the web form but not submit it.



In this case, I would use the "per-site basis" method to disable autosubmit just for this web site.

ChrisKnight

[quote name='justG']Sorry for the trouble, and thank you for the report. This is indeed a very strange case. What happens if you leave the 1Password extension enabled and use it to fill the login form, but disable autosubmit for that site?[/QUOTE]



I don't use auto-submit. At all.



Also, as I reported in my initial bug report, the remote site generates a 500 error whether I let 1Password fill the fields or if I copy and paste my credentials from the 1Password application. Simply having 1Password loaded as an extension causes the issue.



Yesterday, after having found that uninstalling the 1Password extensions allowed me to log in, I re-installed the 1Password extension and tried logging in again. The problem returned, demonstrating that in some way it is related to 1Password.



If I have time today, I will packet sniff a login with 1Password installed, and one without it installed, and see if the HTTP request is different in any way.



-Chris

Nik

Thanks, Chris. Any additional details you discover would be helpful.

ChrisKnight

[quote name='justG']Thanks, Chris. Any additional details you discover would be helpful.[/QUOTE]



Oops... I won't be able to packet sniff it. SSL...

ChrisKnight

[quote name='justG']Thanks, Chris. Any additional details you discover would be helpful.[/QUOTE]



OK, I've been able to watch the POST headers via the FireFox plugin "Live HTTP Headers" and it appears that 1Password is affecting the way that the form code on the page is being interpreted by the browser and the way the form data is submitted to the server. This is happening just by virtue of having 1Password loaded, as auto-submit is not enabled for the page and I have even copied-and-pasted the login info rather than having 1Password fill the fields for me.





When 1Password is NOT loaded, and you go to [url]https://secure.stratascale.com/[/url] (let it redirect you to the real login page), and you submit the form, a couple of things happen:



1) The POST target the browser submits to is /distauth/UI/Login

2) The username and password are processed by a bit of JavaScript and are submitted as IDToken1 and IDToken2, and IDToken0 has no value but is included in the POST data.

3) I can log in.







When 1Password IS loaded, and you go to [url]https://secure.stratascale.com/[/url] (let it redirect you to the real login page), and you submit the form, a couple of things happen:



1) The POST target the browser submits to is /distauth/UI/blank

2) The username is processed by a bit of JavaScript and is submitted as IDToken1 but the password entry IDToken2 is missing, as well as IDToken0 and the rest of the POST data.

3) I get a 500 error from the server.





No wonder I can't log in with 1Password installed.



If you would like a sanitized copy of my HTTP header logs, I can provide that. Sorry, but I can't provide you with a username or password to access the system.

ChrisKnight

One more bit of info...



In an effort to make sure this is purely a 1Password bug, I disabled ALL other Firefox extensions and then re-tested.



With 1Password being the only loaded extension, I continue to experience the login failure at [url]https://secure.stratascale.com/control/[/url] and the form post continues to go to the incorrect destination: [url]https://secure.stratascale.com/distauth/UI/blank[/url]



-Chris

MartyS

Thanks, Chris. I'm sure the developers will be able to make sense out of it all.

ChrisKnight

In case the developers are reading... As of Version 3.2.5 (build 30665) this bug is still present.



It is a sad thing that I have to leave 1Password unloaded in Safari so that I have one browser I can use for work.



-Chris

MartyS

[quote name='ChrisKnight']In case the developers are reading... As of Version 3.2.5 (build 30665) this bug is still present.



It is a sad thing that I have to leave 1Password unloaded in Safari so that I have one browser I can use for work.



-Chris[/QUOTE]



I guess I was confused, and maybe still am: I thought you were having this problem from Firefox, not Safari?



I looked at the page source and the destination for the form(s) [see below] *is* action="blank". It's the page's JavaScript that is making any other decisions and forcing it to be something else when it wants to do so.



I cannot recall another simple login interface that forces page refreshes either: that's just wasted bandwidth. If you're charged for traffic by your ISP or network provider you need to close this tab when you're not needing it.



1Password is filling the fields with my saved test data just fine. Since you're manually clicking the Login button, there's something that's [not] happening when 1Password fills the fields without actually entering into them. In fact that appears to be the issue as this web page actually uses three separate forms: one each for Username, Password and Login. Only the Login form actually dispatches to the desired server page. That seems like an unnecessary amount of HTML and JavaScript for what is usually a very simple facility to get two values from the user and send the information to the web server.



What may work for you would be to have 1Password fill the Username and Password (at least they didn't use the same field name for both dummy forms), then tab or click into the Username field and tab into the Password field, then click Login. Your visiting each field may be enough to trigger their JavaScript into then completing the Login form properly.



I will also say that anytime a web server aborts with a 500 error that the server's application needs to be fixed. No amount of sent data or "missing" data should cause the login application to abort in that fashion.

ChrisKnight

[quote name='MartyS']I guess I was confused, and maybe still am: I thought you were having this problem from Firefox, not Safari?[/QUOTE]



The bug happens with BOTH Safari and Firefox. Since Firefox is my primary browser I decided to unload 1Password from Safari so I can access the web admin console for one of my client's hosting providers. Can't do my workf for them if I can't admin their servers.



[quote name='MartyS']

I looked at the page source and the destination for the form(s) [see below] *is* action="blank". It's the page's JavaScript that is making any other decisions and forcing it to be something else when it wants to do so.[/QUOTE]



Not particularly unusual in a world addicted to AJAX.



[quote name='MartyS']

I cannot recall another simple login interface that forces page refreshes either: that's just wasted bandwidth. If you're charged for traffic by your ISP or network provider you need to close this tab when you're not needing it.



1Password is filling the fields with my saved test data just fine. Since you're manually clicking the Login button, there's something that's [not] happening when 1Password fills the fields without actually entering into them. In fact that appears to be the issue as this web page actually uses three separate forms: one each for Username, Password and Login. Only the Login form actually dispatches to the desired server page. That seems like an unnecessary amount of HTML and JavaScript for what is usually a very simple facility to get two values from the user and send the information to the web server.



What may work for you would be to have 1Password fill the Username and Password (at least they didn't use the same field name for both dummy forms), then tab or click into the Username field and tab into the Password field, then click Login. Your visiting each field may be enough to trigger their JavaScript into then completing the Login form properly.[/QUOTE]



OK, so you are chalking this up to "Their problem, not ours".



[quote name='MartyS']

I will also say that anytime a web server aborts with a 500 error that the server's application needs to be fixed. No amount of sent data or "missing" data should cause the login application to abort in that fashion.[/QUOTE]



It's not my website, but I can send you the email address for the provider if you wish to share your thoughts.

MartyS

[quote name='ChrisKnight']The bug happens with BOTH Safari and Firefox. Since Firefox is my primary browser I decided to unload 1Password from Safari so I can access the web admin console for one of my client's hosting providers. Can't do my workf for them if I can't admin their servers.[/QUOTE]



Thanks for the clarification. It helps to know what browsers can reproduce a certain condition.



[QUOTE]Not particularly unusual in a world addicted to AJAX.[/QUOTE]



Exactly. 1Password has to try and work itself into and around the JavaScript that's present on the page and sometimes that's more of a challenge than others. Filling the fields is usually easy, but there's no standardized way to "trigger" field entry events.



[QUOTE]OK, so you are chalking this up to "Their problem, not ours".[/QUOTE]



Not at all. I was wanting you to know what makes this form more complex than most. Was my possible workaround suggestion helpful to you for this site?



[QUOTE]It's not my website, but I can send you the email address for the provider if you wish to share your thoughts.[/QUOTE]



We're not the customer of this service. We have found that our making "contacts" about something that impacts our customers is a quick way to be ignored. When the customers speak to them however in sufficient numbers or urgency, then we have had some companies make a return contact to us about how they can help make changes that in turn help their customers. We are here to help them as well, if we can.

ChrisKnight

Actually, I'd like to report that something HAS changed, for the better.



When I initially reported this problem, I stated that it occurred whether I used 1Password to auto-fill, or if I copy-and-pasted the username and password into the form. I simply could not log into this website AT ALL if 1Password was loaded as an extension in my browser. What I found was that 1Password was interfering with the form submission just by being loaded, whether or not I used it to fill in the forms.



Apparently one of the recent updates resolved this issue, as I am now able to log in, via a browser that has 1Password enabled, if I copy and paste my credentials in. Further testing has shown that I can auto-fill now as well, as long as I click the submit button.



It's not perfect, but it is a MAJOR improvement over how it had been when I initially reported the bug.

Nik

Thanks for the update, Chris.