[Zope3-dev] Form framework, adapters and pau

Jim Fulton jim at zope.com
Wed Apr 6 09:24:40 EDT 2005


Dominik Huber wrote:
> Jim Fulton wrote:
> 
>> Here's an alternate proposal:
>>
>> Let's put the proxying in the trusted adapter factory.
>>
>> Let's make the trusted adapter factory add the proxy
>> if the adapter doesn't set ILocation. Then the form code
>> stays clean and other code will benefit.  This would become
>> part of the definition of trusted adapters.
>>
>> If there are no objections, let's do it this way.
> 
> 
> +1
> It's a positive convergence from adapters and content components.
> 
> - 1
> It might be a trap too, because developers must be aware of the pretty 
> implicit differnces between trusted and unstrusted adapters.

We just need to make this explicit.

We already "implicitly" set __parent__ in the trusted adapter
factory. I suggest we make this explicit.  If you ask for a trusted
adapter, then we'll set __parent__ on the adapter to the adapted object,
adding a location proxy, if necessary.

 > In cases
> where unstrusted adapters require a dedicated permission the editview 
> has still to proxy those adapters to procede correctly. Would it be 
> possible to deprecate the unstrusted adapters or proxy them to?

I would strongly discourage the use of untrusted adapters that
require a permission other than zope.Public.

In general, adapters are rarely accessed from untrustes code
and are rarely security proxied.  I would not want to location
proxy them in general.

> Question:
> Then we have to build location proxies most of the time. Is that not a 
> performance issue?

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.

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


More information about the Zope3-dev mailing list