[Zope3-dev] Form framework, adapters and pau

[Jim Fulton]

Dominik Huber wrote:
> Jim Fulton wrote:
> 
...
> How can I ask for trusted adapters explicitly inside a framework such as 
> edit view?

You can't.

> If we adapt a context to a certain schema (given by the schema attibute 
> of the editform directive) we have no chance today to ask explicitly for 
> a trusted adapter but rather we get either an untrusted or a trusted 
> one. So if we don't like to end up in the status-quo-bug we have still 
> to handle unlocatable untrusted adapters someway.

Whether something is trusted or not is an implementation decision of the
adapter.

...

>> I would strongly discourage the use of untrusted adapters that
>> require a permission other than zope.Public.
> 
> 
> Then we should not allow to set the permission attribute in the adapter 
> directive ;)

But *sometimes*, it's necessary.

> But I use the permission attribute registering multiadapters (views) all 
> the time, what's the problem there? I'm not aware of any problems.

That's because the BrowserView base class provides ILocation and
the view-lookup machinery sets __parent__.  The high-level view
directives use this base class.

> The zope.Public permission is within all our use cases no alternative.

Not within all, but if an adapter *only* provides logic, then it's better
IMO to rely on the underlying object protections.

>> In general, adapters are rarely accessed from untrustes code
>> and are rarely security proxied.  I would not want to location
>> proxy them in general.
> 
> 
> Yup.
> But my problem is the implicite behavior of the adapter interfaces. IMO 
> we still end up in code like the following
> ...
> adapter = IAnyInterface(context)
> if not ILocation.providedBy(adapter):
>    locatable_adapter = LocationProxy(adapter)
>    locatable_adapter.__parent__ = context.__parent__
>    locatable_adapter.__name__ =  context.__name__
> else:
>    locatable_adapter = adapter
 >
 > doAnyLocationSensitiveProcedure(locatable_adapter)
 > ...
 >

In this example, the adapter won't be proxied unless either
the example code is untrusted, which I assume is not the case,
or the adapter is a trusted adapter.  If the adapter is trusted
and we arrange for all trusted adapters to be locations, then the
extra code should not be necessary.  (BTW, the __name__ assignment
above is pointless.)

> IMO all permission related stuff is possibly location sensitive stuff, 

In practice yes.  This is because current security policies use
location to look up grants.

> therefore the 'real' criteria must be this permission issue and not the 
> trusted/untrusted-issue.

Except that the two are linked.  Trusted adapters provide a way
to deal with adapter security.  Most adapters should not be protected.
The only adapters that should be protected are trusted adapters and
adapters that access sensitive external resources. The vast majority
of adapters don't fit into either of these categories.

> IMO the optimum of explicitness would be reached using only a location 
> helper function such as assertLocation(). We should resign our plans to 
> modify the trusted adapter factory using location proxies if not 
> ILocation is provided by the adapter, because those arrangements do not 
> solve the problem really, as long as we have to differ adapters in 
> relation to their location behavior.

Sorry, I can't make out this translation. :)

> from zope.app.location import assertLocation
> 
> locatable_adapter = assertLocation( IAnyInterface(context))
> doAnyLocationSensitiveProcedure(locatable_adapter)

That's fine.  Of course, it isn't really adapter specific.


>> Yes, we don't want to do this most of the time.  It makes sense IMO,
>> to use them for trusted adapters, but I consider trusted adapters to
>> be a fairly specialized (and useful) tool.
>>
> That would be strengthen the location helper function, too.

So are you agreeing with the proposal to add location proxies
in the adapter factory and not in the form machinery?

> 
> Summary:
> ----------
> I try to collect + and -:
> 
> location helper function:
> + Performance: We don't have to build location proxies all the time
> + Explicitness: Excplicit in relation to the location issue after adaption
> 0 Developer: Have to be aware of the location issue
> 
> assert a location to all trusted adapters:
> 0 Performace: Ok because only the trusted adapters are affected
> - Explicitness: Implicit in relation to the location issue after adaption
> 0 Developer: Have to be aware of the location issue
>
> assert a location to all trusted adapters:

Did you mean "all adapters"?

Jim

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