[Zope3-checkins] SVN: Zope3/branches/ZopeX3-3.0/src/zope/ More
ReSTification and consistency changes.
Fred L. Drake, Jr.
fred at zope.com
Fri Jul 16 15:54:15 EDT 2004
Log message for revision 26592:
More ReSTification and consistency changes.
Changed:
U Zope3/branches/ZopeX3-3.0/src/zope/README.txt
U Zope3/branches/ZopeX3-3.0/src/zope/pagetemplate/architecture.txt
U Zope3/branches/ZopeX3-3.0/src/zope/pagetemplate/readme.txt
U Zope3/branches/ZopeX3-3.0/src/zope/security/readme.txt
U Zope3/branches/ZopeX3-3.0/src/zope/server/ftp/README.txt
-=-
Modified: Zope3/branches/ZopeX3-3.0/src/zope/README.txt
===================================================================
--- Zope3/branches/ZopeX3-3.0/src/zope/README.txt 2004-07-16 19:51:26 UTC (rev 26591)
+++ Zope3/branches/ZopeX3-3.0/src/zope/README.txt 2004-07-16 19:54:15 UTC (rev 26592)
@@ -1,14 +1,17 @@
Zope Project Packages
+---------------------
-The zope package is a pure namespace package holding packages developed as part
-of the Zope 3 project.
+The zope package is a pure namespace package holding packages
+developed as part of the Zope 3 project.
-Generally, the immediate subpackages of the zope package should be useful and
-usable outside of the Zope application server. Subpackages of the zope package
-should have minimal interdependencies, although most depend on zope.interface.
+Generally, the immediate subpackages of the `zope` package should be
+useful and usable outside of the Zope application server. Subpackages
+of the `zope` package should have minimal interdependencies, although
+most depend on `zope.interface`.
-The one subpackage that's not usable outside the application server is the app
-subpackage, zope.app, which *is* the application server. Sub-packages of
-zope.app are not usable outside of the application server. If there's
-something in zope.app you want to use elsewhere, let us know and we can talk
-about abstracting some of it up out of zope.app.
+The one subpackage that's not usable outside the application server is
+the `app` subpackage, `zope.app`, which *is* the application server.
+Sub-packages of `zope.app` are not usable outside of the application
+server. If there's something in `zope.app` you want to use elsewhere,
+let us know and we can talk about abstracting some of it up out of
+`zope.app`.
Modified: Zope3/branches/ZopeX3-3.0/src/zope/pagetemplate/architecture.txt
===================================================================
--- Zope3/branches/ZopeX3-3.0/src/zope/pagetemplate/architecture.txt 2004-07-16 19:51:26 UTC (rev 26591)
+++ Zope3/branches/ZopeX3-3.0/src/zope/pagetemplate/architecture.txt 2004-07-16 19:54:15 UTC (rev 26592)
@@ -2,28 +2,25 @@
================
There are a number of major components that make up the page-template
-architecture:
+architecture:
- - The TAL compiler and interpreter. This is responsible for
- compiling source files and for executing compiled templates. See
- the zope.tal package for more information.
+- The TAL compiler and interpreter. This is responsible for compiling
+ source files and for executing compiled templates. See the zope.tal
+ package for more information.
- - An expression engine is responsible for compiling expressions and
- for creating expression execution contexts. It is common for
- applications to override expression engines to provide custom
- expression support or to change the way expressions are
- implemented.
+- An expression engine is responsible for compiling expressions and
+ for creating expression execution contexts. It is common for
+ applications to override expression engines to provide custom
+ expression support or to change the way expressions are implemented.
- Expression contexts support execution of expressions and provide
- APIs for setting up variable scopes and setting variables.
- The expressions contexts are passed to the TAL interpreter at
- execution time.
-
- The most commonly used expression implementation is that found in
- zope.tales.
+ Expression contexts support execution of expressions and provide
+ APIs for setting up variable scopes and setting variables. The
+ expressions contexts are passed to the TAL interpreter at execution
+ time.
- - Page templates tie everything together. The assemble an expression
- engine with the TAL interpreter and orchestrate management of
- source and compiled template data. See `interfaces.py`.
+ The most commonly used expression implementation is that found in
+ `zope.tales`.
-
+- Page templates tie everything together. The assemble an expression
+ engine with the TAL interpreter and orchestrate management of source
+ and compiled template data. See `interfaces.py`.
Modified: Zope3/branches/ZopeX3-3.0/src/zope/pagetemplate/readme.txt
===================================================================
--- Zope3/branches/ZopeX3-3.0/src/zope/pagetemplate/readme.txt 2004-07-16 19:51:26 UTC (rev 26591)
+++ Zope3/branches/ZopeX3-3.0/src/zope/pagetemplate/readme.txt 2004-07-16 19:54:15 UTC (rev 26592)
@@ -61,4 +61,4 @@
pt.write(template)
pt(das_object=foo())
-See interfaces.py.
+See `interfaces.py`.
Modified: Zope3/branches/ZopeX3-3.0/src/zope/security/readme.txt
===================================================================
--- Zope3/branches/ZopeX3-3.0/src/zope/security/readme.txt 2004-07-16 19:51:26 UTC (rev 26591)
+++ Zope3/branches/ZopeX3-3.0/src/zope/security/readme.txt 2004-07-16 19:54:15 UTC (rev 26592)
@@ -1,324 +1,330 @@
+==============
Zope3 Security
+==============
- Introduction
+Introduction
+------------
- The Security framework provides a generic mechanism to implement
- security policies on Python objects. This introduction provides a
- tutorial of the framework explaining concepts, design, and going
- through sample usage from the perspective of a Python programmer
- using the framework outside of Zope.
+The Security framework provides a generic mechanism to implement
+security policies on Python objects. This introduction provides a
+tutorial of the framework explaining concepts, design, and going
+through sample usage from the perspective of a Python programmer using
+the framework outside of Zope.
- Definitions
+Definitions
+-----------
- Principal
+Principal
+ A generalization of a concept of a user.
- A generalization of a concept of a user.
+Permission
+ A kind of access, i.e. permission to READ vs. permission to WRITE.
+ Fundamentally the whole security framework is organized around
+ checking permissions on objects.
- Permission
+Purpose
+-------
- A kind of access, i.e. permission to READ vs. permission to
- WRITE. Fundamentally the whole security framework is organized
- around checking permissions on objects.
+The security framework's primary purpose is to guard and check access
+to Python objects. It does this by providing mechanisms for explicit
+and implicit security checks on attribute access for objects.
+Attribute names are mapped onto permission names when checking access
+and the implementation of the security check is defined by the
+security policy, which receives the object, the permission name, and
+an interaction.
- Purpose
+Interactions are objects that represent the use of the system by one
+or more principals. An interaction contains a list of participations,
+which represents the way a single principal participates in the
+interaction. An HTTP request is one example of a participation.
- The security framework's primary purpose is to guard and check
- access to Python objects. It does this by providing mechanisms
- for explicit and implicit security checks on attribute access for
- objects. Attribute names are mapped onto permission names when
- checking access and the implementation of the security check is
- defined by the security policy, which receives the object, the
- permission name, and an interaction.
+Its important to keep in mind that the policy provided is just a
+default, and it can be substituted with one which doesn't care about
+principals or interactions at all.
- Interactions are objects that represent the use of the system by
- one or more principals. An interaction contains a list of
- participations, which represents the way a single principal
- participates in the interaction. An HTTP request is one example
- of a participation.
+Framework Components
+--------------------
- Its important to keep in mind that the policy provided is just a
- default, and it can be substituted with one which doesn't care
- about principals or interactions at all.
+Low Level Components
+~~~~~~~~~~~~~~~~~~~~
- Framework Components
+These components provide the infrastructure for guarding attribute
+access and providing hooks into the higher level security framework.
- Low Level Components
+Checkers
+ A checker is associated with an object kind, and provides the hooks
+ that map attribute checks onto permissions deferring to the security
+ manager (which in turn defers to the policy) to perform the check.
- These components provide the infrastructure for guarding
- attribute access and providing hooks into the higher level
- security framework.
+ Additionally, checkers provide for creating proxies of objects
+ associated with the checker.
- Checkers
+ There are several implementation variants of checkers, such as
+ checkers that grant access based on attribute names.
- A checker is associated with an object kind, and provides the
- hooks that map attribute checks onto permissions deferring to
- the security manager (which in turn defers to the policy) to
- perform the check.
+Proxies
+ Wrappers around Python objects that implicitly guard access to their
+ wrapped contents by delegating to their associated checker. Proxies
+ are also viral in nature, in that values returned by proxies are
+ also proxied.
- Additionally, checkers provide for creating proxies of objects
- associated with the checker.
+High Level Components
+~~~~~~~~~~~~~~~~~~~~~
- There are several implementation variants of checkers, such as
- checkers that grant access based on attribute names.
+Security Management
+ Provides accessors for setting up interactions and global security
+ policy.
- Proxies
+Interaction
+ Stores transient information on the list of participations.
- Wrappers around Python objects that implicitly guard access to
- their wrapped contents by delegating to their associated
- checker. Proxies are also viral in nature, in that values
- returned by proxies are also proxied.
+Participation
+ Stores information about a principal participating in the
+ interaction.
- High Level Components
+Security Policy
+ Provides a single method that accepts the object, the permission,
+ and the interaction of the access being checked and is used to
+ implement the application logic for the security framework.
- Security Management
+Narrative (agent sandbox)
+-------------------------
- Provides accessors for setting up interactions and global
- security policy.
+As an example we take a look at constructing a multi-agent distributed
+system, and then adding a security layer using the Zope security model
+onto it.
- Interaction
+Scenario
+~~~~~~~~
- Stores transient information on the list of participations.
+Our agent simulation consists of autonomous agents that live in
+various agent homes/sandboxes and perform actions that access services
+available at their current home. Agents carry around authentication
+tokens which signify their level of access within any given home.
+Additionally agents attempt to migrate from home to home randomly.
- Participation
+The agent simulation was constructed separately from any security
+aspects. Now we want to define and integrate a security model into
+the simulation. The full code for the simulation and the security
+model is available separately; we present only relevant code snippets
+here for illustration as we go through the implementation process.
- Stores information about a principal participating in the
- interaction.
+For the agent simulation we want to add a security model such that we
+group agents into two authentication groups, "norse legends",
+including the principals thor, odin, and loki, and "greek men",
+including prometheus, archimedes, and thucydides.
- Security Policy
+We associate permissions with access to services and homes. We
+differentiate the homes such that certain authentication groups only
+have access to services or the home itself based on the local settings
+of the home in which they reside.
- Provides a single method that accepts the object, the
- permission, and the interaction of the access being checked
- and is used to implement the application logic for the security
- framework.
+We define the homes/sandboxes
- Narrative (agent sandbox)
+origin
+ all agents start here, and have access to all services here.
- As an example we take a look at constructing a multi-agent
- distributed system, and then adding a security layer using the
- Zope security model onto it.
+valhalla
+ only agents in the authentication group 'norse legend' can reside
+ here.
- Scenario
+jail
+ all agents can come here, but only 'norse legend's can leave or
+ access services.
- Our agent simulation consists of autonomous agents that live in
- various agent homes/sandboxes and perform actions that access
- services available at their current home. Agents carry around
- authentication tokens which signify their level of access within
- any given home. Additionally agents attempt to migrate from
- home to home randomly.
+Process
+~~~~~~~
- The agent simulation was constructed separately from any
- security aspects. Now we want to define and integrate a
- security model into the simulation. The full code for the
- simulation and the security model is available separately; we
- present only relevant code snippets here for illustration as we
- go through the implementation process.
+Loosely we define a process for implementing this security model
- For the agent simulation we want to add a security model such
- that we group agents into two authentication groups, "norse
- legends", including the principals thor, odin, and loki, and
- "greek men", including prometheus, archimedes, and thucydides.
+- mapping permissions onto actions
- We associate permissions with access to services and homes. We
- differentiate the homes such that certain authentication groups
- only have access to services or the home itself based on the
- local settings of the home in which they reside.
+- mapping authentication tokens onto permissions
- We define the homes/sandboxes
+- implementing checkers and security policies that use our
+ authentication tokens and permissions.
- - origin - all agents start here, and have access to all
- services here.
+- binding checkers to our simulation classes
- - valhalla - only agents in the authentication group 'norse
- legend' can reside here.
+- inserting the hooks into the original simulation code to add proxy
+ wrappers to automatically check security.
- - jail - all agents can come here, but only 'norse legend's
- can leave or access services.
+- inserting hooks into the original simulation to register the agents
+ as the active principal in an interaction.
+Defining Permission Model
+~~~~~~~~~~~~~~~~~~~~~~~~~
- Process
+We define the following permissions::
- Loosely we define a process for implementing this security model
+ NotAllowed = 'Not Allowed'
+ Public = Checker.CheckerPublic
+ TransportAgent = 'Transport Agent'
+ AccessServices = 'Access Services'
+ AccessAgents = 'Access Agents'
+ AccessTimeService = 'Access Time Services'
+ AccessAgentService = 'Access Agent Service'
+ AccessHomeService = 'Access Home Service'
- - mapping permissions onto actions
+and create a dictionary database mapping homes to authentication
+groups which are linked to associated permissions.
- - mapping authentication tokens onto permissions
+Defining and Binding Checkers
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- - implementing checkers and security policies that use our
- authentication tokens and permissions.
+Checkers are the foundational unit for the security framework. They
+define what attributes can be accessed or set on a given instance.
+They can be used implicitly via Proxy objects, to guard all attribute
+access automatically or explicitly to check a given access for an
+operation.
- - binding checkers to our simulation classes
+Checker construction expects two functions or dictionaries, one is
+used to map attribute names to permissions for attribute access and
+another to do the same for setting attributes.
- - inserting the hooks into the original simulation code to add
- proxy wrappers to automatically check security.
+We use the following checker factory function::
- - inserting hooks into the original simulation to register the
- agents as the active principal in an interaction.
+ def PermissionMapChecker(permissions_map={},
+ setattr_permission_func=NoSetAttr):
+ res = {}
+ for k,v in permissions_map.items():
+ for iv in v:
+ res[iv]=k
+ return checker.Checker(res.get, setattr_permission_func)
- Defining Permission Model
+ time_service_checker = PermissionMapChecker(
+ # permission : [methods]
+ {'AccessTimeService':['getTime']}
+ )
- We define the following permissions::
+with the NoSetAttr function defined as a lambda which always return
+the permission NotAllowed
- NotAllowed = 'Not Allowed'
- Public = Checker.CheckerPublic
- TransportAgent = 'Transport Agent'
- AccessServices = 'Access Services'
- AccessAgents = 'Access Agents'
- AccessTimeService = 'Access Time Services'
- AccessAgentService = 'Access Agent Service'
- AccessHomeService = 'Access Home Service'
+To bind the checkers to the simulation classes we register our
+checkers with the security model's global checker registry::
- and create a dictionary database mapping homes to authentication
- groups which are linked to associated permissions.
+ import sandbox_simulation
+ from zope.security.checker import defineChecker
+ defineChecker(sandbox_simulation.TimeService, time_service_checker)
- Defining and Binding Checkers
+Defining a Security Policy
+~~~~~~~~~~~~~~~~~~~~~~~~~~
- Checkers are the foundational unit for the security framework.
- They define what attributes can be accessed or set on a given
- instance. They can be used implicitly via Proxy objects, to
- guard all attribute access automatically or explicitly to check a
- given access for an operation.
+We implement our security policy such that it checks the current
+agent's authentication token against the given permission in the home
+of the object being accessed::
- Checker construction expects two functions or dictionaries, one
- is used to map attribute names to permissions for attribute
- access and another to do the same for setting attributes.
+ class SimulationSecurityPolicy:
- We use the following checker factory function::
+ implements(ISecurityPolicy)
- def PermissionMapChecker(permissions_map={},
- setattr_permission_func=NoSetAttr):
- res = {}
- for k,v in permissions_map.items():
- for iv in v:
- res[iv]=k
- return checker.Checker(res.get, setattr_permission_func)
+ createInteraction = staticmethod(simpleinteraction.createInteraction)
- time_service_checker = PermissionMapChecker(
- # permission : [methods]
- {'AccessTimeService':['getTime']}
- )
+ def checkPermission(self, permission, object, interaction):
- with the NoSetAttr function defined as a lambda which always
- return the permission NotAllowed
+ home = object.getHome()
+ db = getattr(SimulationSecurityDatabase, home.getId(), None)
- To bind the checkers to the simulation classes we register our
- checkers with the security model's global checker registry::
+ if db is None:
+ return False
- import sandbox_simulation
- from zope.security.checker import defineChecker
- defineChecker(sandbox_simulation.TimeService, time_service_checker)
+ allowed = db.get('any', ())
+ if permission in allowed or ALL in allowed:
+ return True
- Defining a Security Policy
-
- We implement our security policy such that it checks the current
- agent's authentication token against the given permission in the
- home of the object being accessed::
-
- class SimulationSecurityPolicy:
-
- implements(ISecurityPolicy)
-
- createInteraction = staticmethod(simpleinteraction.createInteraction)
-
- def checkPermission(self, permission, object, interaction):
-
- home = object.getHome()
- db = getattr(SimulationSecurityDatabase, home.getId(), None)
-
- if db is None:
+ if interaction is None:
+ return False
+ if not interaction.participations:
+ return False
+ for participation in interaction.participations:
+ token = participation.principal.getAuthenticationToken()
+ allowed = db.get(token, ())
+ if permission not in allowed:
return False
- allowed = db.get('any', ())
- if permission in allowed or ALL in allowed:
- return True
+ return True
- if interaction is None:
- return False
- if not interaction.participations:
- return False
- for participation in interaction.participations:
- token = participation.principal.getAuthenticationToken()
- allowed = db.get(token, ())
- if permission not in allowed:
- return False
+There are no specific requirements for the interaction class, so we
+can just use zope.security.simpleinteraction.Interaction.
- return True
+Since an interaction can have more than one principal, we check that
+*all* of them are given the necessary permission. This is not really
+necessary since we only create interactions with a single active
+principal.
- There are no specific requirements for the interaction class, so we
- can just use zope.security.simpleinteraction.Interaction.
+There is some additional code present to allow for shortcuts in
+defining the permission database when defining permissions for all
+auth groups and all permissions.
- Since an interaction can have more than one principal, we check that
- *all* of them are given the necessary permission. This is not really
- necessary since we only create interactions with a single active
- principal.
+Integration
+~~~~~~~~~~~
- There is some additional code present to allow for shortcuts in
- defining the permission database when defining permissions for
- all auth groups and all permissions.
+At this point we have implemented our security model, and we need to
+integrate it with our simulation model. We do so in three separate
+steps.
- Integration
+First we make it such that agents only access homes that are wrapped
+in a security proxy. By doing this all access to homes and services
+(proxies have proxied return values for their methods) is implicitly
+guarded by our security policy.
- At this point we have implemented our security model, and we
- need to integrate it with our simulation model. We do so in
- three separate steps.
+The second step is that we want to associate the active agent with the
+security context so the security policy will know which agent's
+authentication token to validate against.
- First we make it such that agents only access homes that are
- wrapped in a security proxy. By doing this all access to homes
- and services (proxies have proxied return values for their
- methods) is implicitly guarded by our security policy.
+The third step is to set our security policy as the default policy for
+the Zope security framework. It is possible to create custom security
+policies at a finer grained than global, but such is left as an
+exercise for the reader.
- The second step is that we want to associate the active agent
- with the security context so the security policy will know which
- agent's authentication token to validate against.
+Interaction Access
+~~~~~~~~~~~~~~~~~~
- The third step is to set our security policy as the default
- policy for the Zope security framework. It is possible to
- create custom security policies at a finer grained than global,
- but such is left as an exercise for the reader.
+The *default* implementation of the interaction management interfaces
+defines interactions on a per thread basis with a function for an
+accessor. This model is not appropriate for all systems, as it
+restricts one to a single active interaction per thread at any given
+moment. Reimplementing the interaction access methods though is
+easily doable and is noted here for completeness.
- Interaction Access
+Perspectives
+~~~~~~~~~~~~
- The *default* implementation of the interaction management
- interfaces defines interactions on a per thread basis with
- a function for an accessor. This model is not appropriate for
- all systems, as it restricts one to a single active interaction per
- thread at any given moment. Reimplementing the interaction access
- methods though is easily doable and is noted here for
- completeness.
+It's important to keep in mind that there is a lot more that is
+possible using the security framework than what's been presented here.
+All of the interactions are interface based, such that if you need to
+re-implement the semantics to suite your application a new
+implementation of the interface will be sufficient. Additional
+possibilities range from restricted interpreters and dynamic loading
+of untrusted code to non Zope web application security systems.
+Insert imagination here ;-).
- Perspectives
+Zope Perspective
+~~~~~~~~~~~~~~~~
- It's important to keep in mind that there is a lot more that is
- possible using the security framework than what's been presented
- here. All of the interactions are interface based, such that if
- you need to re-implement the semantics to suite your application
- a new implementation of the interface will be sufficient.
- Additional possibilities range from restricted interpreters and
- dynamic loading of untrusted code to non Zope web application
- security systems. Insert imagination here ;-).
+A Zope3 programmer will never commonly need to interact with the low
+level security framework. Zope3 defines a second security package
+over top the low level framework and authentication sources and
+checkers are handled via zcml registration. Still those developing
+Zope3 will hopefully find this useful as an introduction into the
+underpinnings of the security framework.
- Zope Perspective
+Code
+~~~~
- A Zope3 programmer will never commonly need to interact with the
- low level security framework. Zope3 defines a second security
- package over top the low level framework and authentication
- sources and checkers are handled via zcml registration. Still
- those developing Zope3 will hopefully find this useful as an
- introduction into the underpinnings of the security framework.
+The complete code for this example is available.
- Code
+sandbox.py
+ the agent framework
- The complete code for this example is available.
+sandbox_security.py
+ the security implementation and binding to the agent framework.
- sandbox.py - the agent framework
+Author
+~~~~~~
- sandbox_security.py - the security implementation and binding to
- the agent framework.
+Kapil Thangavelu <hazmat at objectrealms.net>
- Author
+Guido Wesdorp <guido at infrae.com>
- Kapil Thangavelu <hazmat at objectrealms.net>
-
- Guido Wesdorp <guido at infrae.com>
-
- Marius Gedminas <marius at pov.lt>
-
+Marius Gedminas <marius at pov.lt>
Modified: Zope3/branches/ZopeX3-3.0/src/zope/server/ftp/README.txt
===================================================================
--- Zope3/branches/ZopeX3-3.0/src/zope/server/ftp/README.txt 2004-07-16 19:51:26 UTC (rev 26591)
+++ Zope3/branches/ZopeX3-3.0/src/zope/server/ftp/README.txt 2004-07-16 19:54:15 UTC (rev 26592)
@@ -1,11 +1,11 @@
FTP Framework
+=============
- This file contains documentation on the FTP server
- framework.
+This file contains documentation on the FTP server framework.
- The core server is implemented in server.py. This relies on a
- file-system abstraction, defined in zope.server.interface.ft.
+The core server is implemented in server.py. This relies on a
+file-system abstraction, defined in `zope.server.interface.ftp`.
- The publisher module provides the connection to the object
- publsihing system by providing a file-system implementation that
- delegates file-system operations to objects through the publisher.
+The publisher module provides the connection to the object publsihing
+system by providing a file-system implementation that delegates
+file-system operations to objects through the publisher.
More information about the Zope3-Checkins
mailing list