Ticket #26 (closed defect: fixed)

Opened 2 years ago

Last modified 2 years ago

Login Cookie seems not to be set

Reported by: TobiasBg Owned by: westi
Priority: critical Milestone:
Component: general Version:
Keywords: has-patch tested Cc: TobiasBg

Description

I setup a local gp test installation.

Then I try to login with the provided credentials admin/a.
But I get redirected to the same screen again, and I'm still not logged in. (The login link is still there and I can not perform any actions.)
(The credentials seem to be correct, because if I use other ones, like admin/b, I (correctly) get a wrong password error message.)

I brought this up shortly in the #glotpress IRC channel yesterday, and westi had the same issue. He suspected, it might be the login cookie not being set correctly.

Used system: latest trunk, with FF 3.5.5 on Windows

Attachments

fix-cookie-domain.diff Download (1.5 KB) - added by westi 2 years ago.
Only set a cookie domain if really wanted
fix-cookie-domain-dont-delete-cookies.diff Download (1.9 KB) - added by westi 2 years ago.
Improved fix

Change History

The code seems fine, but I also had problems with local domains and Firefox. Could you try using a domain with more than one part (for example I used baba.net)? This worked for me.

For some reason Firefox didn't set the cookie and I haven't been able to track why.

  • Priority changed from major to critical

I tested around again with latest trunk and looked at the HTTP traffic with Firebug.
(My setup is a: Apache/2.2.11 (Win32) PHP/5.3.0, GP installed at  http://localhost/glotpress/, with Firefox 3.5.7.)

I start at  http://localhost/glotpress/ and immediately get redirected to  http://localhost/glotpress/projects.
There, I click on "Log in".
In the form I enter "admin" and "a" and submit. According to the response header in Firebug, two cookies are set:

Set-Cookie
glotpress_auth=admin%7C1263237760%7C91d3333d6b147c864f66a6a477669337; path=/glotpress/; domain=localhost; httponly
glotpress_logged_in=admin%7C1263237760%7C41e72a7ac0e404defcbf3551bf19606b; path=/glotpress/; domain=localhost; httponly

Additionally I get redirected to  http://localhost/glotpress/projects.
But during that GET request, no cookies are transmitted to the server.
Therefore, I obviously am not logged in and everthing starts over again.

As westi confirmed it 4 weeks ago in the #glotpress IRC channel, I don't believe it is a problem with my setup.
And (mentioning this just to make sure): I do not have any problems with cookies/login on any other site, whether remote servers nor my localhost.

As this severly keeps me (and most probably others) from testing GlotPress, I'm increasing the priority. Sorry, if that's wrong.

  • Owner changed from somebody to westi
  • Status changed from new to accepted

I've tracked down the cause of this.

Basically, when GlotPress sets the cookies it is setting the cookie domain.

On a localhost install this gets set to localhost which is an invalid value for a cookie domain ( Cookie Spec) as it is not specific enough so the cookie is 'ignored' by the browser as the domain is seen as invalid.

In WordPress? we don't set a cookie domain by default (so cookies are limited to the host serving the pages) but do allow for a COOKIE_DOMAIN define to be put in wp-config.php which will then be used.

Patch incoming

westi2 years ago

Only set a cookie domain if really wanted

  • Cc TobiasBg added

Thanks for the patch, westi!

I quickly applied it and tested it. Good news: I now come a step further and am logged in on  http://localhost/glotpress/projects
Bad news: It is only for this page view. After clicking any link on the page (or simply pressing <enter> again in the address bar for the URL " http://localhost/glotpress/projects", I'm logged out again.

The Set_Cookie commands from the POST request now don't contain a cookie domain anymore, as expected.
Unfortunately the GET request for /projects (which is a result of the redirect after the login) will delete the cookies again, so that they don't exist for subsequent page views:

Set-Cookie
glotpress_auth=deleted; expires=Sat, 10-Jan-2009 11:39:13 GMT; path=/glotpress/
glotpress_logged_in=deleted; expires=Sat, 10-Jan-2009 11:39:13 GMT; path=/glotpress

I will also test this on a real domain now, I had somehow overlooked nbachiyski's comment and question.

I now tested on a real domain like  http://www.example.com/glotpress/

Without your patch:
Everything works fine: login, browsing, logout.

With your patch:
Same behavior as in my last comment (with localhost): Login works for one page view and them I'm logged out again.

Something interesting happens when I do this:
Login with an unpatched gp-settings.php (which works fine).
Then, while logged in in the browser, patch the file via FTP.
I'm still logged in and can browse around, BUT logout does not work anymore (I'll remain logged in).
And the weird thing with this:
The response header contains

Set-Cookie
glotpress_auth=deleted; expires=Sat, 10-Jan-2009 11:57:33 GMT; path=/glotpress/
glotpress_logged_in=deleted; expires=Sat, 10-Jan-2009 11:57:33 GMT; path=/glotpress/

but the GET requests all contain

Cookie
glotpress_auth=admin%7C1263297145%7C0b0ccef28e524c3dca3ac4234b6a7f8d;
glotpress_logged_in=admin%7C1263297145%7Cbbee8b3638b61a2d18ef3db233f69b32

So the cookie doesn't seem to get removed anymore.

westi2 years ago

Improved fix

Turns out there was a bug in gp_populate_notices() which appears to read notices out of cookies.

It was deleting all cookies whether or not there were notice ones.

Improved patch above

  • Keywords has-patch tested added

Thanks, westi!

That fixes it on both localhost and www.example.com!
No issues with cookies, or login/logout anymore :-)

(Added some keywords, but don't know if they are used on this Trac?!)

  • Status changed from accepted to closed
  • Resolution set to fixed

(In [384]) Do not delete all cookies on populating notices and by default don't give a domain name. Props westi. Fixes #26

Note: See TracTickets for help on using tickets.