Closed Bug 135932 Opened 23 years ago Closed 23 years ago

Logging into United's website complains about 'Cookies Disabled'

Categories

(Core :: Networking: Cache, defect, P1)

Product:
Core
Component:
Networking: Cache
Type:
defect

Tracking

()

Status:
VERIFIED WORKSFORME
Milestone:
mozilla1.0

People

(Reporter: ahp+mozilla, Assigned: morse)

References

(
URL
)

Details

(Keywords: regression, topembed+, Whiteboard: [adt2])

When I try to log into my Mileage Plus account using Mozilla 0.9.9 their website complains that I have cookies disabled. However, if I hit the back button and try to login again it works just fine.
Do you have cookies disabled or not in Mozilla?
Yes, cookies are enabled and they work just fine on other sites (including United when I hit the back button and try to login again).
Changed platform to all/all. added nsbeta1, topembed, regression Problem does not occur in Gecko/20011128 but does occur in recent Mozilla builds. To replicate: 1. Go to http://www.united.com 2. Shift-reload browser to clear cache 3. Enter mileage plus and password [Engineer/QA I can give you mine] Result: You should get mileage plus summary 4. Go back to home page and *do not* clear cache 5. Enter mileage plus & pw again Result: You should get cookie's disabled error I replicated this several times.
Assignee: morse → gordon
Severity: normal → major
Status: UNCONFIRMED → NEW
Component: Cookies → Networking: Cache
Ever confirmed: true
Keywords: nsbeta1, regression, topembed
OS: MacOS X → All
Priority: -- → P1
Hardware: Macintosh → All
Do you have your cookie-acceptance to be originating-server-only? If so, make it accept-all and see if the problem goes away. If it does, then it is probably a dup of bug 134203.
No, I have cookies set to 'Accept All'
My browser is set to "enable all cookies" also. FYI This problem was first reported by chofmann on 3/22: I tried to use a build from today to login and get mileage plus info and it choked. e.g. some messages about cookies not being enabled when they were, then it took the login but some redirection problems ended up sending me to an endless loop page at https://www.itn.net/cgi/xreg/itn/air/mp?message_version=1&auth_message=5O-LJLlDgSkfZOz0Rk7qgVWnuE5cNQ2-TJDiIk7-N8fHvkrKPPmpYk&stamp=NEWCOOKY*itn%2Ford%3DNEWREC%2Citn%2Fair%2Fmp&return_to=ff_acct_hist but never showed me my account info.
topembed+ as per edt triage since this is probably a popular site.
Keywords: topembed → topembed+
Problem still occurs in 2002042306 build.
United is a top 100 site in Media Metrix.
Marking this bug as nsbeta1+/[adt2] as this occurs on a top site, and is a visible regression from 094, and previous commercial release.
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt2]
I just repro'd this on win2k, Netscape commercial 1.0 build from 04/29/02
Assignee: gordon → morse
->1.0
Target Milestone: --- → mozilla1.0
I'm unable to reproduce. I enter my account number and password and do NOT get any message about cookies being disabled. I do however get a message about "Secure access authorization" and they do not let me see my account. But it does let me look at my profile proving that I indeed logged on successfully. I'll call UA (they are open from 4AM to 9AM pacific time) and see if they can clear up the "Secure access authorization" thing. I'm using a trunk build that I just pulled and built today. Susie, if you want to e-mail me your id and password, I'll try it with your account and see if I get anything different.
Status: NEW → ASSIGNED
I just spoke with UA's customer support and they cleaned up my account so that I no longer get the "secure access authorization" message. So I tried this again and I am able to log on successfully. I do not get a message about cookies being disabled. I tried clearing my cache and doing shift-reload. Still do not see the problem. I tried changing my pref to accept-cookies-from-originating-site and I'm still able to log on successfully. It is only after I change my pref so that cookies are completely disabled that I get the message described in this bug report. I am using the most-recent mozilla sources. I have not tried this on a commercial build. But that should not be necessary according to the comments above. Are you still able to reproduce this using the latest build?
Using the 20020512 nightly build I do not see the problem any more.
Closing out as wfm based on my comment 14 and reporter's comment 15. If anyone else is seeing this on a recent build, then reopen the report.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
*** Bug 145680 has been marked as a duplicate of this bug. ***
re-opening. I just repro'd this on win2k, using Netscape 7.0 PR1. I was only able to repro it when attempting login from the main page (http://www.ual.com). Using a mileage plus link elsewhere on the site, things were fine.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
This one is most evasive. I have a lot of information on this now, but no indication yet of where the problem is. 1. I cannot try this on the latest trunk builds (mozilla or commercial) because they crash as soon as you try to submit a form (I'll be filing a bug report on that shortly). 2. The mozilla 1.0 release does not exhibit this problem but netscape 7.0 pr1 does. 3. I can reproduce the problem with this very simply test case: <html> <body> <form action="https://www.ua2go.com/ci/DoLogin.jsp?stamp=NEWCOOKY*itn/ord=NEWREC,itn/a ir/mp&amp;return_to=ff_acct_hist" method="POST"> Mileage Plus# <input type="text" name="userId" value=""> <br> Password <input type="password" name="password" value=""> <br> <input type="submit" value="Login"> </form> </body> </html> 4. I tried capturing traffic for the mozilla case (which works) and the netscape case (which fails). Unfortunately the site is https so the traffic is encrypted and not readable. 5. The traffic for the netscape case (which fails) starts off with a cleartext get which I cannot explain. After that, the remainder of the traffic is encrypted. The traffic should start off with a post -- I can't see where a get could come from. GET /data?if_nt_MileagePlus%20Login=True& Page_Title=United%20Home%20Page&tax0_SiteID=1& if_nt_Browser_Combination=mozilla/4.75%20%5Ben%5D%20%28win95%3B%20u%29& if_nt_URL=http%3A//www.ual.com/ HTTP/1.1 Host: unitedcollect.insightfirst.com User-Agent: Mozilla/4.75 [en] (Win95; U) Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9, text/plain;q=0.8,video/x-mng,image/png, image/jpeg,image/gif;q=0.2,text/css,*/*;q=0.1 Accept-Language: en-us, en;q=0.50 Accept-Encoding: gzip, deflate, compress;q=0.9 Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66 Keep-Alive: 300 Connection: keep-alive HTTP/1.1 200 OK Server: Netscape-Enterprise/4.1 Date: Sun, 09 Jun 2002 23:40:41 GMT Set-Cookie: united042002=9910763; expires=Sat, 31-Aug-2002 23:39:59 GMT; path=/; domain=.insightfirst.com Content-type: image/gif Content-length: 125 Pragma: no-cache Cache-Control:no-cache P3P: CP="NOI DEVa TAIa OUR BUS UNI STA" policyref="http://www.insightfirst.com/w3c/p3p.xml"
By setting the NSPR_LOG environment variables I was able to see the otherwise encrypted traffic. Here is what is being transmitted in the mozilla (successful) case: request: POST to www.ua2go.com/ci/DoLogin.jsp?stamp=...&return=... HTP/1.1 response: set-cookie: WebLogicSession=... request: GET to www.ua2go.com/ci/DoLogin.jsp?nc=1 HTTP/1.1 cookie: testcookie=1; WebLogicSession=... response: redirect to https://www.itn.net/cgi/xreg/itn/air/mp?... Here's what is being transmitted in the netscape (unsuccessful) case: request: POST to www.ua2go.com/ci/DoLogin.jsp?stamp=...&return=... HTP/1.1 response: set-cookie: WebLogicSession=... request: GET to www.ua2go.com/ci/DoLogin.jsp?nc=1 HTTP/1.1 cookie: WebLogicSession=... response: redirect to https://www.ua2go.com/ci/NoCookies.jsp Note that there is no testcookie in the failure case. Also I don't see where the testcookie is getting set in the success case (unless it is being done within the content)
Oh, I failed to mention that the reason for the second request is that the first response was a redirect to https://www.ua2go.com/ci/DoLogin.jsp?nc=1
I just opened bug 150541 for the crash in the trunk builds when submitting the form to ual (see my comment 19 item 1).
Depends on: 150541
Some more information: 1. I no longer crash on the trunk builds. So I was able to test this out on the trunk. The problem does not occur -- I am able to successfully log on to the UAL site. Both with trunk mozilla and trunk netscape. 2. Traffic posted in comment was not quite right. The set-cookie on the first response contains testcookie as well as WebLogicSession. It was hidden there so I didn't see it. But in the next request, that cookie is not being sent back in the Netscape (unsuccessful) case but it is being sent back in the mozilla (successful) case. The actual set-cookie header is as follows: Set-Cookie: WebLogicSession=...; path=/ testcookie=1
OK, there is a slash in the query string portion of the URL. The POST in the original request is as follows: POST /ci/DoLogin.jsp? stamp=NEWCOOKY*itn/ord=NEWREC,itn/air/mp&return_to=ff_acct_hist HTTP/1.1 That's an error on the part of the website! However we fixed that on April 15 and it was checked into the trunk. But due to lack of adt approval, it didn't get checked into the branch until May 30. That's why this bug is appearing in PR1, but not in the current builds (branch or trunk). Therefore closing out once again as WFM.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → WORKSFORME
I forgot to mention -- the fix that was checked in to the trunk on April 15 and the branch on May 30 was bug 62348
*** Bug 147780 has been marked as a duplicate of this bug. ***
verified wfm
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.