Re: [Phplib-users] new Session4 changes | more

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

> Currently the logic in the session module (php3) was:
> 
> if there is no cookie, see if there is a GET sid
>   if there is a get sid, accept that anycase

       +++ create or update the session

>   if tgere's not a GET sid, append a GET sid, leave a cookie as well,
>       redirect to Self (with sid appended). On reentering, it is back to 
>       start

       +++ no session creation was made if nothing found, just the
           redirect


So the base for checking the preexistance was to create & save, in case 
a new session, BEFORE redirect, not create_or_update AFTER, as it was

What is really good in php4 session is the URL rewriting ;-)
that is something I would like to have built in, but I am not sure one 
can wedge PHPLIB's propagation code (so a custom session_start ?), use a 
custom_savehandler for storage (is it possible without a session_start 
?), and still use the PHP4 url_rewrite feature..

Gian






> 
> The logic I applied to somehow block the aliens was:
> 
> if there is no cookie see if there'a a GET sid
>   if there's a GET sid, see if that exists
>     if that no exists, create&freeze a new session, leave the new
>        cookie, append sid to GET, redirect to there
>   if there's no GET sid, ceate&freeze a new sess, append sid to GET and
>      leave a cookie, and redirect to there
>  if there's cookie, see if it exists, if not: recookie, redirect to self
> 
> 
> It supposes that in any moment, header problems apart, you can create a 
> new session, and then start it. This is what actually is missed in php4 
> session. We could keep this pieces of code, because the php4 session 
> module is afterall an 'optional' module. And phplib's code is known to 
> work for years, and gives a better control, so I'dnt throw it away so 
> mindlessly.
> 
> 
> Maxim Derkachev wrote:
> 
>> Hello Rob,
>>
>> Saturday, November 30, 2002, 1:07:46 AM, you wrote:
>> RH> Currently, if cookies are not set, then you just append the 
>> session id to
>> RH> the get string.
>>
>> Well, I know that. But it does not resolve the session hijack issue.
>>
>>
>>
> 
>