On Tue, 2004-09-14 at 21:18, Richard Jones wrote:
On the "proposals" object though, we don't have any delaration for the "secure_url" attribute. If I add one, or a general security.setDefaultAccess("allow"), then the error goes away. This doesn't seem correct to me.
It sure doesn't sound right. Just to be pedantic: You have an object A that has no security assertion for "secure_url". You have an object "B" that does. When you access the aq context a.__of__(b) and ask it for "secure_url" in restricted code, it refuses access. Is that a reasonable characterization or am I reading it wrong?
The relevant change in CVS appears to be:
*** ../../../../Zope-2.7.2/lib/python/AccessControl/ImplPython.py 2004-02-10 17:46:02.000000000 +1100 - --- AccessControl/ImplPython.py 2004-09-15 09:59:41.617423171 +1000 *************** *** 551,560 **** return v
validate = SecurityManagement.getSecurityManager().validate - - # Filter out the objects we can't access. - - if hasattr(inst, 'aq_acquire'): - - return inst.aq_acquire(name, aq_validate, validate) - - # Or just try to get the attribute directly. if validate(inst, inst, name, v): return v raise Unauthorized, name - --- 551,556 ----
The change note being "- Removed DWIM'y attempt to filter acquired-but-not-aceessible results from 'guarded_getattr'." and I'm not sure what that means :)
I'm sure there was a case that provoked this checkin but I think we'd need to ask Tres what it was (and see what he thinks about its results). - C