[Zope3-dev] Form framework, adapters and pau

[Garrett Smith]

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