--- 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 

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 

This mail sent through SwinG Webmail: http://mail.swing.be 

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope )

Reply via email to