RE: [PHP] native vs. phplib sessions

> The major bugs I see in php native sessions are: > > 1/ the native version uses the /tmp dir for sessions, which I believe is > fairly > public and insecure. On a shared server, yes, but not on a dedicated. If you're not running safe_mode on a shared server then all of your PHP scripts are vulnerable, not just the sessions. > 2/ If you use a directory in your own account, if it's 2 more below some > level, > I forget which, garbage collection no longer occurs. also, the contents > are > still accessible via a browser, unless safe mode is set up, and that is a > lot of > headache as well. Haven't heard this one. As long as the directory is set in php.ini, garbage collection will occur. If you use session_save_path() within your scripts to designate a directory, then garbage collection will not occur. You must roll your own. > 3/ the native functions garbage collect at the wrong time, i.e. AFTER the > session is started, not before. Valid argument. > 4/ I you use custom handlers, you MUST save some value in the session, > (and not > an empty variable) in order to have a session, unlike using the fully > native > handlers. How is that a bug of the native session handler? Since you define your own save handler I don't see how that's the case. Unless if $_SESSION is empty the write/close handler is never called? > 5/ You can't destroy a session with a custom handler without having to > recall > session_set_save_handler() a second time again, PHP stupidly kills the > session > handler when you destroy the session. Also, not a bug of the native session handler. Couldn't you just use unset($_SESSION) or $_SESSION = array(); to erase the session data and destroy it? I guess if the #4 is true, you'd have to put a dummy value in it. > 6/ Custom session handlers may truncate session string data. (It might be > the > user who commented on it's fault, depending on the field with in his > database) That's not a bug, that's a user error. Use a field big enough for all of your session data, plain and simple. If you have your own handler and it works, then fine. Use whatever you're comfortable with. I just don't see a need for one in general. The only valid points I've seen so far for a custom handler is for uniformity across PHP versions and (with PHP5) making session variables private members of a class so the are "abstracted" and lower classes can't change them or set any new ones. I guess this would be useful depending upon your application. ---John W. Holmes... PHP Architect - A monthly magazine for PHP Professionals. Get your copy today. http://www.phparch.com/