--- 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 maybe
> shouldn't be included as an option at all.
>
I would like to control finely the session security mechanisms.
I would like to be able to plug a client-checking (or anything
else). This way, each WebApp developper can discriminate among
its own constraints and risks. I want to be able to use
different ways to secure the session.
For example, ther would be cases where I would implement a
client-checking mechanism based on both IP address and browser
time-limited cookie. This would allow me to follow sessions on
people refusing cookies and on people behind "IP dancing"
proxies. I would loose session state for anyone both refusing
browser cookie and being behind "IP dancing" proxy. This would
be an acceptable compromise if I am manipulating highly private
data.
In other cases, I could accept lower-level security related to
the less privacy.
Godefroid Chapelle
---------------------
BubbleNet sprl
rue Victor Horta 30
1348 Louvain-la-Neuve
Belgium
---------------------------------------------------------------------
This mail sent through SwinG Webmail: http://mail.swing.be
_______________________________________________
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
