-----Original Message----- From: Robb Shecter [mailto:shecter@darmstadt.gmd.de] Sent: Friday, January 21, 2000 3:08 PM To: zope@zope.org Subject: [Zope] Q: How are interactive web apps done?

Hi,

I've done lots of servlet programming, and am finally checking Zope out. It looks -very- interesting. I'd like to use it but I'm still trying to figure out how I'd use Zope in all the ways I use servlets.

For example:

A typical servlet-based web app uses the servlet API to automatically generate a session object for each user. (The API maintains the session by either a cookie or url rewriting.)

Similar mechanisms are employed by current Zope Session Products.

A small inheritance framework can easily be written to make some servlets do authentication in their base classes before allowing the user to continue.

Zope begins to differ at this point, subtly. Although there is nothing stoping an inheritance relationship from participating in authentication, and in some situations it does, in Zope, authentication is primarily acomplished using Acquisition, which is a containment relationship, not an inheritance relationship; meaning that instances acquire authentication information (or mechanisms) from the environment around them, aka, all the other instances in the system. Inheritance ususaly takes a part in the definition of the genetic material of the various authentication components, like Users, and 'User Folders' (which are a bit poorly named, often they don't have any 'Folder' like interface).

The subclasses then can get the session object, which is a hash table of objects. One might then define a User java object that gets put into the session after authentication in the base class. Now all of the user's attributes can be accessed by the servlets.

What is the equivalent way of doing things in Zope? I've read about the various user permissions, but I'm not sure how that'd be used in a web application.

I suspect Zope provides a much higher level framework than you're used to. For example, Zope automaticly inserts the current User object into the web request. Zope authentication mechanisms takes care of authenticating the user and constructing the user object (of course, you can create your own kind of user objects with Python code). All you as a content manager need to are create Roles that define the various 'groups' of your users, map a collection of permissions to each Role. The actions a user are allowed to do are the union of all the permissions of all their Roles. You can get down and dirty, in Python. You can completely discard Zope's authentication and acquisition mechanisms and just use it's object publishing ORB and some database modules to simulate what Java Servlets give you. This is much lower level than sitting in the Zope managment interface.

For example, how would an interactive banking application be implemented in Zope? Where would you define what info you want to save about each user?

A relational database could be a good place if you used UserDB, which is a Zope authenticator which works against RDBMs. I'm assuming this would be the method you are acustomed to with Servlets.

How is the ODB used in a more database-like way, as opposed to a transparent web document source way? Or, is there no difference?

There is a difference, and that's when all the research we're doing right now starts to come into the discussion. Whereas we and others have come up with various hackish ways of working with dynamic user schemas and how users look in various system contexts, no generic, reusble mechanism has arisen because the problem is so hard, and I suspect many of the Java platforms punt on a generic reusable mechanism for the same reason. For example, lets say you had a whole Suite of applications. In this environment, you want to maintain an identy accross all applications, possible across multiple remote platforms. Each application may want each user object to look or act completely different. Some applications may consider the information they want to store about the user to be confidential, while other applicaitons may have a lower security barrier and authorization may be necessary for certain applications to allow other applications access to the information they are concerned about in the user. Is there a central LDAPish user repository? Both? Do individual applications keep localized user information? How do users synchronize possibly remote data? How does user managment propegate then to the distributed sources? Does the user or the application control the security between applications? What if two applications define two semantically identical bits of information but uses them in wildly different ways? What if you want to use legacy data (LDAP, RDBM). etc... We've been asking these questions for about a year now, and there's been alot of head scratchin'. What we're conceiving is a generic reusable mechanism which addresses at least a few of these questions. -Michel