RE: Re[2]: [Phplib-users] new Session4 changes

[Rob H. <rob...@ws...>]

	If what you are saying is that there should be a session save handler that
simply abstracts the internal php4 session stuff then I would agree.  If
what you are saying is that is should be the only option, then I disagree.
There are several reasons for implementing variable persistence outside of a
core library that you really cannot rewrite without getting into trouble.
The most basic of which is that you have several options on how to store
session variables.  Not to mension, the ability to do preprocessing before
freezing, having access to the session from a database, performing data
capture on sessions for logging purposes, etc.  Sometimes, speed is not
everything.

Rob Hutton
Web Safe
www.wsafe.com

**********************************************************************

Introducing Symantec Client Security - Integrated Anti-Virus,
Firewall, and Intrusion Detection for the Client.

Learn more:
http://enterprisesecurity.symantec.com/symes238.cfm?JID=2&PID=11624271


> -----Original Message-----
> From: php...@li...
> [mailto:php...@li...]On Behalf Of Maxim
> Derkachev
> Sent: Monday, December 02, 2002 8:31 AM
> To: Giancarlo
> Cc: php...@li...
> Subject: Re[2]: [Phplib-users] new Session4 changes
>
>
> You talk about implementations, while I pointed out the overall
> session strategy limitations. The *implementations* You mentioned use
> the same basics, the main of them is HTTP, which is unreliable,
> because of it has no *internal* state handling - cookies were invented
> to help but they don't always function, as we know. If the HTTP
> protocol had its internal session handling, there would be much less
> buttache to make the session work reliably and secure. And there could
> be 1000+ session implementations in PHP, but all they would be like
> twins from the network point of view. That's why the most of them
> would act
> just like backends for the standard PHP session module - just like
> another savehandler - because nobody wants to reinvent bicycles. All
> the logic needed to implement state propagation has been already coded
> there. And weaknesses and unreliability is in the heart of the whole
> system - HTTP. the PHP core guys could make the module to check
> whether the
> SID already exists before starting a new session and many more, but
> the performance and/or flexibility would suffer, so they preferred to be
> wise and leave the exact implementation of security constraints
> to the users.
> And every descent session module, even if it will use its own
> start() and SID propagation logic, will face the same dilemma.
> Something tells me that the good extensions will go the standard way.
>
>
> G> Look, now there the msession module that seems to suit different needs.
> G> There may come others. That is in fact just one of many
> session modules,
> G> and with some tight-tied constraints. If you canno't have ir
> regenerate
> G> into a new session, most mutancy, which means flexibility, is lost. I
> G> saw a php SOAP php module on sourceforge that first and only things it
> G> does is session.
>
>
>
>
>
> --
> Best regards,
> Maxim Derkachev mailto:max...@bo...
> IT manager,
> Symbol-Plus Publishing Ltd.
> phone: +7 (812) 324-53-53
> www.books.ru, www.symbol.ru
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users
>
>