Jamie Heilman wrote:
Paradoxically, by ignoring Zope's security framework in the context of
on-disk methods this actually improves Zope's overall security.

I can see that. It's interesting that when security is burdensome, it is often less secure overall as a result. I see this pattern everywhere.

So here's the questions I have for you all... is there a way to
declare appropriate security on the bindings that are screwing me
right now from within my product code so that I can selectively poke
holes to allow container access where needed, or am I to be forcibly
coerced into exposing my object to restricted code?  And two, assuming
I haven't overlooked some detail about why forcing PageTemplateFile to
work within the calling security context is a good thing...  Shouldn't
we fix PageTemplateFile to work like DTMLFile wrt security?  How hard
is it going to be to do that?

There certainly ought to be a way to create an unrestricted PageTemplateFile, though it should be an explicit step.

To do this, I would change Products/PageTemplates/Expressions.py. It creates an expression evaluation engine and adds expression types to it. It chooses the unrestricted or the restricted expression types based on whether the "Zope" module exists. This is a wart. Instead, I think it should create two engines, one restricted and one unrestricted. Then you should be able to tell the PageTemplateFile constructor which engine to use.


Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Reply via email to