[Zope] Sessions and authentication

[Curtis Maloney]

On Wed,  7 Mar 2001 06:28, Gerald Gutierrez wrote:
> For the past several weeks I've been looking in detail at Zope and PHP, and
> trying to decide which to use for a web application (as opposed to a
> dynamic web site). Zope has a lot helpful infrastructure, but PHP seems
> more flexible.
>
> One of the scenarios I've been thinking about is the
> authentication/authorization mechanism. It's clear to me how to do this
> with PHP and J2EE; I was hoping that someone can explain to me how to do
> this with Zope.
>
> - The app would use URL rewriting for session management.

Not a problem.   Take a look at the CookieLess Session tool.  It acts as a 
regular folder, and inserts a session key into the path if it doesn't find 
one.

> - When a user accesses the site, he has a session but is not logged in

Yep... does that.

> - He can log in through a form

Simple form validation.  Store the login info into the session, and you're 
done.

> - Some pages can be accessed whether the user is logged in or not, other
> pages must have the user logged in
> - If the user tries to view a page where he must be logged in, the server
> forwards automatically to a login form, and goes to that page when he
> successfully logs in
> - User information is maintained in a database. Rules for matching of
> usernames and passwords is as yet undetermined (e.g. strings are stripped,
> compared case insensitively, possibly multiple passwords for a username,
> with each password authenticating the user into a different role)

All this is reasonably straight forward.  I've not toyed with LoginManager, 
but from what I've seen discussed, it shouldn't be a great hardship to have 
this work alongside the CookieLess session and your login form to have users 
authenticated properly.

> - Once the user is logged in, he is given a cookie with a random string as
> the value. That string also goes into the database

Yuck... cookie based sessions?  Nasty stuff.   What happens if:
1) The user is denying cookies?
2) The user edits their cookie?
3) The users proxy screws up the cookie? (THIS HAPPENS!)

And if you're using path munging, why the cookie?  Or is that for persistant 
logins?

> - If a user accesses the site, is not logged in, and as the above described
> cookie, the server looks up that cookie and auto-logs the user in if
> possible (so he is then logged in without having to type in his username
> and/or password)
> - If the user logs out, he cookie is cleared, the random string is
> invalidated in the databse and the user is not auto-logged in at the next
> visit.

Ah.. the danger here, of course, is that anyone using that computer is 
automagically logged in as that user.  This is handy, and in most cases 
harmless... but I have been stung by this before, with login mixups occuring.

> Thanks.
>
>
> Gerald.
>

Have a better one,
	Curtis Maloney