Re: native vs. phplib sessions

I agree with everything you said. On 4 below, I was reading directly from the page I quoted. Your own handlers will not be called if there are no set variables, but the native ones will, if there are unset variables. I am on a shared server, so 2 is important. For security, I change the permissions on all my files and directories to 404 after they are finalized. I also choose some randomly named directories and have some strict rules in my .htaccess file at the doc root for what can be shown by a browser and what cannot. That's the best I can do on a shared server, save doing cgi on my own and restricting access to the doc root to only my instance of cgi/php. since I don't know how to do that and I don't want the performance hit, I won't do it. On this shared server, I'm going to use PHPLIB container (db_pgsql), and native PHP4 session framework. It apparently is brainless, (which I uuuuuh, uuuuuh, uhhhhh, like ) :-). I'll post my experience when I have it working. "John W. Holmes" wrote: > > > 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/