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?

hi,

i don't know if this is the exact same error as described here but i have the following and it is driving me nuts ...

when i log into symphony with my credentials it always redirects me to the login form with no error whatsoever. if i then reenter my credentials i get logged into the backend. then, when i visit the site with the next click everything is fine. but if i then click any link on the page i get logged out from the backend. i have looked a bit into it and found that the cookie seems fine, but apparently there is no session beeing written to the database. the session table is empty. i tried the abovementioned fix (commenting out the code in the start method and replacing it with basic session start) but this doe not seem to work.

what is even more of a bummer is, that this whole site setup worked fine in development, but not on the customer server.

any help is greatly appreciated! :)

thanx,
daniel

Any clues in your Symphony error log files in the manifest folder?

hi nick,

no, nothing at all in the logs. :(

what puzzles me is that the first login attempt always redirects back to the form but the second one always gets through. its not at all random. and once logged in i can work in the backend with no problems. but if i go to the frontend i get logged out of the backend immediately after the first click.

also, as mentioned the session table holds no records. i just tried logging in with a different user and on the development system a new session entry is written as eypected but not so on the live system.

im kinda lost.

cheers
daniel

I don't want to be a pain in the ass for bringing this up all the time, but why do we still have this session stuff in place?

My websites keep logging me out in the middle of development, because it was then 2 weeks since my last login, instead of resetting the counter on every request.

It is not possible to change the session behaviour to the standard "close your browser and be logged out", which is very useful for apps that need to be a tad more secure.

The whole thing feels buggy, and leads to nasty side-effects (as can be seen in this thread). Can we please discuss removing this "feature"?

My websites keep logging me out in the middle of development

Yep, happens to me too.

Also, it seems a bit much to have 113 sessions stored in the database (as I have on one site) when the user possibly isn't coming back.

close your browser and be logged out

Would be great, maybe apart from the developer users, and primary user account. As Huib just stated, why can't these be reset each time they log in?

why can't these be reset each time they log in?

In fact, they can. It just hasn't been implemented. Is this something more people would like? I am willing to implement this, and send a pull request.

Also, I would like the "remember me" feature to be optional. If I borrow someones laptop I'd love to be logged out immediately after I close the window, because I always forget logging out.