Rp.: Re: Rp.: Re: [Phplib-users] Sessions where are we going??

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

 Donncha O Caoimh <don...@tr...> a écrit le  2/7/02 9:59:

>I explained my idea to John 
>here at work and he said 
>much the same thing. In 
>that case we put a timer in 
>there and update the key 
>every X 
>seconds/minutes/hours or 
>something.
>

this supposes that any browser window shares the same cookie.
I am using Netscape, and it does, but I heard IE might do not.

>I just did a little experiment. 
>I reloaded a page that uses 
>php4 sessions 
>through phplib and did an ls -l 
>/tmp to see if the session 
>file was updated. 
>The file was, so it doesn't 
>matter how often you 
>update the key, the session 
>file is written out (either 
>that or the file is touched by 
>php4.. can anyone 
>shed any light on that?) 

people dream predictably stable solution that sulevate them from the duty of having to shed any light.
That's why they love PHP4 sessions and prefer to ignore anything seriously wrong with it.

>Next thing is to put those 
>session files on a ram drive :)
>
>I think it's probably an idea 
>worth looking at, does 
>anyone else 
>agree/disagree/care?
>
>Donncha.
>
>
>On Monday 01 July 2002 
>17:48, Giancarlo wrote:
>>  Donncha O Caoimh 
><donncha.ocaoimh@tradesig
>nals.com> a écrit le  1/7/02 
>14:23:
>> >Just a thought for an 
>extra
>> >layer of protection for 
>the
>> >user:
>> >The first time the user 
>visits
>> >the site we set a cookie 
>on
>> >their browser with
>> >some very random 
>number
>> >as the key. Store the 
>value
>> >of the key in the
>> >session.
>> >Each time after that 
>modify
>> >the key, set the cookie, 
>and
>> >store it in the
>> >session.
>>
>> That would be heavy on 
>the server. Imagine a 
>multi-frame where each 
>tries
>> to lock&write in very rapid 
>sequence... Maybe  ok for 
>terminal like
>> screens, tellers, mono 
>thread slow stuff.