Re: [Zope-dev] Allowing python logging from restricted code
Hi Jim, Jim Fulton wrote: I think you need to be very careful with this. What's the concern? I'm, at most, planning on making the getLogger function and the top level logging constants (eg: logging.INFO, etc) available... IMO, this is something that should not be turned on by default. OTOH, I have no problem with making this possible to turn on. zope.conf option? Also, do you have any comment on the second half of my proposal, which was to do with making it possible to define more than just event and access logs in zope.conf? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] Re: [Zope-Checkins] SVN: Zope/trunk/lib/python/Shared/DC/ZRDB/ Collector #556: sqlvar now returns 'null' rather than 'None'.
Andreas Jung wrote: IMO there is no need to ship the Zope core with *any* DB package except the ZODB. I dunno, it's very handy to be able to rely on something RDB-like being installed when you want to tests things like ZSQL methods... cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
RE: [Zope-dev] Allowing python logging from restricted code
We are currently finishing up a debug_log much like the error log that Python scripts can write too. We would happily make that source available if you think it will fit the bill. Cheers, Tim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Withers Sent: Tuesday, October 11, 2005 2:50 AM To: [EMAIL PROTECTED] Cc: zope-dev Subject: Re: [Zope-dev] Allowing python logging from restricted code Hi Jim, Jim Fulton wrote: I think you need to be very careful with this. What's the concern? I'm, at most, planning on making the getLogger function and the top level logging constants (eg: logging.INFO, etc) available... IMO, this is something that should not be turned on by default. OTOH, I have no problem with making this possible to turn on. zope.conf option? Also, do you have any comment on the second half of my proposal, which was to do with making it possible to define more than just event and access logs in zope.conf? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org 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 ) ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
[Zope-dev] Re: RestrictedPython, TALES Expressions and CMF
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sidnei da Silva wrote:
(sorry for the cross-post)
I'm currently facing an issue that seems to be a result of a bad
interaction between CMF, TALES and Restricted Python.
The issue currently happens when:
1. A TALES 'Path Expression' in 'Caching Policy Manager' is evaluated
2. The result of evaluating a sub-expression is a Python Script (eg:
object/modified where 'modified' is a Python Script)
3. The context as built by CMF doessn't define 'here'
What happens in this case is that the call will end up in
PageTemplates/ZRPythonExpr.py:call_with_ns, which is reproduced here
for your pleasure:
def call_with_ns(f, ns, arg=1):
td = Rtd()
td.this = ns['here']
td._push(ns['request'])
td._push(InstanceDict(td.this, td))
td._push(ns)
try:
if arg==2:
return f(None, td)
else:
return f(td)
finally:
td._pop(3)
'call_with_ns' should be invoked only for objects with either a
'__render_with_namespace__' attribute (PythonScripts fit here) or those
with 'isDocTemp' true. Its only real purpose is to set up the namespace
before calling a DTMLMethod; I don't even understand why PythonScripts
have such a method.
I'm guessing that you get to this point via CMFCore.Expression's
__call__ method, which calls a compiled path expression.
Now, given that there has been a decision of deprecating 'here' in
favor of 'context', I'm not exactly sure about the fix.
CMF seems to create expression contexts in two places off the top of
my head: In 'CMFCore/Expression.py' and
'CMFCore/CachingPolicyManager.py'. None of those define 'here' or
'context' but instead just 'object'.
In 'Products/PageTemplates/TALES.py', in the 'translate' function,
'here' is also hardcoded, but that should be less of an issue as code
reaching into that function *should* have a proper expression context.
'here' is *never* the proper key to expect; I would class that a bug.
The question then is, which code is wrong? PageTemplates for relying
on 'here' being defined, or CMF for not defining 'here'? I volunteer
to provide a fix with tests as soon as someone clarifies which one
needs to be fixed.
The 'call_with_ns' bit is *definitely* the wrong code path for
PythonScripts, which should be simple callables (I think). I think
PythonScripts get their '__render_with_namespace__' attribute by way of
'Shared.DC.Script.Bindings', which is only in order to support a really
*goofy* use case (being able to get at the DTML '_' namespace when it is
bound). I would be willing to bet that *nobody* does this who actually
needs it.
If we *must* go through that path, then the 'call_with_ns' code needs
to be hardened two ways:
- It should prefer 'context' to 'here' ('here' is deprectated in
Zope).
- It should be willing to supply 'None' if the 'context'/'here' keys
are not present in the namespace.
As a reminder, 'actions' as defined by 'portal_actions' tool and
anything that derives from 'ActionProviderBase' suffer from the same
issue.
We could work around the issue in the CMF by supplying a (temporary,
deprecated) 'here' key in the context we create. The problem with Zope
assuming that 'here' or 'context' are mandatory namespace keys is that,
in our case, we have multiple candidates for the role, and therefore
wish to use unambiguous name.
Tres.
- --
===
Tres Seaver +1 202-558-7113 [EMAIL PROTECTED]
Palladion Software Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDS7bg+gerLs4ltQ4RArczAJ47bJIYNRFb40klCPDJBuuXSgJjgQCgh85v
c9al2avb9+rBcqP2GiQIfqw=
=uIWu
-END PGP SIGNATURE-
___
Zope-Dev maillist - Zope-Dev@zope.org
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 )
[Zope-dev] Re: [Zope-CMF] Re: RestrictedPython, TALES Expressions and CMF
On Tue, Oct 11, 2005 at 08:58:08AM -0400, Tres Seaver wrote:
| 'call_with_ns' should be invoked only for objects with either a
| '__render_with_namespace__' attribute (PythonScripts fit here) or those
| with 'isDocTemp' true. Its only real purpose is to set up the namespace
| before calling a DTMLMethod; I don't even understand why PythonScripts
| have such a method.
|
| I'm guessing that you get to this point via CMFCore.Expression's
| __call__ method, which calls a compiled path expression.
That is correct.
| Now, given that there has been a decision of deprecating 'here' in
| favor of 'context', I'm not exactly sure about the fix.
|
| CMF seems to create expression contexts in two places off the top of
| my head: In 'CMFCore/Expression.py' and
| 'CMFCore/CachingPolicyManager.py'. None of those define 'here' or
| 'context' but instead just 'object'.
|
| In 'Products/PageTemplates/TALES.py', in the 'translate' function,
| 'here' is also hardcoded, but that should be less of an issue as code
| reaching into that function *should* have a proper expression context.
|
| 'here' is *never* the proper key to expect; I would class that a bug.
Bingo.
| The question then is, which code is wrong? PageTemplates for relying
| on 'here' being defined, or CMF for not defining 'here'? I volunteer
| to provide a fix with tests as soon as someone clarifies which one
| needs to be fixed.
|
| The 'call_with_ns' bit is *definitely* the wrong code path for
| PythonScripts, which should be simple callables (I think). I think
| PythonScripts get their '__render_with_namespace__' attribute by way of
| 'Shared.DC.Script.Bindings', which is only in order to support a really
| *goofy* use case (being able to get at the DTML '_' namespace when it is
| bound). I would be willing to bet that *nobody* does this who actually
| needs it.
|
| If we *must* go through that path, then the 'call_with_ns' code needs
| to be hardened two ways:
|
| - It should prefer 'context' to 'here' ('here' is deprectated in
| Zope).
|
| - It should be willing to supply 'None' if the 'context'/'here' keys
| are not present in the namespace.
From glancing at the code it looks like this is the right thing to
do. I wonder who's the person that gets the last word on that dark
corner of Zope. Would that be Fred?
| As a reminder, 'actions' as defined by 'portal_actions' tool and
| anything that derives from 'ActionProviderBase' suffer from the same
| issue.
|
| We could work around the issue in the CMF by supplying a (temporary,
| deprecated) 'here' key in the context we create. The problem with Zope
| assuming that 'here' or 'context' are mandatory namespace keys is that,
| in our case, we have multiple candidates for the role, and therefore
| wish to use unambiguous name.
Yeah, I would like to avoid that one, but considering all Zope
versions out there have the issue, we might need to provide the
temporary fix for a while, to be deprecated in a couple versions.
--
Sidnei da Silva
Enfold Systems, LLC.
http://enfoldsystems.com
___
Zope-Dev maillist - Zope-Dev@zope.org
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 )
[Zope-dev] fresh install zope3.1.0 (binary installer) on windows
Could we create some docs on 'Newbie: How-to install the recent Zope3.1.0 on windows using the binary installer' provided at zope.org ? At the moment http://dev.zope.org/Zope3/Zope310 is the only available doc. It says 'Installation instructions for both Windows and Un*x/Linux are now available in the top level README.txt file of the distribution. The binary installer is recommended for Windows.' Which means, you need to download the tarball to get to install instructions. Would you like to comment on the questions below ? Questions when using the binary installer on windows: * already installed zope3 versions are recognized by the installer * the user is prompted to uninstall first * user knows where to uninstall * user knows the name of the program to uninstall * installer uninstalls on demand * installer installs and exits * user knows the place of the installation * zope program group is created with contents of the program group * start.bat - startup zope * nt-service - install as a windows service * uninstall * documentation * zope docs * online docs * create a new zope instance * install and start zeo * ...and your questions here I will add your comments to http://zopewiki.org/ZopeOnWindowsInstaller for a quick start. Michael -- http://zope.org/Members/d2m http://planetzope.org ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] Allowing python logging from restricted code
Hi Tim, Tim McLaughlin wrote: We are currently finishing up a debug_log much like the error log that Python scripts can write too. We would happily make that source available if you think it will fit the bill. I';d sure be interested in taking a look, but python's logging package is pretty all-inclusive and extremely flexible. All that it needs is some security declarations to make it available from restricted code and the ability to define more than just and event and access log in zope.conf... cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
