[Zope-CMF] Re: [dev] unresolved site manager related issues

[Alec Mitchell]

On 4/15/07, Tres Seaver <tseaver at palladion.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Alec Mitchell wrote:
> > On 4/15/07, Martin Aspeli <optilude at gmx.net> wrote:
> >> Dieter Maurer wrote:
> >>> Alec Mitchell wrote at 2007-4-12 06:59 -0700:
> >>>> ...
> >>>> ... deprecation of "getToolByName" ...
> >>>> which is that there's no practical reason other than
> >>>> aesthetics to deprecate getToolByName at this point.
> >>> A very good point: let's deprecate deprecations done just for
> >>> aethetical reasons :-)
> >> Aesthetics were not the original reason for moving down this route, so
> >> it's a little unfair to cast it in that light. The main drivers, as I
> >> recall, were to encourage API usage that would allow us to move tools
> >> out of content space eventually, and to make code depending on CMF tools
> >> more consistent with "newer" code which may depend on new utilities (at
> >> least in the Plone world, there is a general consensus that we'd rather
> >> not have any more content-space tools from now on).
> >
> > What is it about getToolByName that implies that tools are in content
> > space?  Consistency with "newer" code is an aesthetic concern as far
> > as I understand it.
>
> Agreed.  I'm fine with having 'getToolByName' issue a deprecation
> warning if the tool can't be found using the component registry, and
> therefore the API has to fall back to acquisition to *find* the tool.
>
> That is a different problem than *wrapping* the returned tool to give it
> place (for security, for forward compatibility, whatever):  if the tool
> implements 'Acquisition.interfaces.IAcquirer', then it *needs* wrapping,
> whether that is done via 'getToolByName', 'five.lsm', or some other
> voodoo-yet-to-be-written.  Failing to wrap objects that expect to be
> wrapped is a major party foul:  in fact, I would class that a
> showstopper for any final release of CMF 2.1.

Yes tools need to be wrapped, because to a great extent their purpose
is to allow use of methods from untrusted (ui) code.  I'm not sure
this pattern really maps well on to the use of utilities in Zope 3,
but it's hard to say since Zope 3 doesn't really seem to have the same
concept of untrusted code.  However, there's

> Utilities that don't expect to be wrapped had better fall into one of
> the following categories:
>
>   - They shouldn't be used by untrusted code at all (i.e,, all their
>     methods are declared private).  Such a utilitiy might be registered
>     as a "policy hook" for some other framework:  note that it would
>     *not* be possibile to *configure* such a utility TTW using "stock"
>     Zope2 ZMI patterns.

Is there currently a way to access a utility from untrusted code?
Aside from CMF's new getToolByInterfaceName method (which is about
wrapped tools not utilities), there isn't AFAIK.  My impression is
that untrusted code should generally be using methods from views
(which could themselves delegate to utilities), not utilities or
non-view adapters which are currently inaccessible  and insufficiently
protected for untrusted code.

Currently, Five doesn't support security declarations on utilities or
adapters at all (I mean global utilities in this case), and I think
the reason is that utilities are generally accessible only from
trusted code.  I understand that this limitation makes it quite hard
to make use of utilities in the way that tools have traditionally been
used.  To me that's just another reason to consider the introduction
of this tool <=> utility equivalence to have been premature.

It may turn out that we need to wrap utilities generally (including
the global ones), but that's something that would need to happen at a
different level than five.lsm.  Many people have made use of global
utilities in Zope 2 and not missed the acquisition wrapping.  Local
utilities shouldn't be any different.  In the end, if we need wrappers
on the local ones, then we should have wrappers on the global ones
too, and we need a solution that capable of providing wrapping for
both.

>   - Or they have no expectation that Zope2 protects them (i.e., all
>     their methods are public).  Such utilities would either perform
>     their own security checks, *using a passed in context object*,
>     or would provide services which did not require any protection.
>
>   - Or some mixture of the two.
>
> Any use of 'security.declareProtected' in the class of the tool mandates
> that the tool be given "place" for Zope2 security purposes, even if
> nothing else needs wrapping.
>
> Trying to come up with an "elegant" way to avoid the necessity of
> wrapping is silly at this point:  it isn't even "better" to try to make
> Zope3-style wrapping (the ILocation stuff) equivalent, because we will
> have to support implementations which don't know or care about Zope3
> indefinitely.

For content objects this is probably of dubious utility, because, as
you say, there will always be implementations around which don't
understand or expect the Zope 3 patterns.  Other components like
views, adapters, and utilities (none of which generally provide
ILocation) would only be accessed from non-legacy code so this concern
doesn't really apply.   However, the conversion of tools into
"utilities" breaks that assumption.

Alec