Re[2]: [Phplib-users] new Session4 changes
Brought to you by:
nhruby,
richardarcher
From: Maxim D. <max...@bo...> - 2002-12-02 12:05:35
|
Здравствуйте, Giancarlo, G> It supposes that in any moment, header problems apart, you can create a G> new session, and then start it. This is what actually is missed in php4 G> session. We could keep this pieces of code, because the php4 session G> module is afterall an 'optional' module. And phplib's code is known to G> work for years, and gives a better control, so I'dnt throw it away so G> mindlessly. The old PHPLib's Session class is damn slow compared to the native PHP4 sessions. So, In My Considered Opinion, there is no way back to the "PHPLib for PHP3" Session class usage, it is just the history now. And the only reason to use Session class *interface* instead of using PHP's session functions explicitly is the nice abstraction, just like a "control panel" for tuning the module parameters, cause the module is quite complicated and confusing for the unexperienced users. 1. The check for session existence is trivial. In my addition to the Session4 the session exists if the originator's IP is registered with the session. If we have a SID in the request and don't have *any* IP in the session, the session does not exist, so the SID should be omitted and the new session with the new random SID should be emitted. 2. We should always try to avoid extra redirects - the main reason is that those redirects can be misunderstood by the search robots, and the site will not be properly indexed. 3. We should do something so that session hijacks could be made [almost] impossible. The old Session class has the same issue and the session can be hijacked using both PHPLib's Session3 and PHP4 session module weaknesses. The only way I see is to bind the session under some circumstances to a marker that can not be forged. The only such a marker I see is the user's IP address - the others can be easily rewritten in the request variables. Given that the cookie is one of the hardest thing to forge (just because the nature of the attack - the attacker tries to persuade the victim to click an URL), we can ease the restrictions for cookie users. So, the site with such restrictive policy could recommend cookies to everybody and enforce cookie usage by all users that may change their IP during the 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 |