tags:

views:

181

answers:

5

Is there currently - or has there ever been - any serious or significant problem with PHP's built-in session handling?

I mean, it's always worked for me and my projects.

But I see some codebases and frameworks out there seem to use a custom handler. Is this reinventing the wheel? Or improving on some flaws? What flaws?

+5  A: 

Is there currently - or has there ever been - any serious or significant problem with PHP's built-in session handling?

No problems with the built-in handlers. Access and deletion of old session files are implemented well.

Is this reinventing the wheel? Or improving on some flaws? What flaws?

File based session handling works fine for single server websites. Problems may arise when applications need to be run on multiple servers (scaled out). A master database can be used to store and provide session information across multiple servers. This can make things easier when an application is scaled out. Custom session handlers can be used to interact with the database.

webbiedave
I think the OP is after "why", rather than alternatives...
MatW
My answer was intended to provide a "why" someone would use them. I've reworded to make it a little clearer.
webbiedave
nice one :) I know I'm being a pedant, but I can't stand oblique, "Why are apples green? Cake is better" style answers...
MatW
A: 

A reason to roll your own session handlers would be implementing a single-sign-on system, or session sharing with other applications (= validation of sessions by a Java/CF/whatever application).

Pekka
A: 

Sessions can only be up to a certain size no?

SeanJA
I *think* there is no official limit like there is for cookies, but a big session data file would be loaded into memory on every request that does a `session_start()`.
Pekka
It is limited by the maximum amount of memory your script is allowed, so I guess it would be the same for a database / (some other way of storing it) session.
SeanJA
+1  A: 

One of the major advantages of overriding the session behavior is being able to persist the session information into a database. When that is combined with user authentication it can become a powerful tool.

It really opens up a whole new set of possibilities:

  • Build session management tools for site administrators
  • Audit trail of a user's session data.
  • Ability to lock a users account and easily kill active sessions
  • etc.
Tibrim
+5  A: 

Pros and cons of PHP's built-in session handler

  1. Pros:

    1. Easy to use (just use session_start() and you're done)
    2. Available OOTB.
  2. Cons:

    1. Uses only SESSID (or SID, SESSIONID, etc.) cookie to recognize user. That's not much, and this information can be easily stolen using XSS attacks or something like that.
    2. In most cases you aren't able to do things like get total count of active sessions (often used in Who's online? features)

Pros and cons of your own session handler

  1. Pros:

    1. Works in the way you want it to work
    2. Total control over how do you recognize users. You can use cookie, IP address, browser signature to make sure that stealing session is impossible (or at least it's much harder task).
    3. You can chose the place where the session data is stored (database/filesystem)
    4. You've got control over session mechanism as a whole
  2. Cons:

    1. You have to spend several minutes to create a such handler
Crozin