Shane Hathaway <shane@zope.com> wrote:

sean.upton@uniontrib.com wrote:

...

Personally, I think this really should be an integration issue instead of a Zope issue: use a front-end proxy server (i.e. Squid) and set up ACLs to prevent this...

This hasn't been fixed because it's not well understood. Javascript can POST an invisible form, AFAIK. The problem occurs on the browsers of users who are *already authenticated*. It has nothing to do with Zope or any server software, really.

I recently saw a _very_ interesting description of how capability-based distributed computing (and the Principle of Least Authority) is used to address vulnerabilities to client side trojans, viruses, etc. I think the approach may apply to the web situation. "Capabilities" are a signficant, fairly established idea in the realm of distributed operating systems, but are not very familiar more generally. This description is by far the most approachable i've seen (and perhaps, the first i've understood:) - i highly recommend looking it over. It's in a substantial overview of the very nifty looking scripting language, E, which is specifically designed to provide secure, reliable, manageable distributed computing scripting. The relevant bits are at: http://www.skyhunter.com/marcs/ewalnut.html#SEC41 A page or two down it describes the ramifications for things like computer viruses, if you want to skip straight to the punch. That part doesn't quite capture the way i expect we would use it to address the client-side trojan problem. Offhand, i suspect we could use these principles with Zope cookies and capability-specific roles. This approach provides a means for implementing something along the lines that chris petrilli was suggesting a while back, with incremental, rather than either/or, role privileges. Ken klm@zope.com