Community
Participate
Working Groups
Whenever I try to log in on https://dev.eclipse.org/site_login/ I return to that site without an error message or any other comment. It appears that I'm not logged in after that. So, I tried to comment on: http://dev.eclipse.org/blogs/kevinmcguire/2008/12/04/experiments-with-bugzilla-email-filtering/ So I was redirected to: http://dev.eclipse.org/blogs/kevinmcguire/wp-login.php?redirect_to=http://dev.eclipse.org/blogs/kevinmcguire/2008/12/04/experiments-with-bugzilla-email-filtering/ After entering my credentials and click on login I was redirected to: https://dev.eclipse.org/site_login/
I've seen this happen, but I'm unable to reproduce it reliably enough to figure out what's broken. I'll keep looking.
So maybe it's account specific? I still can't login. (Tried it right now if you want to scan some logs).
After a second try I'm logged in now.
It's not account specific, as I've seen this happen to me. Karl originally thought it was a problem with the 'remember me', but I don't see it. I'll keep poking.
When I go to the blogs.eclipse.org site and login (not checking the box) I get logged in successfully but I just end up at the page that says: " Welcome Back, Karl You have successfully logged in. Although you're logged in, you're not eligible for the Friend of Eclipse Benefits. Consider becoming a Friend of Eclipse today! If you have recently made a donation of $35 USD or more there are sometimes unexpected delays with Paypal clearing your transaction. Please allow 2-3 business days for the payment to clear our systems. If you still need assistance with your Friends of Eclipse Login please contact friends at eclipse.org Return to previous page. "
When I manually return to the blogs page and reload, I still have to click login again. Behaves the same way now with the box checked to remember me, too.
I now see what the problem is. The 'Return to previous page' link (that you didn't click) is the wp_login.php page, which will end up seeing your login cookie and etc. etc. I'll fix this. This is a separate issue from what Gunnar is seeing, though, but an issue nonetheless.
This happened to me today as well. I 100% sure I was using the right credentials, it wasnt until i tried to show Matt (of course) that it worked. Wish i could give you more details about how it happened.
I had a look at the HTTP traffic using Fiddler but I wasn't able to reproduce. Maybe it is a specific node only. Anyway, the server response indicates a source for potential trouble. The ECLIPSESESSION cookie is set multiple times. The first two times it's value is "deleted" but the last time it's the actual session id. I don't now the HTTP spec in detail but I could imagine that this could confuse some browsers. However, I could also be wrong because it worked and I was logged on. ------ HTTP/1.1 302 Found Date: Fri, 05 Dec 2008 18:49:06 GMT Server: Apache Set-Cookie: ECLIPSESESSION=deleted; expires=Thu, 06-Dec-2007 18:49:05 GMT; path=/; domain=.eclipse.org Set-Cookie: ECLIPSESESSION=deleted; expires=Thu, 06-Dec-2007 18:49:05 GMT; path=/; domain=.eclipse.org Set-Cookie: ECLIPSESESSION=12345678901234567890123456789012; expires=Sat, 05-Dec-2009 18:49:06 GMT; path=/; domain=.eclipse.org Set-Cookie: TAKEMEBACK=https%3A%2F%2Fdev.eclipse.org%2Fsite_login%2F; path=/; domain=.eclipse.org Location: http://www.eclipse.org/friends/welcomeback.php X-NodeID: node2 Content-Length: 7032 Keep-Alive: timeout=3, max=100 Connection: Keep-Alive Content-Type: text/html; charset=ISO-8859-1 ------ Another suggestion I have is to make the /site_login/ page be smart and don't show the login form if I have a valid session but a logout button. But that's another issue.
Ginnar, I noticed the same thing when I got the issue -- the session cookie gets set multiple times (with deleted and with a valid value). I'll go with that. Thanks
Created attachment 119657 [details] HTTP headers of a broken logon workflow Ok, so I was able to record a broken session. Headers attached. The basic workflow is as follows. GET /friends/welcomeback.php (without ECLIPSESESSION cookie) -> 302 Found -> Set-Cookie: ECLIPSESESSION=deleted;... -> Set-Cookie: ECLIPSESESSION=deleted;... -> Location: https://dev.eclipse.org/site_login/ GET /site_login/ -> 200 OK -> Set-Cookie: ECLIPSESESSION=deleted;... POST /site_login/index.php -> 302 Found -> Set-Cookie: ECLIPSESESSION=deleted;... -> Set-Cookie: ECLIPSESESSION=deleted;... -> Set-Cookie: ECLIPSESESSION=(real session id);... -> Set-Cookie: TAKEMEBACK=(site login url) -> Location: http://www.eclipse.org/friends/welcomeback.php GET /friends/welcomeback.php -> 302 Found -> Set-Cookie: ECLIPSESESSION=deleted;... -> Set-Cookie: ECLIPSESESSION=deleted;... -> Location: https://dev.eclipse.org/site_login/ Maybe it's also the TAKEMEBACK cookie?
- I've made sure that all erased cookies follow the spec (ie, time() - 3600) - I delete the TAKEMEBACK cookie after login and logout - I've added a META REFRESH after a successful login, which will take you back to the old page after 5 seconds - I've added a big "Continue" button on the welcome back page. I think this solves Karl's use case. I haven't encountered the comment 0 use case since doing all this. I'll keep testing before closing FIXED.
*** Bug 258329 has been marked as a duplicate of this bug. ***
*** Bug 259394 has been marked as a duplicate of this bug. ***
Created attachment 121073 [details] Patch for session code I think I was being too aggressive in trying to invalidate older sessions by deleting the cookie, even if it wasn't there. With this patch I don't get the multiple ECLIPSESESSION-=deleted on my localhost.
I also fixed a slight glitch with the $App->useSession("required") code (which was called by welcomeback.php): was: $ssn = new Session(); if ( (!$ssn->validate()) && $required == "required") { The default constructor for Session calls validate already, so the second call was redundant. I changed it to this instead: $ssn = new Session(); # constructor calls validate if ($ssn->getGID() == "" && $required == "required") { After a battery of testing, I can't reproduce the symptom in comment 0 (after a login, back to the login screen without an error), so I'll close this as FIXED. If you still experience this blank screen login, please reopen.
Meh, while troubleshooting a different problem, I found the definitive cause of this one. See bug 259508.
Indeed, if I stopped the slave database server and logged in, the welcomeback page's SELECT went to the stale slave database, didn't see the login session and returned me to the login page without error. With bug 259508 fixed, I updated the session SELECT to user the master instead, and I can log in successfully even when the slave is lagged.
Reopening ... I'm still getting reports of this returning a blank login form (no error) after submitting the login.
*** Bug 262093 has been marked as a duplicate of this bug. ***
Because of this bug I was unable to post to Eclipse Subversive newsgroups to report about a problem without their update site and now I'm unable to ask people there if it is safe enough to update to the last version... I'd suggest to raise the priority of this bug either to Critical or even to Blocker, as it totally blocks the usage of Newsgroups web interface! (I cannot and don't want to install a newsgroup client software on my machine) The symptoms are similar to e.g. Bug 262093: - I go to the Subversive newsgroups http://www.eclipse.org/newsportal/thread.php?group=eclipse.technology.subversive - I click "New message" - I am redirected to https://dev.eclipse.org/site_login/ - I enter my credentials - I am redirected to the same login page without any errors - if I enter the correct email, but incorrect password, I see the corresponding error message So, I am stuck on the login page, and can't enter the community to post messages to the newsgroup.
I just tried this and it worked for me. Could you try this in a different browser, as well as tell us what browser/os you were connecting on?
(In reply to comment #22) > I just tried this and it worked for me. > > Could you try this in a different browser, as well as tell us what browser/os > you were connecting on? > Just tried, with the same results. I use Firefox 3.0.10, Win XP; also tried Opera 9.64, IE 7, Chrome 1.0 - same results again.
Someone else had reported this through webmaster@ and they gave me their login and password. From a variety of computers/browsers, I wasn't able to reproduce this. I sure wish I could, though.
So, is there anything I can help you with? HTTP headers, cookies etc?
Most of the site login stuff is stored in a cookie on your machine, can you delete you eclipse.org cookies and try once more?
(In reply to comment #26) > Most of the site login stuff is stored in a cookie on your machine, can you > delete you eclipse.org cookies and try once more? > Tried, no luck... Please note that I've never used all the other browsers except for Firefox to browse either bugzilla or newsgroups at Eclipse.org.
*** Bug 283537 has been marked as a duplicate of this bug. ***
Jean: what browser (and version) are you using? And can you tell me if you're using a proxy server?
After a bit of examination, it occurs to me that after a successful login, I'm sending a 302 redirect but still sending the entire login form payload to the browser (a blank form with no error). Something like: if(login is successful) { do_stuff(); 302_redirect_to_www.eclipse.org/friends/welcomeback.php; } show_login_form(); A 302 with a 7KB html payload may perhaps confuse a browser, so I've added an exit after the 302 redirect. I've also crafted a shell script which will login and follow the redirection to www.eclipse.org/friends/welcomeback.php every minute and check the state: #!/bin/bash while [ 1 == 1 ] ; do rm cookies.txt curl -s -c cookies.txt -D headers.txt \ https://dev.eclipse.org/site_login/index.php \ -F 'username=my@email.com' -F 'password=mypass' \ -F 'remember=1' -F 'submit=Login' > login.html curl -s -b cookies.txt -D wwwheaders.txt http://www.eclipse.org/friends/welcomeback.php \ > welcomeback.html A=$(grep -c "HTTP/1.1 302 Found" wwwheaders.txt) B=$(date) if [ $A -gt 0 ]; then echo "$B Login Failed -- www redirected to Site Login"; else echo "$B Login Successful -- www showed the page" fi sleep 60 done;
Hmmm... From RFC2616: "If the 302 status code is received in response to a request other than GET or HEAD [the Login form is a POST], the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued." I did not know that. Apparently I should be using a 303 See Other response to redirect a POST, but it seems to introduce some risk: " Note: RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected of the client. 10.3.4 303 See Other The response to the request can be found under a different URI and SHOULD be retrieved using a GET method on that resource. This method exists primarily to allow the output of a POST-activated script to redirect the user agent to a selected resource. The new URI is not a substitute reference for the originally requested resource. [snip] Note: Many pre-HTTP/1.1 user agents do not understand the 303 status. When interoperability with such clients is a concern, the 302 status code may be used instead, since most user agents react to a 302 response as described here for 303."
Created attachment 141658 [details] Patch for RFC compliance So here is a patch that would make this RFC-compliant. It will send a 302 for HTTP/1.0 clients, and 303 for HTTP/1.1 clients. Tested: $ telnet wikitest 80 Connected to wikitest. Escape character is '^]'. GET /test.php HTTP/1.0 HTTP/1.1 302 Found Location: /blah [snip] Connection closed by foreign host. $ telnet wikitest 80 Connected to wikitest. Escape character is '^]'. GET /test.php HTTP/1.1 HOST: wikitest HTTP/1.1 303 See Other Location: /blah Content-Length: 8 Connection closed by foreign host. Further reading: http://en.wikipedia.org/wiki/Post/Redirect/Get
Patch committed, closing as FIXED.
*** Bug 282941 has been marked as a duplicate of this bug. ***
When it says "FIXED", does that mean the fix is already installed? I'm still seeing this symptom. I had earlier thought it was fixed, but now I see that it is not.
Sorry Denis, Out for hollydays, I did not see your question until now. Anyway, I just checked, it works now, thanks
