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:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
