Dominik Huber wrote:
(This mail seems to be lost some where so I take another try.)
Sorry if this was my fault.
Hi Jim,
I cleaned up the locatableadapters-branch, but I did not implement an
additonal locate attribute to the adapter directive yet, because it's
pretty tricky to separate trusted-ness from location-ness.
How so?
I already raised the question what the precedence should be if the
<class...-and-<adapter...-pattern is used within the registration of
trusted adapters.
OK, I'll anser that. If a permission is used in an adapter directive,
it takes precedence over declarations made in a class directive.
(In the future, I'd like to change the way security declarations work
so that, perhaps, they are set on a name-by-name basis. So then,
declarations for names in other interfaces wouldb't be lost when
making a declaration for an adapter to a particular interface.)
Question: What should the precedence be if I use the sample zwiki
registration (modified example above)?
At the moment (trunk) the permission attribute of the <adapter... is
ignored and the permission-set of the <class... is invoked
(experimental verification only).
I couldn't tell you what the precedence should be because I didn't
anticipate that someone would do both.
The precedence is <class... then <adapter... because the
_protectedFactory (used for adapter permissions) does only set the
permission if the adapter does not provide an __Security_checker__
attribute (see also zope.security.checker.ProxyFactory).
I don't see this. The _protectedFactory sets the __Security_checker__
regardless of whether it is already set.
Also making declarations with the class directive does not set
__Security_checker__ attribute on the class.
zope.security.checker.ProxyFactory) checks for __Security_checker__
before looking for class-based declarations.
Therefore we can't use the permission attribute of the <adapter...
directive to switch between locating or none-locating trusted adapter
factories because the permission of the <adapter..-directive. is not
asserted.
Sorry, I don't see this.
Given the above precedence fact, I cannot imagine a way how to resolve
your (Jim's) requirement
'trusted-public-adapters-should-not-be-location-proxied' and the
requirement within a local authentication any permission unless
zope.Public does require location-ness.
For that reason I sugest to stay with the current implementation of the
branch (30225) and cancel the locate-extension.
I think the current proposal is:
1. provide an explicit locate attribute. This should be steaightforard.
2. if a non-public permission was specified, then behave as if a locate
attribute was used. This seems straightforward too.
I don't see what the problem is.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
