[z3-five] Templates in views and path expressions

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Aspeli wrote:

>>>   - ViewPageTemplateFile's in a browser view are doing restricted, 
>>> rather than unrestricted traversals
>> This is becuase
>> 'Products.PageTemplates.Expression.createTrustedZopeEngine' only trusts
>> 'python:' expressions;  path traversal is still governed by
>> 'boboAwareZopeTraverse', which uses 'restrictedTraverse'.
> 
> That's bad, isn't it?
> 
>>>   - The <require /> directive doesn't seem to work properly on simple 
>>> properties
>> Your context object somehow has no acquisition wrapper, and therefore
>> cannot be verified by Zope's acquisition-based security policy.
> 
> Strange; it derives from CMF's PortalFolder (and a few other things), so 
> it should be acquisition-aware, and I'm invoking the view via normal 
> traversal.
> 
> What is telling you that there's no aq wrapper, specifically?

The check for 'aq_inContextOf' is failing;  that method is defined in C
for acquisition wrappers.  Could you be running into a case where the
context is actually tuple-ified to prevent wrapping it in the view?  I
think that is an AT thing, but don't recall for sure.

>>> Are these bugs? Are my expectations unreasonable? What are the 
>>> consequences of not having a <class> directive setting permissions on 
>>> the content type?
>> Applications which don't expose their objects to TTW-modifiable code can
>> safely leave those declarations out;  in fact, all the Five-based apps I
>> have worked on do this, as they don't permit "skinning" or
>> "customerization".
> 
> Right. I'd still prefer to have it in, though. :)
> 
> I'm also uear what the effect of base classes (e.g. PortalFolder) 
> doing their own ClassSecrityInfo is on my own derived type, if my 
> derived type uses neither ClassSecurityInfo directly, nor a <require /> 
> ZCML statement.
> 
>> We had a similar exchange about three weeks ago on the subject, 'ZCML
>> security declarations and properties'.  I conceded then, through
>> failutre to read carefully enough:
> 
> Ah yes, I knew there was a reason I had deja-vu :(
> 
>>> You are correct that the VPTF is trusted code -- my bad.
>> As it turns out, it is only "partially trusted."  The attached patch
>> should make them "really trusted", at least for path expressions;  does
>> it help?  I haven't added any tests, although my 2.10 branch checkout
>> does pass all tests with this change.
> 
> It seems to me that being "not fully trusted" is a bug, so I'd be very 
> happy if this went in!

Does the patch fix your problem?  I refactored the tests for the
Expressions module last night to allow up to write tests for the
security semantics of both the trusted and the regular engines, but
don't want to go further unless the patch fixes you issue.

> I assume this only impacts ViewPageTemplateFiles and not regular 
> TTW/skin layer Page Templates?

RIght:  the only client of 'createTrustedZopeEngine' is
Products.Five.browser.pagetemplatefile.  It is arguable that the normal
PageTemplateFile should use this engine as well;  for BBB, we'd probably
have to expose it as an option to the PTF construtor, and then cahnge
the default from untrusted to trusted after a couple of releases.


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGPze4+gerLs4ltQ4RAoNEAJ9w4RakOTcIJkNkiSiGpZ0KGlm4zQCaAy8Y
XX4t96r1Egj/Z6xRplgIvDA=
=P9M/
-----END PGP SIGNATURE-----