>>> Toby Dickenson wrote
> > Are you suggesting that the session token should actually
> > store session
> > data?
> As an alternative SessionManager, it appears to have some advatanges that
> others do not.
It also has a major disadvantage, if you don't want the users to be
able to monkey wit
--- In [EMAIL PROTECTED], "Chris McDonough" <[EMAIL PROTECTED]> wrote:
> Without a client-checking scheme (such as encoding the IP
address in the
> token), a token theft attack is very easy. As voiced by
others in the
> thread, client-checking is not reliable, should not be a
default, and mayb
>
> > But all of these ponderings are kind of moot, because session
> > data can be
> > arbitrarily large (session data on the order of a megabyte
> > will probably not
> > be uncommon), so the data can't realistically be embedded in the token
> > anyway.
>
> Agreed, in-URL session data is not a u
Chris Wrote:
> yeah, but have you ever tried to have two copies of a tree open on the
> same data?
That problem wouldnt arise if the page containing the tree tag used a
URLDataSessionManager ;-)
A different Chris Wrote:
> Hmmm. Please smack me if I'm wrong, but I'm not clear on how it differ
> > Are you suggesting that the session token should actually
> > store session
> > data?
>
> As an alternative SessionManager, it appears to have some advatanges that
> others do not.
Hmmm. Please smack me if I'm wrong, but I'm not clear on how it differs
much from not keeping session-related d
> Are you suggesting that the session token should actually
> store session
> data?
As an alternative SessionManager, it appears to have some advatanges that
others do not.
It is the only option (AFAIK) that avoids the session hijacking problem
without relying on security-through-obscurity (the
Toby,
Sorry, I'm still not sure I understand. :-(
Are you suggesting that the session token should actually store session
data? Or are you just pointing out the difference between the
implementation an implementation that meets the requirements of sessions
and an implementation adequate for th
> > i.e. it is secure if the key *is* the data, rather than a key to the
> > data.
>
> Can you explain? I do not see what you're getting at.
Consider how the tree-tag stores its 'session' data. Its impossible to
hijack a tree-tag session because the 'session' state is stored by the
client (in
>>> KevinL wrote
>
> Please, please, please, do _not_ use IP numbers to verify it's the same
> connection. You guys don't have the problem in .us, but out here at the
> fringes (.au, and presumably .uk and similar), proxy server use is rampant -
> and leaning on IP breaks, because proxy's sha
Please, please, please, do _not_ use IP numbers to verify it's the same
connection. You guys don't have the problem in .us, but out here at the
fringes (.au, and presumably .uk and similar), proxy server use is rampant -
and leaning on IP breaks, because proxy's share the connection around.
At 05:17 PM 10/2/00 +0200, [EMAIL PROTECTED] wrote:
>
>I was told that some ISP change your IP address during a
>connection but never took the time to check if it is true.
Whether the actual user's IP changes isn't relevant. The question is, can
the IP of a proxy server between the user and you
--- In [EMAIL PROTECTED], Chris McDonough <[EMAIL PROTECTED]> wrote:
> I suppose I could implement something like this (encode the IP
address
> into the token) and provide a knob to turn it on and off on
the id
> manager. I'm not going to do this for the first iteration, I
need to
> get it wor
I suppose I could implement something like this (encode the IP address
into the token) and provide a knob to turn it on and off on the id
manager. I'm not going to do this for the first iteration, I need to
get it working first. :-)
Steve Spicklemire wrote:
>
> I forget now where I saw this...
Dieter Maurer wrote:
> I, at least, care much more about my privacy than about
> some wish list maintained for a longer term.
Sure. That is why you're free to not continually visit sites that
implement this policy.
(and boy are you gonna hit the roof when you read my explanation of why
I change
Chris McDonough writes:
> Dieter Maurer wrote:
> > ... serious privacy concers about long living browser ids ...
> > .
> > This means, if the session lifetime is in the
> > order of an hour, the cookie need not live
> > longer than, say, a day.
>
> Not if you want
> I just read the CoreSessionTracking proposal.
Great...
> I am very concerned about the "long living browser id".
>
> * Why should a browser id live longer than the
> session data maintained for the browser?
Because it's a browser id, not a session id. This terminology may change in
lat
16 matches
Mail list logo
