Cookie Handling Issues with Konqueror?

[Zugschlus]

That Re-Init is performed, when your s9y installation is missing the $_SESSION['SERVER_GENERATED_SID'] value. (top of serendipity_config.inc.php)

This code?

Code: Select all

    if (!isset($_SESSION['SERVER_GENERATED_SID'])) {
        session_regenerate_id(true);
        @session_start();
        header('X-Session-Reinit: true');
        $_SESSION['SERVER_GENERATED_SID'] = true;
    }

This in turn can only happen, if your PHP's session storage does not work, because that sessionvalue is created immediately after the session in fact IS set.

I'm not sure about that Debian PHP 5.2.0 version; I think there was a problem with PHP's session_regenerate_id() function in some PHP5 function which got fixed at some point. Maybe debian didn't backport this fix?

Any chance to use a more recent PHP5 version?

I installed Debian unstable in a virtual machine and see the following headers:

Code: Select all

http://192.168.8.132/apache2-default/s9y/1.2/

GET /apache2-default/s9y/1.2/ HTTP/1.1
Host: 192.168.8.132
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.12) Gecko/20080129
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plai
Accept-Language: de,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: serendipity[userDefLang]=en; serendipity[old_session]=278bb99637bcce3592

HTTP/1.x 200 OK
Date: Mon, 17 Mar 2008 08:17:58 GMT
Server: Apache/2.2.8 (Debian) PHP/5.2.5-3 with Suhosin-Patch
X-Powered-By: PHP/5.2.5-3
Set-Cookie: PHPSESSID=4d204c4e3493880ce5377b9771fcb14d; path=/
Set-Cookie: PHPSESSID=d145b4af71c4734e2ea8595e84609a0f; path=/
Expires: 0
Cache-Control: no-cache, pre-check=0, post-check=0
Pragma: no-cache
X-Session-Reinit: true
X-Blog: Serendipity
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8

It doesn't get any newer on Debian.

I can upload the virtual machine (executeable with VMware Player) to the web so that you can download and see for yourself, or isntall the virtual machine on a publicly visible host so that you can log in from remote and try it yourself. Or, I can do whatever you ask to find out what's going wrong here.

Greetings
Marc

[garvinhicking]

Hi!

Could Suhosin be interfering? Please disable it temporarily.

Also, why is your serendipity[old_session] cookie only 18 bytes long? It should be 32 bytes, like your PHP Session!

I'm a bit out of time, also talked to isotopp a bit. There might be some problems with the session_regenerate_id() functions and maybe even the PHP-version.

But for starters, I'd consider if suhosin could be a culprit, it might hook into the session generation code?

Regards,
Garvin

[Zugschlus]

Could Suhosin be interfering? Please disable it temporarily.

As far as I know this is not possible without re-building. Do you require me to do this?

Also, why is your serendipity[old_session] cookie only 18 bytes long? It should be 32 bytes, like your PHP Session!

Cut&Paste error, cut from an 80-character terminal with line wrapping disabled. I haven't yet found out how to directly cut from Live HTTP Headers.

There might be some problems with the session_regenerate_id() functions and maybe even the PHP-version.

Workaroundable in s9y?

Greetings
Marc

[garvinhicking]

Hi!

I just checked with my installation. It seems normal to me that multipe Set-Cookies are issued.

Here's what I wrote to isotopp:

[13:19] supergarv: Also je länger ich darüber nachdenke: Ich glaube es ist von PHP gewollt, dass da Zwei Set-Cookies kommen. Der "letzte" Wert überschreibt ja den ersten im Browser. Daher ist das eigentlich egal, nur der letzte enthält die gültige Session-ID.
[13:19] supergarv: Und die letzte Session-ID sollte dann die sein, die der browser danach wieder an den server per Cookie sendet.
[13:20] supergarv: Und sobald man einmal in s9y eingeloggt ist, soll diese session id in serendipity[old_session] auch gespeichert sein.
[13:20] supergarv: Mich dünkt, dass das eher zugschlus' problem ist: Dass seine [old_session] nur 18 zeichen lang ist und daher ne ungültige session gespeichert hat, die dann wieder zum reinit führt?

All in all: Please give me your VMWare, I'll check it. But beware my rhythm-stick beating, if I shall find out it's a user error

Cut&Paste error, cut from an 80-character terminal with line wrapping disabled. I haven't yet found out how to directly cut from Live HTTP Headers.

So the answer is that your session line really is 32 bytes long?

Regards,
Garvin

[Zugschlus]

I just checked with my installation. It seems normal to me that multipe Set-Cookies are issued.

Then we're back to issue 1: Why do browsers throw users back to the login screen?

All in all: Please give me your VMWare, I'll check it. But beware my rhythm-stick beating, if I shall find out it's a user error

It's a 366 MB .tar.bz2, I'll upload this afternoon when the "bigger" upstream is available.

Cut&Paste error, cut from an 80-character terminal with line wrapping disabled. I haven't yet found out how to directly cut from Live HTTP Headers.

So the answer is that your session line really is 32 bytes long?

Yes:

Code: Select all

http://192.168.8.132/apache2-default/s9y/1.2/

GET /apache2-default/s9y/1.2/ HTTP/1.1
Host: 192.168.8.132
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.12) Gecko/20080129 Iceweasel/2.0.0.12 (Debian-2.0.0.12-2)
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: de,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: serendipity[userDefLang]=en; serendipity[old_session]=d145b4af71c4734e2ea8595e84609a0f; serendipity[author_token]=e07fb0f52cc6fbf3ffdfaa9e9c730f9db1099e0a

HTTP/1.x 200 OK
Date: Mon, 17 Mar 2008 09:07:13 GMT
Server: Apache/2.2.8 (Debian) PHP/5.2.5-3 with Suhosin-Patch
X-Powered-By: PHP/5.2.5-3
Set-Cookie: PHPSESSID=bc7fefa9c8db743bc3d70bf0b2d7f0bd; path=/
Set-Cookie: PHPSESSID=0e7f92e1d3482e753cbedf269469dd23; path=/
Expires: 0
Cache-Control: no-cache, pre-check=0, post-check=0
Pragma: no-cache
X-Session-Reinit: true
X-Blog: Serendipity
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8

[garvinhicking]

Hi!

It's a 366 MB .tar.bz2, I'll upload this afternoon when the "bigger" upstream is available.

The earlier, the better. I will release s9y 1.3 today, so if there's an issue, I could implement a fix for yours.

Regards,
Garvin

[Zugschlus]

All in all: Please give me your VMWare, I'll check it. But beware my rhythm-stick beating, if I shall find out it's a user error

It's a 366 MB .tar.bz2, I'll upload this afternoon when the "bigger" upstream is available.

https://ivanova.notwork.de/~mh/stuff/Te ... ne.tar.bz2

root password 1234
The vmrtual machine will obtain an IP address via DHCP
serendipity URL http://$IP/apache2-default/s9y/1.2
Account tester, password 1234

Please tell me when you have downloaded the image, I'd like to remove it asap.

Greetings
Marc

[garvinhicking]

Hi!

Downloaded. Will try later.

[garvinhicking]

Hi!

I've mounted it here on my windows PC (it did not work on my linux machine).

I do not have any trouble using IE6, IE7, Firefox2, Firefox3, Opera7, Opera8, Opera9 and Safari accessing your site in the VMWare. I could log in (WITHOUT checking 'remember me') and did not see any other login prompt again.

I could not try Konqueror because I could not find it for windows, and the IP was not accessible unter my Linux workstation.

Sadly your VMWare image does not seem to contain KDE or X, so I could not "locally" test it?

But judging from this, this sounds to me more like a client problem of your system...?!

Regards,
Garvin

[Zugschlus]

Sadly your VMWare image does not seem to contain KDE or X, so I could not "locally" test it?

The VM was only made to show the "double PHPSESSID cookie" issue. I didn't try the heisenbug that throws me back to the login screen at abitrary times in the admin frontend.

But since both Isotopp and Rince experience the same issue, I doubt that this is a client issue on my machine.

Greetings
Marc

[Zugschlus]

What exactly does

Code: Select all

Set-Cookie: serendipity[author_information]=deleted; expires=Sun, 18-Mar-2007 23:06:48 GMT; path=/; domain=127.0.0.1
Set-Cookie: serendipity[author_information_iv]=deleted; expires=Sun, 18-Mar-2007 23:06:48 GMT; path=/; domain=127.0.0.1

mean in the response to a POST /serendipity_admin.php request with correct authentication data?

Shouldn't it be setting the author data of the account just logging in?

Greetings
Marc

[Zugschlus]

What exactly does

Code: Select all

Set-Cookie: serendipity[author_information]=deleted; expires=Sun, 18-Mar-2007 23:06:48 GMT; path=/; domain=127.0.0.1
Set-Cookie: serendipity[author_information_iv]=deleted; expires=Sun, 18-Mar-2007 23:06:48 GMT; path=/; domain=127.0.0.1

mean in the response to a POST /serendipity_admin.php request with correct authentication data?

Shouldn't it be setting the author data of the account just logging in?

Ok, that appears also when a login is successful and persistent.

When comparing HTTP Live Headers of a browser that doesn't persistently log in to the headers of a freshly configured browser running under a new account, I do not see significant differences. The PHPSESSID cookie is set twice in the first http call, and the browser delivers the second one set back to the server in each subsequent call. The only difference is that the server's reply to a "GET /serendipity_admin.php?serendipity[adminModule]=entries&serendipity[adminAction]=new"
is a login screen in one case and a "new entry" screen in the other.

Greetings
Marc

[garvinhicking]

Hi!

This author_information cookie is an expiring auto-login cookie which is only valid for a certain timestamp, and updated after each successful step.

BTW: The double "Set-Cookie" phenomenon seems to be proper, at least all PHP versions emit that when session_regenerate_id() is called. Browsers operate cookies inthe order of their HTTP result, so double ones require to be overwritten. PHP seems to think it is no problem to pass multiple Set-Cookie commands. It might be nicer for PHP if it would only emit a single cookie (the valid one), but currently it should still work and should not be the root of your problem.

I'd really love to help, but to me this issue is not reproducable neither with my own install nor with your vmware image using the browsers I have at hand...

Regards,
Garvin

[Zugschlus]

I'd really love to help, but to me this issue is not reproducable neither with my own install nor with your vmware image using the browsers I have at hand...

Would it probably help to have some strategically placed debug log output calls in the appropriate parts of s9y source code? I mean, somewhere, s9y must decide that I am not logged in and throw me back to the login screen...

Or is this happening deeply inside the bowels of PHP?

Greetings
Marc

[garvinhicking]

Hi!

Would it probably help to have some strategically placed debug log output calls in the appropriate parts of s9y source code? I mean, somewhere, s9y must decide that I am not logged in and throw me back to the login screen...

It decides that based on the HTTP-Cookies only, and depending on the Session-Management.

The "X-Session-Reinit" thing is already helpful for that; other than this, it could actually only be related to Suhosin or PHP session management, outside of the s9y scope.

I have not heard any other reports of people with issues like that, so I really doubt it is related to Serendipity itself?

Regards,
Garvin