Search

When I loaded my website this morning I found that I was logged out again. My first thought was that “logout madness” had returned. Then I remembered that my cookie was set to expire on 14 August 2010. (I noted this while I was trying to track down the cause of my logout problems.) This got me thinking about the two ways that an existing session can be ended — through cookie expiration or session garbage collection — so I looked to see if this was described in the documentation. Since I didn’t find it I decided to write something for new users of Symphony. Of course, corrections are welcomed.


The purpose of this article is to describe how PHP Sessions and Cookies are used in Symphony CMS and how that affects the user of a website powered by Symphony. I won’t get into great detail about the general usage of sessions and cookies because Googling those terms will turn up several good tutorials. Here is one.

When a new visitor views a Symphony powered site a cookie is placed on the visitor’s computer, a session record is stored in the site database and some parameters are set. The session and cookie are related through a unique key that is stored in both. The cookie is set to expire two weeks from the time it is created. The session, however, doesn’t contain an expiration date. It just keeps a record of the last time the visitor loads or refreshes a page on the site. The session record also contains a visitor’s username and password if the visitor has logged in.

The parameters control the session garbage collection process. One is a “timeout” period that causes a session to be deleted when the visitor doesn’t view the site for two weeks. Another two together determine the frequency of occurrence of garbage collection activity. They specify that, on average, only one of three instances of site activity by any visitor can result in garbage collection. Garbage collection is the process of deleting obsolete session records. A session record is considered obsolete if it contains no log-in information or if it hasn’t been active for the past two weeks.

Now how does all this play out for a site visitor? When the site is first loaded it checks to see if the visitor’s computer has a site cookie from a previous visit. If it doesn’t, a cookie is created and a session is started. If it does, the site uses the key from the cookie to see if a matching session still exists and if the visitor is still logged in. If no matching session exists, a new session is started using the key from the cookie.

Site visitors who have no log-in privilege are affected very little by cookies and sessions. Visitors who can log in are able to stay logged in for up to two weeks if they don’t log out before leaving the site on their previous visit.

The lifetime of an existing session is theoretically determined by both cookie expiration and garbage collection. But, since the key parameter for both is set to two weeks, cookie expiration will dominate in ending sessions. Cookies always expire two weeks after they are created, but a session can remain active forever if the elapsed time between visits never exceeds two weeks.

Thanks for this. Bookmarked for addition to the docs.

Question: If I work on a site everyday, is there a reason why the cookie expiration date is not updated to expire on a later date (always 2 weeks from now)?

I don’t know why the cookie expiration time is not advanced on each visit. I also don’t know why it couldn’t be. I suppose it was thought that having to log in twice a month was not that inconvenient. And I agree.

it does seem like the cookie headers are updated on login only, hence not updating every time you visit a site if you’re not logging in everyday.

Then I’d like to request that this behaviour is adjusted to automatically update the expiration date.

@wtdtan - The cookie expiration date is never updated whether you log in or not. At least that is true on my installation (2.1.0)

@Nils - That, of course, is a request that only the core development team can grant — unless it can be done through an extension.

@Nils: shouldn’t be too hard. I will take a look into it now.

EDIT: What would be the difference between setting the date again and just setting the date to the far-future?

@creativedutchmen:

  1. If you reset the date you will be logged out after two weeks if you are not revisiting the site.
  2. If you set the date to the far-future you will not.

I’d prefer the first solution.

If you set the date to the far-future you will not [be logged out after two weeks].

not exactly. You will be logged out as the garbage collection will delete your session data on the server after two weeks. However, your Session-ID will never change. Wich isn’t a good thing either.

I was thinking about something similar after reading wisolman saying

If no matching session exists, a new session is started using the key from the cookie.

I don’t think that’s a good thing as it might make the unique IDs more predictable and/or make your users more prone to attacks. I’d want the SID to change as often as possible (after logging out and after garbage collection).

However, your Session-ID will never change. Wich isn’t a good thing either.

This could be easily solved by using the session_regenerate_id function.

I have been looking at the session and the cookie class, and they are not what you would expect them to be. The cookie class does not do anything with cookies, but it changes session data instead.

Maybe the entire session/cookie handling needs to be reworked to make sense.

I have been looking at the session and the cookie class, and they are not what you would expect them to be. The cookie class does not do anything with cookies, but it changes session data instead.

I’ve found that too. The naming is quite confusing :-)

Now if you guys go and rewrite the session/cookie handling I’ll have to rewrite my documentation. (Just kidding.) I had noticed too that the cookie class works mostly with sessions. Perhaps we don’t need a separate cookie and session class.

I’d want the SID to change as often as possible (after logging out and after garbage collection).

I’ve edited the class.symphony.php file (symphony/lib/core). On line 192 (in the isLoggedIn() function) I’ve added the following:

                    $session_id = session_id();
                    session_regenerate_id();
                    self::$Database->update(array('session' => session_id()), 'sym_sessions', " `session` = '$session_id'");

Which generates a new session id every time you visit a protected page.

However, if you are really concerned about session hijacking there are a few other things that would be quicker and safer (linking the session to ip’s, browsers, etc)

Will you not also have to change the cookie id to match the new session id? If not, it won’t be able to find the session on your next visit. Symphony uses the cookie id to link up with an existing session. If it doesn’t find one it will create a new session and leave the old modified session dangling until garbage collection deletes it.

Will you not also have to change the cookie id to match the new session id?

That’s what the session_regenerate_id() function is for. It generates a new session id, and sets the cookie accordingly.

Okay. Didn’t know that.

I tested your changes and found that it generates a new cookie, which means the expiration date is also reset. This should accomplish what Nils is requesting.

But is isLoggedIn() the right place for your regeneration? This causes the regeneration to occur on every page load or refresh. That seems a bit too frequent.

However, if you are really concerned about session hijacking there are a few other things that would be quicker and safer (linking the session to ip’s, browsers, etc)

Not really. :-)

But is isLoggedIn() the right place for your regeneration? This causes the regeneration to occur on every page load or refresh. That seems a bit too frequent.

I was more thinking of “on every Logout” and “if Cookie ID is unknown”.

Maybe I don’t get the point, but didn’t Alistair answer the essential cookie/session thingy in this comment?

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details