ZEXP F Å((U
OFS.FolderqUFolderqtqNt.}q(U__ac_local_roles__q}qUzopeq]qUOwnerq asUacl_managerq
(U Hq(UProducts.ACLManager.ACLManagerqU
ACLManagerq
ttQU_Change_permissions_Permissionq]qUManagerqaU_Add_zwolcategories_Permissionq]qhaU#_Add_Database_Connectors_Permissionq]qhaU_Change_TinyTable_Permissionq]qhaU!_Change_DTML_Documents_Permissionq]q(U
InstructorqheU_Add_ZWOLDocuments_Permissionq]qhaU-_EduUser_faculty_staff_info__write_Permissionq]qhaU_Add_ZCatalogs_Permissionq]q(hheU*_Clean_Out_Database_Permissions_Permissionq ]q!haU$_EduUser_employment__read_Permissionq"]q#haU_View_Permissionq$]q%(UEnrolled Studentq&hheU_Undo_changes_Permissionq']q((hheU(_EduUser_transcript__read_all_Permissionq)]q*haU'_Create_Database_Permissions_Permissionq+]q,haU$_Add_Generic_User_Folders_Permissionq-]q.haU&_Assign_GroupACLs_to_groups_Permissionq/]q0haU*_Write_EduUser_Private_Identity_Permissionq1]q2haU(_Save_discard_Version_changes_Permissionq3]q4(hheU_Change_proxy_roles_Permissionq5]q6haUdescriptionq7(U
xq8(UOFS.DTMLDocumentq9UDTMLDocumentq:ttQU)_EduUser_transcript__write_all_Permissionq;]q DatabaseAPI and ACLManager are two products that work together
to bring Zope technology forward. They are especially
applicable to product authors making use of databases
as well as enterprise level installations of Zope. The DatabaseAPI product permits the creation of a
non-implementation-specific, standardized database API.
It also simplifies the task of writing
an implementation of the API. Products built around the API can
then communicate with whatever kind of database has been
implemented onsite (including SQL, LDAP, and proprietary types.)
In effect, Zope products built around DatabaseAPI gain a higher
degree of "plug and play" capability. ACLManager takes the concept of abstract databases a little farther
and enables Zope user management based on an implementation of a
DatabaseAPI. It also takes advantage of Zope's roles and permissions
subsystem to provide a seamless and theoretically secure connection
to a protected database. Both were designed with an educational setting in mind. System
Administrators at educational institutions don't have the time to
fiddle with a lot of settings and read a mountain of documentation
just to add a small feature to their site. They need to be able to
download a product, install it, and have it interoperate with their
database right away. That is why DatabaseAPI is so important. And
they must not be required to spend their time managing users, since
there are thousands of students and only a few people--often only
one--who are qualified to manage a Web site. ACLManager helps to
reduce the burden of user management. However, these products can fulfill a wide variety of needs.
They are designed in a modular way, taking full advantage of Zope's
object-oriented architecture. This is an early release so the documentation is scarce and there
are not yet any good examples of usage. However, most of its functions
have been tested at least once and, after a lot of reworking and
rewriting, all known bugs have been resolved. If you are writing
anything in Zope that interacts with a database, you really should
study these products. They will help you ensure your product works
with any database or distributed system. When installed, the DatabaseAPI product provides two new Zope object
types: DatabaseAPI and DatabaseConnector. The theory is that product
authors will create a DatabaseAPI which everyone will use, while
others (including on-site programmers) will create DatabaseConnector
objects which implement the API. An API consists of methods, record types, and permissions.
Methods, as in Zope, are pieces of program code that complete a
small task and sometimes send back some information. In many
cases the information sent back will conform to a specific format.
Record types define the format. One of the properties of a
method is the record type which it returns. Another property
that can be assigned to methods is the permission required to
execute that method. Once an API has been created, a DatabaseConnector can be created
which implements the API. In other words, a DatabaseAPI is a
declaration of what should be in a DatabaseConnector.
In DatabaseConnector the user
provides an implementation of each of the methods using
DTML, Python, Z SQL methods, external methods, or a constant
value. The methods, which will be written for a specific type of
database, simply fulfill the function designated by the DatabaseAPI. It is planned that DatabaseConnector objects will eventually
provide services that
lighten the burden for those who write database implementations.
Suggestions on what services to provide are welcome. The current
DatabaseConnector already parses returned data from several formats
into Python-native record objects automatically. Once a database implementation is created, it is exposed as
a single object having methods and permissions. The object can
have a virtual presence anywhere in a Zope hierarchy, taking upon
itself the roles and permissions that apply to its virtual
context. Keep in mind, however, that there is currently no good way
to use the virtual context feature except in conjunction with the
ACLManager product. It is expected that product authors will collaborate and write a
standardized DatabaseAPI for different applications of Zope,
encouraging interoperability and simplified end-user installation.
One type of API already being created is the API that facilitates
connection to an ACLManager. The ACLManager product provides two new object types: ACLManager
and GroupACL. The ACLManager object must be located in the same
directory as the DatabaseConnector object from which it draws users.
Generally a site will only need a single ACLManager object.
The information provided to ACLManager about each user includes,
among other data, a list of group names and roles. GroupACL objects are intended to be spread out in the Zope
hierarchy. They must have access to the ACLManager object (always
called acl_manager) through acquisition. GroupACL objects are
very similar to user folders, but all user information is drawn
from the ACLManager. Cookie-based logins are supported (in
fact, user authentication is persistent and can be shared easily among
multiple servers using NFS, Windows Networking, or other network file
sharing mechansims.) Users get access to a folder managed by a
GroupACL by being a member of a group. The groups are assigned
to GroupACL objects by a system administrator or through a
request-based system. Users have only one password that
works on the whole server (or series of servers). An important feature of GroupACL objects is that they expose
the database implementation in a virtual context. To access the
database, DTML just needs to call the userdb() method on the GroupACL
object, which is always called acl_users. For example,
The permissions mechanism is the reason this whole project
started, actually. During the creation of the Zope-Edu project,
the need for a database API was determined. However, Zope lacked
a clean way to provide users access to the database methods
depending not only on their roles but also on their group
memberships. The DatabaseAPI and ACLManager products
together address that need. Both products are provided under the terms of the
GPL,
meaning that anyone who uses the products is also given
limited rights to the source code as specified in the
GPL. Development of these products is expected to continue
in the Zope-Edu
project on sourceforge.net. Subscribe to the
Zope-Edu-User list
if you would like to help out or just watch what is happening. This folder is a demonstration of the way DatabaseAPI and
ACLManager work. The For this demo, the user data is stored in a
In this demo, enrollment for each of the three course
folders is gathered directly from the centralized
database in real time. Use the editdb folder to manage
users directly. Note that the user interface (the
editdb folder) is completely separate from the database
access mechanism (the db/useredit folder.) That means
that you can write a DatabaseConnector that connects to a different
type of database (such as Oracle) without changing any
of the user interface. Or you can change the user interface
(it could use a facelift)
without changing the database access mechanism, which you
already know to be functioning correctly. DatabaseConnectors
are not difficult to write and can be written using Zope's
management interface. There are a lot of other things that could be explained,
but the best way to understand DatabaseAPI and ACLManager
is to just explore this demo.
Shane Hathaway (April 2000)
Introduction to DatabaseAPI and ACLManager
Copyright (c) 2000 Shane Hathaway
shathaway at earthling.net
March 15, 2000
Version 0.2
<dtml-var "acl_users.userdb().getUserInGroup('john')">
would retrieve information about the user named "john" directly
from the database. All database methods are available through
userdb() and are protected by the permissions declared in DatabaseAPI.
Thus the only way a user is allowed to call a database method
protected by a permission called "Access Schedule Information", for
example, is if the user has a role in the GroupACL-managed folder
that grants the "Access Schedule Information" permission.db
object is the source of the data
accessed by the acl_manager
object.
The important thing to notice
is that acl_manager
doesn't need to know
where the actual data is coming from. DatabaseConnector
and DatabaseAPI provide a layer of abstraction that
allows a connection to any kind of database supported by
Zope.
TinyTablePlus
object. The TinyTablePlus product
is the same as the TinyTable product with only one difference:
it allows updates of the table data from DTML or PythonMethod
code. See the
TinyTablePlus README
for details.GroupACL
objects are
similar to GenericUserFolder
objects (in fact,
GenericUserFolder was used as a starting point) but
GroupACL objects are designed to be managed centrally,
making it more feasible to host hundreds of different
course folders each having a different set of non-static users.
(The cookie management is also improved a lot.)