PHPSESSID (Semi-Bug)

[DrNI]

Hi there,

I've been running S9Y for quite a while. Recently I successfully updated my two blogs.

I found out that in recent versions of S9Y, confusing things happen as soon as you have two blogs on one Internet domain: depending on which blog I visit first, the language of the second blog's controls adapts to the one of the first. I checked my cookies and found out, that all PHP applications on my domain are using the cookie PHPSESSID for storing the session key.

In order to prevent two installations of S9Y from interacting on the same domain, I found it useful to put the following intro the .htaccess file:

php_value session.name LalaSID

Choosing a custom session name for each installation prevents the problem and keeps other PHP applications on the domain from doing even more unpredictable things with S9Y.

Perhaps it would be a good idea to make S9Y aware of that and have it using its own session name per installation automatically.

Best

DrNI

http://www.drni.de/blog/
http://www.drni.de/niels/cl/blog

[garvinhicking]

Hi!

That's generally a good suggestion, but we'd need to think of the best way to use this. .htaccess is surely easy, but would require regenerating the file on update. Using it within PHP scope would be the most compatibly way, but there we'd have to create a unique session name for each installation; we could use the serendipityHTTPPath variable for that (stripping all "/"s of course), but it would also mean putting session_start later in the scope for when we have the configuration data loaded already. This in turn might create some side-effects, when session initializing is done later one.

So I'm tending towards a .htaccess solution, and maybe using a randomly created variable name...

Regards,
Garvin

[kleinerChemiker]

Gibt es .php-Files, die ausgeführt werden und nicht im Hauptverzeichnis liegen? Falls nicht, sollte es reichen, folgenden Code vor session_start() einzufügen.

Code: Select all

session_name('s9y_' . md5(dirname(__FILE__)));

[Don Chambers]

This would be great if it can be incorporated into s9y itself.... I think it could solve a lot of issues people report with more than a single s9y installation - myself included!

[garvinhicking]

Hi!

@kleinerChemiker: Ah, great idea. I've committed this to the svn trunk, I believe this should work well.

This would be great if it can be incorporated into s9y itself.... I think it could solve a lot of issues people report with more than a single s9y installation - myself included!

I fully agree. Actually, this is one particular instance that was always nagging me and I never got to the root of it.

Regards,
Garvin

[Don Chambers]

Awesome... did you commit it to just trunk, or also the 1.4.2 branch?

[DrNI]

This would be great if it can be incorporated into s9y itself.... I think it could solve a lot of issues people report with more than a single s9y installation - myself included!

I think that if S9Y uses cookies otherwise, it always stores them together with the path to the installation. At least I have some in my browser like serendipity[author_token] etc. which are specific to "/blog/"

The difference seems to be that the PHP engine - at least on my server - always uses the path "/" for the PHPSESSID cookie.

So go on with the workaround and make people happy.

DrNI

[Don Chambers]

The difference seems to be that the PHP engine - at least on my server - always uses the path "/" for the PHPSESSID cookie.

So does mine... but I have not had the chance to test the patch yet.