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).
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -