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

[Maxim D. <max...@bo...>]

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