#1
  1. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Posts
    3,959
    Rep Power
    1014

    Reimplementing sessions?


    Hi,

    PHP sessions suck.

    Since there's no difference between starting and resuming a session, anybody who visits a protected page without being logged in will create a useless session data set and receive a useless cookie. The whole logic is just weird: When there's no session, you create one -- just to realize that it's empty and that there never was any session in the first place.

    Since the concept of dumping all data in a string is hard coded, there's no way to get type safe data or at least make sure the user ID points to a valid user.

    Given those weaknesses, I wonder if it might make sense to just throw it all away and implement my own sessions. I mean, it's pretty common to define custom session handlers, so why not go one step further? Do you see any serious problems associated with that? Sure, I'll lose the $_SESSION superglobal and the garbage collector. But apart from that, I don't think I'd miss anything.
    The 6 worst sins of security ē How to (properly) access a MySQL database with PHP

    Why canít I use certain words like "drop" as part of my Security Question answers?
    There are certain words used by hackers to try to gain access to systems and manipulate data; therefore, the following words are restricted: "select," "delete," "update," "insert," "drop" and "null".
  2. #2
  3. Wiser? Not exactly.
    Devshed God 1st Plane (5500 - 5999 posts)

    Join Date
    May 2001
    Location
    Bonita Springs, FL
    Posts
    5,947
    Rep Power
    4033
    Originally Posted by Jacques1
    Hi,
    Since there's no difference between starting and resuming a session, anybody who visits a protected page without being logged in will create a useless session data set and receive a useless cookie. The whole logic is just weird: When there's no session, you create one -- just to realize that it's empty and that there never was any session in the first place.
    I don't really see any problem with this personally, some extra files aren't going to break anything, and they will get cleaned up in due time.

    If such a thing does bother you though, you don't really have to re-implement sessions to fix it. You could solve the problem with a custom session handler, or your own session_resume() that rather than session_start on page where you want to only resume a session.

    Code:
    function session_resume(){
       $name = session_name();
       if (!isset($_COOKIE[$name])){  //could also check $_POST/$_GET if you want
           return false;
       }
    
       $id = $_COOKIE[$name];
       $path = session_save_path();
       $path = $path.DIRECTORY_SEPARATOR.'sess_'.$id;
       if (!file_exists($path)){
          return false;
       }
    
       session_id($id);
       return session_start();
    }
    Originally Posted by Jacques1
    Since the concept of dumping all data in a string is hard coded, there's no way to get type safe data or at least make sure the user ID points to a valid user.
    Not too sure what you're getting at here. The fact that it stores the session data as a serialized string? If that's it, I don't really see much of any other way to do things. You need to be able to write out a representation of the data to a file.

    Things such as user ID's just need to be verified each time you restore the session data. If someone else say deleted a user making their ID invalid, there's not a good way to communicate that to the active sessions. It works out better to just have the sessions verify their contents when restored. Obviously PHP can't do that on it's own because there's not generic way to verify the contents of a session, that's where your custom save handlers come in.
    Recycle your old CD's, don't just trash them



    If I helped you out, show some love with some reputation, or tip with Bitcoins to 1N645HfYf63UbcvxajLKiSKpYHAq2Zxud
  4. #3
  5. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Posts
    3,959
    Rep Power
    1014
    I should have added that I wanna move all sessions to the database in any case.

    So I'm talking about a serialized string in a single column vs. a properly normalized table with a foreign key for the user ID (and all the other features to ensure data integrity).

    Of course you can fix the issues to some extend by adding custom code on top of the existing functionalities. That's what I considered first. However, when I actually started with it, I realized that there wouldn't be much left from the standard sessions.

    For example, when you write your own session_resume() like you did, you'd also have to write your own session_start(). Because session_start() is now supposed to actually start a new session and not resume an existing one -- which is incompatible to the standard implementation.

    So when you define all the open/read/write/... logic in your own session handlers and add all kinds of workarounds, it seems to me that you might as well start from scratch ...
    The 6 worst sins of security ē How to (properly) access a MySQL database with PHP

    Why canít I use certain words like "drop" as part of my Security Question answers?
    There are certain words used by hackers to try to gain access to systems and manipulate data; therefore, the following words are restricted: "select," "delete," "update," "insert," "drop" and "null".
  6. #4
  7. Wiser? Not exactly.
    Devshed God 1st Plane (5500 - 5999 posts)

    Join Date
    May 2001
    Location
    Bonita Springs, FL
    Posts
    5,947
    Rep Power
    4033
    Originally Posted by Jacques1
    For example, when you write your own session_resume() like you did, you'd also have to write your own session_start(). Because session_start() is now supposed to actually start a new session and not resume an existing one -- which is incompatible to the standard implementation.
    I don't think it's really necessary. You'd just use session_start() in a place where you want to start a new session (ie the login page) and session_resume() everywhere else.

    If you want to create your own session API you certainly can, there's nothing wrong with doing that. Other than loosing the $_SESSION super-global (not a big deal) there shouldn't be any problems.
    Recycle your old CD's, don't just trash them



    If I helped you out, show some love with some reputation, or tip with Bitcoins to 1N645HfYf63UbcvxajLKiSKpYHAq2Zxud
  8. #5
  9. No Profile Picture
    Lost in code
    Devshed Supreme Being (6500+ posts)

    Join Date
    Dec 2004
    Posts
    8,317
    Rep Power
    7170
    Since there's no difference between starting and resuming a session, anybody who visits a protected page without being logged in will create a useless session data set and receive a useless cookie. The whole logic is just weird: When there's no session, you create one -- just to realize that it's empty and that there never was any session in the first place.
    PHP sessions operate in this way because they are not designed solely for authentication systems. They are simply meant to be a persistent storage mechanism that lasts for the duration of a browser session. Whether the user is authenticated or not does not matter at the PHP session level, which allows PHP sessions to be used for purposes other than authentication.

    Conceptually a login system can be built on top of PHP sessions and operates at a level "above" the PHP session. The login session data only exists when the user is authenticated, but the underlying PHP session data is meant to exist even when the user is not authenticated (thus allowing it to be used for non-login session data too).

    Since the concept of dumping all data in a string is hard coded, there's no way to get type safe data or at least make sure the user ID points to a valid user.
    Serializing the data into a string is the most compatible way to do it, and it works well for most applications. The session handler hooks exist for the express purpose of allowing more complicated application-specific methods of storing session data.
    PHP FAQ

    Originally Posted by Spad
    Ah USB, the only rectangular connector where you have to make 3 attempts before you get it the right way around

IMN logo majestic logo threadwatch logo seochat tools logo