Serendipity Forums

Hi,

when I use konqueror as a browser, I have - since a few days - some issues with the administration suite. I log in, and get the admin main menu. I click on an entry of the menu, and am thrown back to the login screen.

This can - sometimes - be remedied by deleting the cookies that konqueror has stored. Other times, this does not help.

Since i haven't done anything to my s9y installation in the last few days, I am kind of stymied about this behavior. Any ideas what may be going wrong here?

Greetings
Marc

Hi!

Does the same happen with Firefox or Opera?

Regards,
Garvin

garvinhicking wrote: Does the same happen with Firefox or Opera?

No, Firefox is just fine.

Greetings
Marc

Hi!

Hm, then I sadly can only point to Konqueror. I don't really have knowledge with that browser.

Regards,
Garvin

garvinhicking wrote:Hm, then I sadly can only point to Konqueror. I don't really have knowledge with that browser.

Can you give me some enlightenment about what I could/should test before I try filing a bug against the browser? The KDE people will most probably need more info than "logging in to s9y doesn't work".

Greetings
Marc

Hi!

It would be really time consuming to isolate the login procedure from s9y, so I can't tell you the specifics of how to create a small cookie example.

Maybe you can try older builds of konqueror to see when a new version fails to work?

Regards,
Garvin

Hi Marc,

which version of Konqueror and S9y are you using? I'm on Gnome right now, but I could check if Konqueror works once I'm back home. Haven't had any problems so far, but who knows ...

- Mattsches

Zugschlus wrote:when I use konqueror as a browser, I have - since a few days - some issues with the administration suite. I log in, and get the admin main menu. I click on an entry of the menu, and am thrown back to the login screen.

This can - sometimes - be remedied by deleting the cookies that konqueror has stored. Other times, this does not help.

Since i haven't done anything to my s9y installation in the last few days, I am kind of stymied about this behavior. Any ideas what may be going wrong here?

The issue has re-surfaced with Firefox, eh, Debian Iceweasel 2.0.0.12, in the last few days. Am now out of browsers that I can reliably log in to my blog.

A pcap file showing a suggessful login process and getting me thrown back to the login screen is available on request.

Any ideas how to debug?

Greetings
Marc

Hi!

Do you run other applications on your blog-domain, like suirrelmail or phpmyadmin? Those can interfer with the PHP session on the same domain, even if in subdirectories.

Do you have any firewalls, proxies or filter-extensions that could be responsible?

Can you reproduce it on other Client PCs?

Regards,
Garvin

garvinhicking wrote: Do you run other applications on your blog-domain, like suirrelmail or phpmyadmin? Those can interfer with the PHP session on the same domain, even if in subdirectories.

No, blog.zugschlus.de is s9y exclusively. It's even a dedicated apache process, and the configuration hasn't been touched in months.

garvinhicking wrote: Do you have any firewalls, proxies or filter-extensions that could be responsible?

No, my notebook is connected to the internet via a regular NAT router, no proxies configured. Konqueror doesn't have any plugins at all, and my Firefox has only adblock plus, flashblock, it's all text, live http headers, mozex and web developer installed.

garvinhicking wrote: Can you reproduce it on other Client PCs?

No, it's a heisenbug that is sometimes repaired by deleting cookies (which is a severe nuisance since that means losing local configuration of all other web applications I use, and I very seldomly use other client machines.

s9y is the only application acting up this way.

Greetings
Marc

Hi!

What about that pcap, what does that contain? Never heard of that...is it a HTTP header capture?

No, it's a heisenbug that is sometimes repaired by deleting cookies (which is a severe nuisance since that means losing local configuration of all other web applications I use, and I very seldomly use other client machines.

You know that you can selectively delecte cookies, at least in firefox? There you can view cookies and only delete those associated to your blog URL.

Regards,
Garvin

garvinhicking wrote:What about that pcap, what does that contain? Never heard of that...is it a HTTP header capture?

libpcap is the library the tcpdump and wireshark use to capture packets on an interface. A pcap file is written by tcpdump or wireshark and contains the entire network traffic and can be analyzed with wireshark.

So, it contains both http headers and the payload, including IP headers.

garvinhicking wrote:

No, it's a heisenbug that is sometimes repaired by deleting cookies (which is a severe nuisance since that means losing local configuration of all other web applications I use, and I very seldomly use other client machines.

You know that you can selectively delecte cookies, at least in firefox? There you can view cookies and only delete those associated to your blog URL.

Unfortunately, that doesn't always solve the issue. Which is one of the reaons I suspect that s9y chokes on its own cookies that it just had set seconds ago.

Greetings
Marc, who is also present on #s9y for real-time discussion and debugging

Hi!

So, it contains both http headers and the payload, including IP headers.

Uff, okay. Too hard to analyze then.

Unfortunately, that doesn't always solve the issue. Which is one of the reaons I suspect that s9y chokes on its own cookies that it just had set seconds ago.

Why shouldn't it? If you delete the s9y cookies from that domain, then no other influencing cookies are there.

The only choking s9y can do is if it gets pre 1.1 headers, because the login routine changed in 1.1 - so those cookies should be cleared so that your browser does not send them anymore. But if you once cleared that, this isn't an option on your case.

Deleting all s9y cookies for the domain would suffice then, all other cookies on your machines can't possibly interfere and don't need purging.

Marc, who is also present on #s9y for real-time discussion and debugging

I can be there too, but only if someone pays me.

Regards,
Garvin

Hiho,

We used Mozillas Live HTTP Headers to analyze the problem - and found out that somehow S9Y seems to give a session-ID twice.

This is the live header session we see:



http://blog.rince.de/

GET / HTTP/1.1
Host: blog.rince.de
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; de; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12
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,de-de;q=0.8,en;q=0.5,en-us;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
X-OPENID-ANTI-PHISHING: VeriSign's OpenID SeatBelt/1.0.0.3354

HTTP/1.x 200 OK
Date: Fri, 14 Mar 2008 14:00:30 GMT
Server: Apache/2.2.3 (Debian) PHP/5.2.0-8+etch10
X-Powered-By: PHP/5.2.0-8+etch10
Expires: 0
Cache-Control: no-cache, pre-check=0, post-check=0
Pragma: no-cache
X-Session-Reinit: true
X-Serendipity-InterfaceLangSource: Content-Negotiation
X-Serendipity-InterfaceLang: de
X-Blog: Serendipity
Content-Type: text/html; charset=UTF-8
Set-Cookie: PHPSESSID=a77efda90fe6f7ff9bb0358716435db6; path=/
Set-Cookie: PHPSESSID=6a78b5890d0101abec7245049417e151; path=/
Set-Cookie: serendipity[karmaVote]=a%3A0%3A%7B%7D; expires=Sun, 13-Apr-2008 14:00:30 GMT; path=/; domain=blog.rince.de
Via: 1.1 blog.rince.de
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
----------------------------------------------------------
http://blog.rince.de/plugin/checkautobackup



The full file can be retrieved under
http://texte.rince.de/Blog-headers.dump


So, is there a way to find out why s9y produces here two Session-IDs? (This is s9y-1.2)

Ciao, Hanno
--

Hi!

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

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?

Regards,
Garvin