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

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. 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 Fulton           mailto:[EMAIL PROTECTED]       Python Powered!
CTO                  (540) 361-1714  
Zope Corporation
Zope3-dev mailing list

Reply via email to