Symphony.

I have some problems with working with sessions. I looked through the forum and I saw earlier cases of similar behaviour, but it didn’t provide my with an answer to my problem. Let me explain what happens:

On localhost my site works just fine. However, when I upload it to a subdomain of my own domain, the strangest stuff happens:

• I can’t login in Symphony. When I enter my credentials I just get redirected back to the login form. No error or nothing.
• I have a webshop on the frontend, and when I add items to the cart they don’t get stored.

Now, the strangest bit is, sometimes it does work! So if I tried logging in for 20 times or something, then the 21th time it works and I’m logged in. The same goes for the webshop. It doesn’t remember it’s contents, but for some strange reason when I check back 5 min. later to try again it remembered the item I previously clicked. Adding new items to the cart doesn’t work at that moment.

I tried looking at how the session get stored (looking at class.session.php), but I still don’t have a clue what’s going wroing :-S I’m at the point of pulling my hair out over this one. X-S

Does anyone know what’s going wrong? What could be causing this behaviour? I’m using Symphony 2.1.2—

Is there a way you could test sessions in general on the server in question, to rule that out at least?

That’s the first thing i tested and the sessions work as normal on the website. So that’s ruled out.

Ok, I’m not sure what’s going wrong, but I’m pretty sure it’s the way Symphony handles it’s sessions (by storing them in databases etc and such).

When I commented out everything in the start()-function in class.session.php and replaced it with:

@session_start();
return session_id();

everything works fine.

Now I’m not sure what caused this problem. I looked through the session-class and the cache-class, but I don’t see any real complex code. My guess is that somewhere something goes wrong with the garbage collection and/or the session expire time. Perhaps it has something to do with the timezone set by PHP?

Anyway, I fixed it by commenting all the old code and using good old plain PHP sessions. Which makes me have 2 questions:

1. Why are sessions in Symphony stored in such way? Whats the benefit above regular sessions?
2. Should this be filed as an issue?

Why are sessions in Symphony stored in such way? Whats the benefit above regular sessions?

I’ve often wondered this myself.

Yeah, it seems to me that the whole essence of Symphony is using as much built-in functionality in the core of PHP (like XML/XSL parsing and also the DOMDocument-functions in the upcoming Symphony 3).

So why is it that sessions have this custom code around them? As proven today this only supplies an extra opportunity to slip in some nasty bugs. Could somebody please explain why this is better than PHP’s built-in session handling?

There is one reason I can think of: it is the only reliable way to remember session date for a longer period of time.

Normally, sessions would use textfiles containing the data, if a database is used for this, it takes a lot less memory and CPU to search through the data if there is a lot of it. (which is what will happen if session data is stored for a longer period of time).

it is the only reliable way to remember session date for a longer period of time

What is this used for in Symphony? Under what use case does Symphony need to remember sessions beyond their default lifetime? The only thing I can think of is to keep authors logged in over multiple sessions, but that is solved with a cookie.

The only thing I can think of is to keep authors logged in over multiple sessions, but that is solved with a cookie.

Yes, this is solved with a session cookie. So the session data on the Symphony end needs to be stored somewhere, which is where the database comes in.

The only thing is: is keeping authors logged in for a longer period of time worth the session handling with all bugs attached to it? Or should we replace all of it by a cookie stored username + hashed (with added salt and pepper) password combination. The latter will be a lot easier to write and maintain.

Yes, I too would like to know why the default time for the sessions is 2 weeks. Has anyone set the $this->Cookie = new Cookie in the class.symphony.php file to lets say 1hour? What’s the impact of changing this, as well as the CACHE_LIFETIME?

This is interesting.

@kanduvisla can you debug a little further?

At what point in the start function does it fail? Is the database not properly created?

It’s one thing to say replacing the function fixes it, but it’d be nice if we could figure out just why :)

@Csam0003, changing it to whatever you like will have no odds effects, other than your session will expire every hour (same goes for the Members extension).

Thanks Brendo

@brendo: I couldn’t quite figure out what was causing the problem, because sometimes it remembered a bit of the session, but not all of it. For example: You would try to log in (or modify something else to your session). At the end of the script it’s placed in the session, but when te page reloads, it’s gone from the session.

But… When you modify the session and don’t refresh (like for 15 min.) or something, then it would remembered it. But then adding something else to the session would result in the same result described above.

My guess it has something to do with timestamps mismatch between PHP and the database (since the timestamps are stored in the database). I also found that a timezone of ‘localtime’ could give problems on some servers. Perhaps this is to blame?

Nevertheless, it only happened to me on one server thusfar, but I think it’s something to look at. When I have the time I could look into it any further, but for now time is not on my hand.

I can confirm this problem again. I tried to login in a website. Here is the strange part:

It worked in all browsers, except for one... You can guess which one...: Internet Explorer (9).

I had no problems on our internal develop environment, but as soon as the site went live, logging in was not possible due to the session weirdness. Commenting out everything in the start()-function and replacing it with

@session_start();
return session_id();

Seemed to fix the problem (again). Which brings the question to light:

1. Why does this happen? (Symphony 2.2.1)
2. Why are sessions stored in the database at all?