608362 - Login to marinet.lib.ca.us fails, login form clears on submit

Status: RESOLVED WORKSFORME

(Core Graveyard :: Networking: Domain Lists, defect)

Description

[Dan McMahon]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 ( .NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 ( .NET CLR 3.5.30729)

Beginning with 3.6.11 on Windows and Macs, logins to our site (a public library catalog) fail.  The login form clears, though the server shows it's delivering the logon page, as does the URL in the browser.  It works in IE and Safari, and I've been told FF 3.6.11 works in Linux as well.  It's not: SSL (turned it off), javascript (turned it off), cache or cookies (cleared, deleted), html issues that we can find (nothing changed, and we've had folks scour the code).  I've got dozens of reports of this, and not one confirmed report that 3.6.11 or 3.6.12 (or 3.5.14/15) work to login to our site.

Reproducible: Always

Steps to Reproduce:
1.  Go to http://marinet.lib.ca.us and click on Log into My MARINet
2.  Type in valid name, barcode and PIN.  
3.Invalid info works correctly, giving error message.
Actual Results:  
Submitting valid info clears the form, though the server records that it is returning the first user account page, the URL of which does appear in the address bar of Firefox.

Expected Results:  
One should be looking at the first user account page with all its options to view checkouts, fines or holds, and to logout.

Comment 1

[Tim (fmdeveloper)]

Does the issue still occur if you start Firefox in Safe Mode? http://support.mozilla.com/en-US/kb/Safe+Mode

How about with a new, empty profile? http://support.mozilla.com/en-US/kb/Basic+Troubleshooting#Make_a_new_profile

Comment 2

[Dan McMahon]

Safe mode has the same issue, in 3.6.11 and .12.

The new profile also has the same issue, as does a new installation on a fresh PC.  3.6.10 works fine as a new install.

I've also discovered another anomaly with 3.6.11/.12, likely related, in that the book cart functionality doesn't work.  (Find a single book title, click "Add to Book Bag," click "View My Book Bag" and "Export My Save Titles."  This doesn't require a login, but Firefox shows "You have not saved any records for export."  This does work in IE and Safari.

Comment 3

[Tim (fmdeveloper)]

Are you seeing any errors in the error console when logging in or using the book bag function?

Comment 4

[Dan McMahon]

The website gives "server does not support RFC 5746" errror.  With signon.debug set to true, when I try to log on I get this sequence:
1. Login Manager: observer notified for form submission.
2. Login Manager: Checking if logins to https://marinet.lib.ca.us can be saved.
3. PwMgr mozStorage: Getting login saving is enabled for https://marinet.lib.ca.us
4. Login Manager: (form submission ignored -- saving is disabled for: https://marinet.lib.ca.us)
5. marinet.lib.ca.us : server does not support RFC 5746, see CVE-2009-3555
6. Login Manager: onStateChange accepted: req = https://marinet.lib.ca.us/patroninfo~S3/1231405/top, flags = 0x30004
7. Login Manager: domEventListener: got event DOMContentLoaded
8. Login Manager: Counting logins matching host: https://marinet.lib.ca.us, formSubmitURL: , httpRealm: null
9. PwMgr mozStorage: _countLogins: counted logins: 0

No. 6 looks like the URL I should have if I logged in succesfully.

When I click to add a book to the book bag, I get these:
1.  Login Manager: onStateChange accepted: req = http://marinet.lib.ca.us/search~S3?/tempire/tempire/1,160,278,B/frameset&FF=tempire&5,,10?save=b1620521, flags = 0x30004
2. Login Manager: domEventListener: got event DOMContentLoaded
3. Login Manager: Counting logins matching host: http://marinet.lib.ca.us, formSubmitURL: , httpRealm: null
4. PwMgr mozStorage: _countLogins: counted logins: 0

None of it looks unusual, compared to a 3.6.10 session that does work.  I did find a Firefox Help Forum report identical to our issues, at http://support.mozilla.com/en-US/questions/763100.

Comment 5

[Tim (fmdeveloper)]

Do you have access to server logs that will show the requests coming in on the server? I am seeing the issue in Firefox and working in other browsers. Looking at the URL's that the JS calls are using they are identical in all browsers. I am curious if the server is receiving the correct info.

Tyler -> Any ideas?

Comment 6

[Tyler Downer [He/Him]]

Kicking over to core.
https://bugzilla.mozilla.org/buglist.cgi?quicksearch=ALL%20status1.9.2%3A.11-fixed is the 3.6.11 changelist, if this happened in that update, has to be fallout from one of these bugs.

Comment 7

[Dan McMahon]

Here's a sequence from the server logs as I tried to log in from my own PC.  Patroninfo is the login screen, and there are 2 redirects, which might be where it's losing Firefox, but the final line shows the page as being sent frojm the server with a status 200. 

[21/Oct/2010:08:03:19 -0700] "GET /patroninfo HTTP/1.1" 301 117 "http://marinet.lib.ca.us/" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.11) Gecko/20101012 Firefox/3.6.11 (.NET CLR 3.5.30729)" 3087
[21/Oct/2010:08:03:20 -0700] "GET /patroninfo HTTP/1.1" 200 1997 "http://marinet.lib.ca.us/" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.11) Gecko/20101012 Firefox/3.6.11 (.NET CLR 3.5.30729)" 17394
[21/Oct/2010:08:03:23 -0700] "POST /patroninfo HTTP/1.1" 302 26 "https://marinet.lib.ca.us/patroninfo" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.11) Gecko/20101012 Firefox/3.6.11 (.NET CLR 3.5.30729)" 46178
[21/Oct/2010:08:03:23 -0700] "GET /patroninfo~S3/1231405/top HTTP/1.1" 200 1997 "https://marinet.lib.ca.us/patroninfo" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.11) Gecko/20101012 Firefox/3.6.11 (.NET CLR 3.5.30729)" 17230
[21/Oct/2010:08:03:27 -0700] "POST /patroninfo~S3/1231405/top HTTP/1.1" 302 26 "https://marinet.lib.ca.us/patroninfo~S3/1231405/top" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.11) Gecko/20101012 Firefox/3.6.11 (.NET CLR 3.5.30729)" 38892
[21/Oct/2010:08:03:27 -0700] "GET /patroninfo~S3/1231405/top HTTP/1.1" 200 1997 "https://marinet.lib.ca.us/patroninfo~S3/1231405/top" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.11) Gecko/20101012 Firefox/3.6.11 (.NET CLR 3.5.30729)" 17361

Comment 8

[Tim (fmdeveloper)]

Works:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.11pre) Gecko/20100928 Firefox/3.6.11pre ( .NET CLR 3.5.30729; .NET4.0E) ID:20100928042306

Fails:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.11pre) Gecko/20100929 Firefox/3.6.11pre ( .NET CLR 3.5.30729; .NET4.0E) ID:20100929042157


Pushlog -> http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=[phone]&enddate=2010-09-29

Comment 9

[Dan McMahon]

Our server vendor made an adjustment (adding an option to not "force cookies" whatever that means) and our problems have disappeared.  They said that they had a second customer run into this issue, and so they figured out how to adapt the Apache server to the new security configuration of 3.6.11/3.5.14 and newer, which is probably the best outcome.

Comment 10

[Tim (fmdeveloper)]

I think this might have the same cause as Bug 614565 - changing component to match that bug. Not sure if the fix in Bug 614565 will fix this so not marking as a duplicate yet. Gerv?

Comment 11

[Gervase Markham [:gerv]]

Tim: in comment 8, you link to a mozilla-central pushlog list. Surely you meant to link to a mozilla-1.9.2 list?

https://hg.mozilla.org/releases/mozilla-1.9.2/pushloghtml?startdate=[phone]&enddate=2010-09-29

That does include the PSL change in question. 

All of the site in question seems to be on marinet.lib.ca.us, and setting cookies for that should be fine. (Which is probably how they've got it to work now.) If the site was setting cookies for all of lib.ca.us before, that was probably the wrong thing...

Dan: is the signon in your application designed to work across all California's public libraries, or just for your site?

Also, are you happy with the fix your server vendor has produced, or are you pushing for more action from us?

Gerv

Comment 12

[Dan McMahon]

The signon is supposed to work only for our site, marinet.lib.ca.us.

I'm happy with the vendor fix, though we've found some other odd behavior as a result of whatever they did.  Some of our proxy-server database authentications aren't working in Firefox, giving an error page.  ("The page isn't redirecting properly" error.  Firefox has detected that the server is redirecting the request for this address in a way that will never complete.  This problem can sometimes be caused by disabling or refusing to accept cookies.")

Comment 13

[Gervase Markham [:gerv]]

Resolving based on comment 12.

Gerv

Comment 14

[Dan McMahon]

The upgrade to v.4.0 (and 4.01) has caused this problem to reappear.  Recent versions of Chrome also do not work.  Login box clears upon clicking "submit."

Our application vendor came up with a workaround (not forcing use of cookies) but that causes people to be logged into other people's accounts at site that NAT to a single IP, so we had to abandon that option for privacy reasons.

Comment 15

[Gervase Markham [:gerv]]

Dan: setting cookies for the site marinet.lib.ca.us should work. 

If I click "Submit" on https://marinet.lib.ca.us/patroninfo, I see the following (from Firebug):

Set-Cookie	SESSION_SCOPE=3; path=/ III_EXPT_FILE=aa21953; path=/; domain=.lib.ca.us; path=/ III_SESSION_ID=129f63c181c47d427996ebd810ce9e0f; domain=.lib.ca.us; path=/

This is your problem. Your application is attempting to set cookies for all of the lib.ca.us domain. Get your vendor to stop doing that, and set them only for the domain marinet.lib.ca.us, and your logins will work again.

Feel free to point them at this bug.

Gerv

Comment 16

[Dan McMahon]

We're finally fixed.  Thanks very much for pointing me in the right direction, I was able to use this information with our ILS vendor.  (They only took 4 weeks to verify it and suggest a solution.)

Our vendor's web software for some reason couldn't generate a cookie that would work with a domain name as short as ours (marinet.lib.ca.us), and all their other customers in .lib.ca.us had one more qualifier than we did so "no one else has this problem."  Our solution was to alias our catalog to catalog.marinet.lib.ca.us, get a new security certificate including that, and we are now using session cookies and enjoying it in all browsers.

Again, many thanks for your expertise.