[Zope3-dev] Form framework, adapters and pau

[Jim Fulton]

Garrett Smith wrote:
> I don't understand the pushback against location proxying
> security-proxied objects. LocationProxy does actually play well with
> security-proxied objects.

That was not our experience in the recent past.  I'll have to document
the problems, assuming that I can reproduce them.

I wonder if it would make sense for the trusted adapter machinery to
simply set __parent__ on adapters if either the adapter provides ILocation
*or* the adapter doesn't already have a __parent__.  This would solve the
problem and avoid the proxy.

Jim

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


-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org