RE: Re[4]: [Phplib-users] new Session4 changes

[Rob H. <rob...@ws...>]

> -----Original Message-----
> From: php...@li...
> [mailto:php...@li...]On Behalf Of Maxim
> Derkachev
> Sent: Monday, December 02, 2002 11:01 AM
> To: Rob Hutton
> Cc: php...@li...
> Subject: Re[4]: [Phplib-users] new Session4 changes
>
>
> RH> I'm not following.  If the session doesn't have an IP then
> it's not valid?
> Right, it's not valid since it doesn't "exist" yet (in case when we
> always save client's IP, with every request). If we have a SID, but
> the session, associated with the SID is empty (or, at least, does not
> contain an IP, which should be there), than the most probably that the
> SID was hand-crafted or obsolete (the new session is born
> automatically), so we trash this SID and issue a new one, with a new
> session.

But either the session is valid, which means it is going to have an IP
because the session setup puts it in, or it does not exist.  There will
never be a situation where the session exists without an IP.  Unless you are
only going to put in the IP in the case of PUTS and GETS, but what happens
when you change modes?

>
> RH> What if the IP doesn't match? Is it invalid also?
> This depends on your policy. I suppose, the "less evil" would be to
> close the session if the SID comes from anything but the cookie (we
> have 4 sources for SID in PHP). Cookie-enabled clients won't suffer.
> But the right way is of course to make this behavior turned on/off as
> desired.

The less evil way would be to ignore the mismatch and keep going, which will
soon be almost a requirement.

>
> RH> Most search tools ignore redirects as well as javascript, etc.  We are
> RH> talking about protected sites that people do not want indexed
> anyway.  If
> RH> they were for public consumption, then there would be no need
> to protect
> RH> them.
> Wrong. Tell this to Amazon :) The public sites must be protected, if
> they are not going to loose their clients.
>
> RH> There is no good way of addressing this.  There are many
> papers, etc. on
> RH> doing so, but they are all at the protocol level and involve the user
> RH> posessing a personal key signed by a trusted third party.  When DNSSec
> RH> becomes more widely deployed, then there will be a reasonable
> way of doing
> RH> something, but not until then.
>
> We live just now. And when somebody can snoop into your personal
> details without any serious effort, the problem should be solved.
>
> RH> As it stands now, if the client has cookies enabled, then
> there is a fairly
> RH> secure way of tracking them.  If not, there is not a
> secure/reliable way.
> RH> That is the whole reason cookies were invented.  To store
> bits of data on
> RH> the client's machine because there was no reliable way of
> tieing it to them
> RH> next time.  How are you going to handle HP, which has a whole
> class B block,
> RH> but also has several thousand IPs behind masquerading machines.
>
> I do know about proxies and masquerading. I also know that a dialup
> users often receive a different IP after reconnect. But we should