Symphony.

I'm a little bit confused about how to handle sessions correctly (best practice for Symphony) in an extension I'm currently working on.

Normally, I would just store a value like

$_SESSION[$key] = $value;

This is how the Session Monster extension seems to work.

But Symphony also has its own session class AND a cookie class (which brendo recommended to use in this comment).

What's the correct (recommended) way of working with session data in an extension?

Personally I'd rather use the Symphony Cookie stuff. Seems quite robust; I've been using it to handle authentication; and store other basic information such as from where the user has visited the site etc.

The only downside maybe if you have plenty of visitors is the size of the cookie/session table in Symphony since data is usually kept for two-weeks. However you can also set your own custom expiry period if you want a longer/shorter time-frame.

The session stuff in Symphony is all handled through the Cookie class, I found out the hard way while developing the Twitter Notifier.

You can use Cookie and $_SESSION interchangeably I believe. Symphony tells PHP to store sessions into the database. What's often confusing is that if you use the Cookie class, you expect a cookie to be created, but in reality it stores this data into the sessions table with an expiry and your browser only sees (and sends) the session ID. It's a somewhat poorly named class, but it works. I'd suggest using Cookie since this is what the core uses — it ensures your logic goes though the same API as everything else.

Thanks a lot for your help guys.

However you can also set your own custom expiry period if you want a longer/shorter time-frame.

Since the expiry period only seems to be stored for the whole session, wouldn't changing this from one extension interfere with other extensions that might use session data?

I think so, yes. I hit this problem when wanting to expire Members sessions and found it was not possible (there's an issue in the members repo describing what I found).

I am not 100% sure about this. Because if you create a cookie and just use the same name - not the other parameters as well it could possibly set another cookie. As I had a small bug for 'logout' just because of this but I've never tested it; for the purpose of having different-expiry time cookies.

Mhh. I used the simple and oldschool approach for now since Symphony's session handling still confuses me (updated the "Can Of Spam"-extension). Will improve on this later.

Maybe we should account for stuff like this while the discussion is hot.

@nickdunn, sadly i spent the last 2 hours finding out the exact same before stumbling over this issue here. although it seems that setting the timeout period globally now works as expected. i set it to 60 secs in the DEFINES and it logs me out after that time has elapsed (whether i am idle or not).

but still all cookie information is stored on the same entry in sym_sessions and only one cookie is created in the browser. so if i need to set the expire for a member differently than that of a symphony backend user (which i need to) my session always gets revived because the single cookie always has the global expiry date (two weeks).

what i want to do is log members out on close (so i would like to set expires to 0) and keep backend users logged in as is. also i'd like to keep track of logged in members, which i could if the two were separated or at least a new entry with updated cookie information would be created in sym_sessions if the member "cookie" expires.

We definitely need a new mechanism for handling sessions (or better explanation/documentation of the existing stuff). It's not just Core and Member, other extensions like shopping carts, payments, etc. need independent session handling (or at least expiration times) as well.

It'd be nice if we can configure session handling via drivers, e.g database, apc, memcached, cookie and so on. Could be useful for cacheing too.

Does anybody know why Symphony updates the expiry time of sessions (which is "Cookies" in Symphony) in the database session table although the browser cookie will expire anyway? This leaves orphaned sessions in the session table.

In other words: Why is the browser cookie's expiry time not updated?

OK, it has been discussed before. It's a conceptual flaw that needs to be fixed.

And there's an issue on GitHub.