(This mail seems to be lost some where so I take another try.)

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.

I already raised the question what the precedence should be if the <class...-and-<adapter...-pattern is used within the registration of trusted adapters.

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).

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.

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.


_______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to