Symphony.

System: Windows 7

WAMP: Apache 2.2.11, php 5.2.9-2

Browser: Chrome 5.0.375.125, Firefox 3.6.8/4.0b

System: Vista

WAMPServer: Apache 2.2.11, PHP 5.3.0

Public site (has logout issue): PHP 5.2.13, Apache 2.2.15

Local development site (no logout issue): PHP 5.3.2-1, Apache 2.2.14 (Ubuntu)

I’ve been able to reproduce it on my windows box (finally!)

The error is not due to garbage collection in the database (the entries are still intact), but a new phpsessid is generated which is empty. (both in the database as in the session itself).

The strangest thing is that the code responsible for handling the session is not changed (for as far as I can see, atleast).

I will do some more debugging, will keep you posted on my findings.

Nice work! Look forward to a solution :)

The error is not due to garbage collection in the database (the entries are still intact), but a new phpsessid is generated which is empty. (both in the database as in the session itself).

In my case a current session (not over two weeks old) with a full set of session_data (valid username and password hash) is being deleted when I leave the site without logging out. Of course, when I return to the site I have to log in again. It appears that this happens only when someone else visits my site while I’m away.

I’m not getting a new PHPSESSID cookie either. My site has kept the same cookie with the same id on my computer for days even though this logout problem is occurring several times a day.

@wisolman, would you be able to give us your server details to the site? We cannot reproduce any of this on our side so it’s been difficult for us to find a way to fix it. You can email the details to team at [this domain].

We’re having the same, or a very similar, issue at work. So far it doesn’t seem to be a server thing. Some users will get logged out, others can use it happily without any issues.

What surprises me most: normally putting content before the session_start method would return a fatal error.

In symphony, it should throw a new exception, but I have not been able to trigger that yet.

This could a be reason for creating new sessions every now and then. If the headers are already sent, the previous session is not restored, and a new one is generated.

Am I missing anything on the header thing?

In my particular case, I think I figured it out.

After using a packet sniffer, I found that when the error occurs with me (subsection manager), there was a redirect. The redirect redirects to the same page, but with an added slash between the hostname and the url (localhost//projectname instead of localhost/projectname).

That caused the path setting in the cookie to stop it from beeing sent, so a new cookie is generated, with the same path as the old one, overwriting the old one.

I have not yet found a fix, but it won’t be long.

In the htaccess file, my rewritebase was set to //projectname/, after replacing that with the normal /projectname/, no more logout issues!

This could also be the problem with the 404 errors described before. If the file does not exist, the htaccess rules will redirect the requests to symphony itself.

If this redirect has the wrong rewritebase, a new cookie will be set, even if an image is requested. This logs you out.

My rewritebase is set to / as always, so that doesn’t appear to be the problem in my case. I’ve made a hack or two that seemed to fix the problem for awhile but it eventually starts reoccurring.

@Allen - I’m on BlueHost. I posted the Apache and PHP versions near the top of this page. Is there something else that you need?

@wisolman: The issues you are describing have been pretty different from mine from the beginning. I would say they are completely seperate bugs..

This fixed my problem. Great find @creativedutchmen!

Looking at my htaccess rules, I did see the RewriteBase //projectname/ scenario. When I removed the extra slash (resulting in /projectname/) the logout error no longer occurred. 404 errors on the front end no longer cause me to be logged out of the admin.

I examined my working install of 2.0.8RC3 and the htaccess rule was simply /projectname/, so I guess the question is why 2.1 is creating the htaccess rule differently…

In the htaccess file, my rewritebase was set to //projectname/, after replacing that with the normal /projectname/, no more logout issues!

At first glance that appears to have fixed it for me as well.

I’ve found, at least in my installation, that these settings in class.session.php

if (session_id() != "") {
    ini_set('session.save_handler', 'user');
    ini_set('session.gc_maxlifetime', $lifetime);
    ini_set('session.gc_probability', '1');
    ini_set('session.gc_divisor', '3');
}

are never made because session_id is never set at this point. In fact, it will produce an error if these settings are attempted after a session is started. I removed the condition to allow the settings to be made regardless of the session_id() value and the logout problem went away — at least for now. I’ll know more about the effectiveness of this change tomorrow.

For some reason I couldn’t get the same results by changing these values in the php.ini file.

I examined my working install of 2.0.8RC3 and the htaccess rule was simply /projectname/, so I guess the question is why 2.1 is creating the htaccess rule differently…

This is also why the bug appears only on windows. The windows directory seperator is normally the backslash (\), but the forward slash (/) is also used.

The old code stripped the forward- and backslash from the beginning and the end of the folder, where the new code only filters the OS standard (backslash for windows). This will leave any forward slashes intact.

I’ve already proposed a fix, alistair is working on it;)

This is also why the bug appears only on windows. The windows directory seperator is normally the backslash (), but the forward slash (/) is also used.

I’ve had this problem before with 2.0.8RC2 on my work machine, which is windows. Because the core team only seemed to support the LAMP stack at that point, nothing was done about it. Every time I install a test site on windows now, I automatically check the .htaccess file and make adjustments.

Glad you found it! I hope all these issues can be solved, I’m really dubious about using 2.1 I just don’t get how 2.0.8RC3 was the most stable release candidate yet, then 2.1 has all these bugs in it?! How can so many changes have taken place?

How can so many changes have taken place?

I think most bugs in 2.1 are introduced when the code was cleaned up. This is pretty much the case in this bug, and in the file upload field.

Oh, and by the way, the error here is in the install file, which has to be rewritten, so maybe it isn’t too strange..;)

So guys, Alistair took a look into the issue we where having today. It turns out the cookie was never being initialised due to an extension that overloaded parts of Symphony to do its own crazy stuff.

The hack that has solved our problem? Adding $this->Cookie->get('init'); to line 83 of symphony/lib/core/class.symphony.php, at the end of the __construct function.

I really doubt that this will fix your issues, but it’s worth a shot.