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

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

G> PHP4 Serialization and URL rewriting (trans_sid) are valuable indeed, 
G> file savehandler could be accomodated, but propagation is faulty and 
G> has no abstraction and is rigidly tied to all the rest. As I said, if I 
G> could choose pieces of it...

The propagation is faulty but I don't see the way to make it better
(remember, it should be *generic*).
The session start, read, save and propagation (url rewriting is only
part of the propagation mechanism) methods are pretty abstracted, they
deal with an abstract savehandler and serializer.
That's why the module itself does not have any means to know whether the
session already exists before actually starting it - the module will have
to dig into savehandler - so the abstraction will leak. So, in this
case, all the savehandlers should implement this logic. Don't mention
that this check can raise performance problems.
We can check if the session exists using a marker. It can be simple
boolean value - e.g. $_SESSION['session_active']. I just used
REMOTE_ADDR instead of boolean marker in order to save an extra info
about the session, to use it in the anti-hijack part. But we may do
such things in a library only - if we introduce the new predefined
internal global/session variable in the core part of the PHP system,
it can break someone's applications because of the naming conflict.
That's why the module don't check for session existence, just issues a
new one with the SID it gets from one of the predefined sources.
So, the propagation is not so faulty - it is generic and clearly
abstracted from other parts.


G> I meant the 'second half' can be used only once and must be chosen among 
G> a fair enough batch of pregenerated ones.

I don't follow you here ... How this can harden the session security?


-- 
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