Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Is coupling these two concepts a bad approach?

As of right now I'm delegating all session handling and whether or not a user desires to logout in my file. As I was writing my Auth class I started wondering whether or not my Auth class should be taking care of most of the logic in my Regardless, I'm sure there's a more elegant way of handling this...

Here is what I have in my (also a large chunk of this code is based on a reply I found on SO except I can't find the source ._.):

ini_set('', 'SID');

# session management
session_set_cookie_params(24*60*60); // set SID cookie lifetime
if(isset($_SESSION['LOGOUT']) {
    session_destroy(); // destroy session data
    $_SESSION = array(); // destroy session data sanity check
    setcookie('SID', '', time() - 24*60*60); // destroy session cookie data
    #header('Location: '.DOCROOT);
} elseif(isset($_SESSION['SID_AUTH'])) { // verify user has authenticated

    if (!isset($_SESSION['SID_CREATED'])) {
        $_SESSION['SID_CREATED'] = time();
    } elseif (time() - $_SESSION['SID_CREATED'] > 6*60*60) {
        // session started more than 6 hours ago
        session_regenerate_id(); // reset SID value
        $_SESSION['SID_CREATED'] = time();  // update creation time

    if (isset($_SESSION['SID_MODIFIED']) && (time() - $_SESSION['SID_MODIFIED'] > 12*60*60)) {
        // last request was more than 12 hours ago
        session_destroy(); // destroy session data
        $_SESSION = array(); // destroy session data sanity check
        setcookie('SID', '', time() - 24*60*60); // destroy session cookie data

    $_SESSION['SID_MODIFIED'] = time(); // update last activity time stamp
share|improve this question
Pretty and Proper OO ∉ PHP – anonymous coward Feb 6 '11 at 6:59
You can indeed do pretty and proper OO in PHP. That's despite PHP, not because of it, which is the proper thrust of your argument. – Frank Shearar Feb 6 '11 at 14:55

Session control falls under security, which is generally considered one of the more fruitful areas to apply AOP rather than OOP principles. That is to say, security considerations tend to be more of an aspect or a cross-cutting concern than your application's core logic. That said, AOP is probably going to be more of a distraction at this point so let's stick to OOP.

One of the promises of OOP is that you'll get code that closely models you problem domain. So what have we here? Users sending you Requests, belonging to Sessions. As a start you can create these classes and try to imagine the relationships (together with assigning multiplicity) between them. One tried and tested way to work this out is to draw up CRC cards for each of your classes and imagine the "conversations" they'd be having with one another, such as some MVC controller asking the Request it is servicing which Session it belongs to, and what User is associated with that.

Here's where the aspect angle of security comes in: the security enforcement code doesn't really care about your application logic, it just does the same things over and over. For instance, if a Request arrives that isn't associated with a Session, it displays a login page. Some OO frameworks call these interceptors, in AOP terms it would be an aspect - you get the idea.

Of course your application might make use of some completely different security model - this is just one example. What makes it OOP is the way it models and encapsulates the entities you're dealing with.

share|improve this answer

I tend to couple authentication with authorization, and not with sessions:

  • Users may come to the site and never log in. They'll still have a session
  • Users may come to the site, log in once, and never log out. The session should still expire once they've left.
  • Users may take actions which require a temporary escalation in authorization (for example, updating their address, or viewing/changing their credit card data). They should probably log in again for these kind of activities
  • From a security point of view, it's better to authorize (and therefore, authenticate) at the transaction level rather than the session level. For example, you might authenticate to gain permission for loading some of the users' information into the session, and then again when the user wants to change the information. That way, if someone walked up to the computer while the user's not looking, your site still does the right thing
share|improve this answer

I'd go for Database Driven Sessions (i.e. storing all session data in a database, not the server), and wrapping the session handling functions in a session class. In a somewaht generic OO syntax that would be:

class Session{
    public open(name);
    public close();
    public read(var);
    public write(var, value);
    public destroy();

Looking that you are using PHP, refer to session_set_save_handler and pass it the following.

$session = new Session();

You have to implement the garbage collector method and check for the right behavior for each of your handler methods, but that would be the general idea. You could also forget using PHP session functions altogether and replace them with your framework, but I'd rather integrate my class to native functionality.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.