I don't understand the pushback against location proxying security-proxied objects. LocationProxy does actually play well with security-proxied objects.
-- Garrett Dominik Huber wrote: > Jim Fulton wrote: > >> Dominik Huber wrote: >> >>> A few months ago the following code block was removed in >>> editview.py, editwizard.py and schemadisplay.py (revision 29418): >>> >>> def _setUpWidgets(self): >>> adapted = self.schema(self.context) >>> if adapted is not self.context: >>> if not ILocation.providedBy(adapted): >>> adapted = LocationProxy(adapted) >>> adapted.__parent__ = self.context >>> self.adapted = adapted >>> setUpEditWidgets(self, self.schema, source=self.adapted, >>> names=self.fieldNames) >>> >>> As a consequence each trusted adapter class should now implement >>> ILocation >> >> >> One could, as an alternative, use an non-trusted adapter >> that is public and rely on the underlying object protection. > > We can only use trusted adapters for our use case. > >> >>> that the TrustedAdapterFactory can set the location of adapter >> >>> instances correctly. Otherwise, only the global authentication is >>> involved and the edit view fails if any local principal tries to >>> edit a certain field (security.canWrite(source, name) in >>> zope.app.form.utility line 207). >>> >>> I would like to revert those changes. IMO a framework like the form >>> framework knows the context (location) and adapts that context to a >>> certain schema. If the following procedures depends on location >>> information, the framework itself should pass such informations in a >>> smart way. It's an unnecessary >>> <se?lp=ende&p=/Mn4k.&search=unnecessary> expense >>> <se?lp=ende&p=/Mn4k.&search=expense> to force all schema adapters >>> to implement ILocation: >>> >>> - The solution using the location proxy seems fairly famillar >>> compared with the container framework and containment that does not >>> provide ILocation. >> >> >> Except that the object being location proxied is already security >> proxied. Location proxies were not designed to proxy >> security-proxied objects. > > Theory: > I cannot assess this location-proxied securtiy proxy issue. Therefor I > have a question about the order of containment proxies: > 1. contained proxy > security proxy > component > 2. security proxy > contained proxy > component > So far I thought a component is created and proxied by their factory, > afterwards it is contained proxied by the container if it does not > provide ILocation. Therefor my statemets bases of 1. > > So for me it is not very obvious what the difference should be between > location proxied containement and location proxied trusted adapters: > location proxy > security proxy > trusted adapter > > Practise: > The form framework does not work using trusted adapters which do not > provide ILocation in combination with the local authentication > information. This raises an Unauthorized exception if a local > principal with enough privileges tries to access the edit view. > (Reason: Because the unlocatable adapter invoke the global > authentication only). > > We have three oportunities: > a) status quo > b) location proxy or simalar derivates > c) extend security.canWrite(obj, name, context=None) > d) ... > > History: > Roger removed the location proxy code because at that time the > security information get lost using location proxies (Reason multiple > security proxies: security proxy > location proxy > security proxy > > trusted adapter). Afterward Garret fixed the proxy method of the > Checker class. Since that time proxied object will be only proxied if > their were not already proxied before (location proxy > security > proxy > trusted adapter) > >> >>> - An adapter that implements more than one interface cannot be >>> registered with the implicit adapts and implements informations. >> >> >> True. >> >>> - A regular schema does not extend ILocation therefore it is not >>> obvious to write an adapter implementing ILocation. >> >> >> True. >> > If you answers the last two reasons with True then follows IMO a) is > a bug. > > So we have to choose an other implementation alternative > b), c) or d) would be ok for me. > >>> Any objections? >> >> >> Yes. :) >> >> Why not simply use an untrusted public adapter? > > Use case: > We have within the site 's' an extendable containerish component 'f' > (Class Fasade) that should fasade its containment . Inside 'f' we can > put any component for example component 'any' (Class Any) providing > 'IAny'.The IWriteContainer declaration of 's' requires the permission > 'zope.ManageContent'. The IWriteContainer declaration of 'any' > requires a dedicated permission for example 'zope.ManageInside'. > > Now we should provide an edit-view for 'f' that invokes the contained > component 'any'. The edit-view should be accessable for local > principal of s which have the 'zope.ManageContent' permission. > > Our design goal tries to satify the following two targets: > - demeter's law (No direct access to 'any'). > - different permission between inside and outside 'f' > > So we decided to access 'any' on the location of 'f' using an > AnyForFasade adapter. > IMO this adapter must be trusted to hide inside permission of 'any'. > > Regards, > Dominik Huber _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com