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.
Shane
_______________________________________________
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
