[Zope3-checkins] SVN: Zope3/trunk/src/zope/app/security/_protections.py The code in this module worked for tests but was broken for actual Zope instances. This caused Messages to be security proxied, which can cause surprising and undesirable effects. Fixed with the most obvious hack around the problem, but this is not ideal. There was a discussion earlier on how to fix this the 'right' way; using an artifact of our testing framework to bootstrap a zope instance, as I am doing here, is not acceptable for a release. A revert to the previous (broken for tests, but with a workaround) behavior would be preferable than using _clear.

[Stephan Richter]

On Wednesday 26 October 2005 17:31, Gary Poster wrote:
> Changed:
>   U   Zope3/trunk/src/zope/app/security/_protections.py
>
> -=-
> Modified: Zope3/trunk/src/zope/app/security/_protections.py
> ===================================================================
> --- Zope3/trunk/src/zope/app/security/_protections.py   2005-10-26 21:26:52
> UTC (rev 39657) +++
> Zope3/trunk/src/zope/app/security/_protections.py   2005-10-26 21:31:04 UTC
> (rev 39658) @@ -37,6 +37,9 @@
>      zope.security.checker.BasicTypes[MessageID] = NoProxy
>      # this, however, is not a security hole, because Messages are
> immutable. zope.security.checker.BasicTypes[Message] = NoProxy
> +    zope.security.checker._clear() # XXX The BasicTypes approach requires
> +    # _clear be called.  This is not a good idea.  This should be
> addressed +    # before release.

Why do we need _clear() here? This does not make sense. _clear() does nto 
affect BasicTypes at all.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training