Re: [Phplib-users] new Session4 changes

[Giancarlo <gia...@na...>]

Look, now there the msession module that seems to suit different needs.=20
There may come others. That is in fact just one of many session modules,=20
and with some tight-tied constraints. If you canno't have ir regenerate=20
into a new session, most mutancy, which means flexibility, is lost. I=20
saw a php SOAP php module on sourceforge that first and only things it=20
does is session.


Maxim Derkachev wrote:
> =C7=E4=F0=E0=E2=F1=F2=E2=F3=E9=F2=E5, Giancarlo,
>=20
> G> It supposes that in any moment, header problems apart, you can creat=
e a
> G> new session, and then start it. This is what actually is missed in p=
hp4=20
> G> session. We could keep this pieces of code, because the php4 session=
=20
> G> module is afterall an 'optional' module. And phplib's code is known =
to=20
> G> work for years, and gives a better control, so I'dnt throw it away s=
o=20
> G> mindlessly.
>=20
> 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.
>=20
> 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.
>=20
>=20
>=20