[Zope] question about user authentication

[Michel Pelletier]

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