BTW, please don't send HTML formatted mail to the Zope list, it makes it a bit difficult to deal with. I'm meaning to mention this for the past week or so... Jason Jones wrote:

I'm new to Zope and having some trouble understanding the user authentication procedures.

I've defined several user roles to suit my needs (author, moderator, maintainer, partner, etc,...) and want to be able to provide access to objects based on whether a user has priviledges dictated by those roles, for the specific object. My problem is that I don't want Zope to handle the authentication, rather I would like to provide a login form for users.

You mean you don't want the *browser* handling HTTP Basic authentication? The server is going to get involved in all cases, including an HTML forms based method.

Normally I would keep user data in and RDBMS, let the user log in, I'd grab their permissions, issue a session_id either as a cookie or part of the URL, and enter the session_id/permissions into a hashtable or some other storage so that I could check it when I needed to, and delete it when the session lapses or the user logs out.

Sounds reasonable.

Do I need to do essentially the same thing in Zope, or is there some way that I can authenticate a user from a DTML login method and have that authentication persist (and be queryable) throughout the user's session until they log off?

There are no high level Zope 'sessions'. You need to design them into your application. At this point, this is usualy done with a cookie.

It's my understanding that with HTTP authentication, Zope will essentially manage the session persistence so that later on I could use the AUTHENTICATED_USER object to find out who I'm dealing with and act accordingly, but is their a way to do the authentication from DTML? I can't seem to locate such method calls in the documentation, and I don't know how Zope stores session information.

Zope does not keep the AUTHENTICATED_USER object around in a persistent manner. How HTTP basic auth works is that the server challenges the browser on *every* request, on the first request, the browser caches the uid and pwd the user types in ,and uses it for each subsequent request. The point is, there is NO state maintained on the server end. If you want to keep state, you'll have to set a cookie, or munge your URLs. I would set a cookie, URL munging is a pain. To fold your cookie auth into the Zope security framework, you would need to write your own kind of User folder. Luckily, we have done this allready with UserDB, which can authenticate with cookies against a relational database. To make it work like a normal Zope folder but with cookies, you would jsut have to create a new kind of Zope folder that did the cookie part from UserDB but not the DB part, or you could just use UserDB.

Of course, I could be looking at this the wrong way. Is Zope's security setup even intended to provide ways of managing a user's session and the content they can view and manipulate, or is it mainly intended for managing access by people who will be dealing with Zope itself (this is what all of the documentation examples tend toward)?

Zope has no built in restrictions for using session like concepts, in fact we have used that model many times. You'll just have to roll your own, because no general solution has been found yet. -Michel