File: PKG-INFO

package info (click to toggle)
zope2.13 2.13.22-1
  • links: PTS, VCS
  • area: main
  • in suites: jessie, jessie-kfreebsd
  • size: 38,644 kB
  • ctags: 38,805
  • sloc: python: 196,395; xml: 90,515; ansic: 24,121; sh: 916; makefile: 333; perl: 37
file content (103 lines) | stat: -rw-r--r-- 4,537 bytes parent folder | download | duplicates (3)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
Metadata-Version: 1.0
Name: Products.PythonScripts
Version: 2.13.2
Summary: Provides support for restricted execution of Python scripts in Zope 2.
Home-page: http://pypi.python.org/pypi/Products.PythonScripts
Author: Zope Foundation and Contributors
Author-email: zope-dev@zope.org
License: ZPL 2.1
Description: Overview
        ========
        
        The Python Scripts product provides support for restricted execution of
        Python scripts, exposing them as callable objects within the Zope
        environment.
        
        Providing access to extra modules
        ---------------------------------
        
        Python script objects have a limited number of "safe" modules
        available to them by default. In the course of working with Zope,
        you will probably wish to make other modules available to script
        objects.
        
        The Utility.py module in the PythonScripts products provides a
        simple way to make modules available for use by script objects
        on a site-wide basis. Before making a module available to Python
        scripts, you should carefully consider the potential for abuse
        or misuse of the module, since all users with permission to
        create and edit Python scripts will be able to use any functions
        and classes defined in the module. In some cases, you may want to
        create a custom module that just imports a subset of names from
        another module and make that custom module available to reduce
        the risk of abuse.
        
        The easiest way to make modules available to Python scripts on
        your site is to create a new directory in your Products directory
        containing an "__init__.py" file. At Zope startup time, this
        "product" will be imported, and any module assertions you make
        in the __init__.py will take effect. Here's how to do it:
        
        - In your Products directory (either in lib/python of your
          Zope installation or in the root of your Zope install,
          depending on your deployment model), create a new directory
          with a name like "GlobalModules".
        
        - In the new directory, create a file named "__init__.py".
        
        - Edit the __init__.py file, and add calls to the 'allow_module'
          function (located in the Products.PythonScripts.Utility module),
          passing the names of modules to be enabled for use by scripts.
          For example::
        
            # Global module assertions for Python scripts
            from Products.PythonScripts.Utility import allow_module
        
            allow_module('base64')
            allow_module('re')
            allow_module('DateTime.DateTime')
        
          This example adds the modules 'base64', 're' and the 'DateTime'
          module in the 'DateTime' package for use by Python scripts. Note
          that for packages (dotted names), each module in the package path
          will become available to script objects.
        
        - Restart your Zope server. After restarting, the modules you enabled
          in your custom product will be available to Python scripts.
        
        Placing security assertions within the package/module you are trying
        to import will not work unless that package/module is located in
        your Products directory.
        
        This is because that package/module would have to be imported for its
        included security assertions to take effect, but to do
        that would require importing a module without any security
        declarations, which defeats the point of the restricted
        Python environment.
        
        Products work differently as they are imported at Zope startup.
        By placing a package/module in your Products directory, you are
        asserting, among other things, that it is safe for Zope to check
        that package/module for security assertions. As a result, please
        be careful when place packages or modules that are not Zope Products
        in the Products directory.
        
        Changelog
        =========
        
        2.13.2 (2012-09-09)
        -------------------
        
        - Correct module security declaration for our `standard` module.
        
        2.13.1 (2012-09-09)
        -------------------
        
        - LP #1047318: Adjust tests.
        
        2.13.0 (2010-07-10)
        -------------------
        
        - Released as separate package.
        
Platform: UNKNOWN