Bugzilla – Full Text Bug Listing
| Summary: | Need to confirm login credentials three times before I get to "Continue" page | ||
|---|---|---|---|
| Product: | Community | Reporter: | David M. Karr <davidmichaelkarr> |
| Component: | Forums and Newsgroups | Assignee: | Eclipse Webmaster <webmaster> |
| Status: | RESOLVED WORKSFORME | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | karl.matthias |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
David M. Karr
I think there's another detail that might be useful. I'm seeing similar behavior in Bugzilla. While entering this report, I first logged into Bugzilla to get to the initial bug entry page. In the process of entering the report, it asked me to log into Bugzilla two more times before I completed the submission. The newsgroups login and the Bugzilla login are on different servers and use different code bases. If you encounter the same problem on both, I'd submit that the problem is at your end -- either with your browser config, caching setup or any network/proxy servers you may have. I don't get it. How could anything on my end possibly cause those symptoms? (In reply to comment #3) > I don't get it. How could anything on my end possibly cause those symptoms? > Well, your browser does all the work of filling in data, submitting it to the server, etc. It's in 100% control of what is sent. Do you have Firefox? Install Firebug and take a look at the network transmissions. You might find what's wrong. I would think there could be a connection to the new load balancer we just put in over the weekend, but since you say this used to happen on the old site, I am with Denis that I think it's on your end. Have you experienced the same problem in multiple browsers? Do you access our site through a firewall or proxy at home or at work? Those are all things that can affect this. If it matters, I changed my Firefox config so that the Eclipse web site always uses IETab, and now I never have this problem. I gave up trying to get this to work in plain Firefox. I can't reproduce this. Please reopen if you can supply a reproducible use case. It's obvious that there is a race condition present here. It's impossible to present a reproducible test case for a race condition. This continues to happen for me. Some days I just give up, some days it goes through immediately. Yesterday it morphed into a situation where after clicking "Continue" it went to the login page again. I logged in again, and it went to the "Continue" page, and then it went to the login page again, ad infinitum. Then I tried again an hour later and "Continue" went right through to the posting page. > It's obvious that there is a race condition present here.
It may be obvious to you, but I can't see it. I log in just about every day, using all kinds of browsers and from various networks, and never once does it fail.
If you have access to a network packet sniffer, such as Wireshark, you could attach a .pcap of this race condition. That way I could see exactly what your computer sees.
Sorry, I feel your frustration, but at this point I can't do much more than be sympathetic.
I sent Denis a pcap file in separate email demonstrating a similar symptom. > I sent Denis a pcap file in separate email demonstrating a similar symptom. Thanks for the pcap. After staring at it for about 1.3 seconds, it became blatantly obvious that not once does your computer actually talk to our servers. Never. you <-> proxy server@x.x.x.54 <-> eclipse.org So your proxy server is doing some weird stuff which, incidentally, I cannot see from your pcap. I get the distinct feeling that your proxy is confused by the fact that the login cookie, which is returned by an https server called dev.eclipse.org, is set for the entire .eclipse.org domain, and for both http and https connections. But it is a valid cookie, and it is valid spec. Your proxy doesn't seem to like it. Unfortunately, I can't see the dialog between your proxy server and our servers, so this is only my best educated guess as to what is happening. You can try taking this up with the entity running your proxy service (which appears to be your provider). Big providers such as yours have had proxy/cookie/auth glitches in the past, so this particular issue is not without precedent: http://arstechnica.com/web/news/2010/01/facebook-att-play-fast-and-loose-with-user-authentication.ars For what it is worth, I took the first URL in your pcap (the forum response link) and loaded it up in my browser. I was sent to the login screen, I logged in, then I clicked the "Continue" button, then I was sitting at the Post Form in the forum. I can't do much more than this. Best of luck. Interesting. So you think it's possible that the proxy sometimes (not all the time) will get the cookie from "dev.eclipse.org" that is set for the "eclipse.org" domain and decide it doesn't match and not send it to the client? Unfortunately, my provider is my employer, so I have even less influence than if I was a customer. :) Thanks for looking. Yes... Either that, or the proxy is 'rewriting' the cookie to specify it is for dev.eclipse.org only. The forums, being on www.eclipse.org, would then return you to the login page. I guess your evil corporate environment won't let you access NNTP? Even through port 80? Can you tell me what cookie is the login cookie? Is it ECLIPSESESSION? I was recently experimenting with the "Cookie Monster" Firefox plugin, and I noticed some curious behavior that the plugin author cannot repeat. It will show the list of all the cookies in the domain, but when I try to inspect the values of cookies, some of the values show, but some of them do not. I'm seeing this behavior in multiple domains. For instance, before I go to the forums login page, I viewed the cookies for eclipse.org, and I didn't see anything that looked like a login cookie. Then I went to the login page and entered my credentials and clicked OK. When I got to the Continue page, I checked the cookies again, and I saw the new ECLIPSESESSION cookie in the cookie list, but I can't see the values for that cookie. I also found a new "TAKEMEBACK" cookie, which I also can't see the value of. Going through the entire cookie list, I also found a "__utmc" cookie in multiple subdomains that I cannot see the value of. I can see the values for all other cookies in the list, for the eclipse.org domain, at least. I discovered that the problem with the Cookie Monster plugin was a bug in the plugin. It was apparently just a coincidence that ECLIPSESESSION was one of the ones it couldn't display the value for. After I got an update from the author, I was able to see that cookie value now. |