Re: Session management module - thoughts

I'm not sure I'm following you, but what I have in mind is something every John Doe newbie user can handle. Something along the lines of: session_start(); session_variable($foo); session_variable($bar); That would save up $foo and $bar at the end of the page execution (request_shutdown), in a completely transparent way to the user. In that sense, it should probably be limited to files. I guess we could probably make session_start() support an optional variable that tells it where to store the information, but the default should be files that would just work out of the box. That would be suitable for the vast majority of users. Zeev On Fri, 28 May 1999, Sascha Schumann wrote: > On Fri, May 28, 1999 at 12:54:41PM -0400, Jim Winstead wrote: > > On May 28, Zeev Suraski wrote: > > > What I have in mind is a KISS approach to sessions, through a built-in PHP > > > module. For information storage - use files. Implement functions that > > > start a session, that add variables to a session, and possibly that end a > > > session. At request_shutdown, simply store all variables that were > > > registered as session varaibles in a file, named after a unique key that's > > > generated by the session starter, and passed along through cookies (I > > > think it'll be fair to rely on cookies, and point people that don't trust > > > cookies to phplib's session support). > > > > The whole mechanism should also allow hooks for user-defined > > retrieval and storage functions, so alternate methods of storing > > the data can be implemented easily. That will be nice for prototyping, > > as well. > > As I said before, the mechanism should not be limited to files. It could be > implemented in such a way that a configuration setting is added in the form of > > handler_name:handler_args > > For example: > > files:/web/server1/session/ > > This could tell PHP to use the specified directory to look for session ids. > > > > > One problem is keeping track of the session key, though. Relying on > > cookies is only okay if you're willing to let people slip through > > the cracks. Otherwise you have to do URL munging and slipping the > > session id in as hidden form data on forms. How does PHPLIB deal > > with this? > > <? $sess->purl("someurl.phtml"); ?> > > That is what I don't like very much: The URLs are adapted by using a function > call which performs some regexes on it and spits it out. This automatically > embeds the session id, if necessary (e.g. in PHPLIB's get mode). > > -- > > Regards, > > Sascha Schumann > Consultant > -- ----------------------------------------------------- Zeev Suraski <zeev@zend.com> For a PGP public key, finger bourbon@netvision.net.il -- PHP Development Mailing List http://www.php.net/ To unsubscribe send an empty message to php-dev-unsubscribe@lists.php.net For help: php-dev-help@lists.php.net