[Zope] Sessions and authentication

Chris McDonough chrism@digicool.com
Wed, 7 Mar 2001 20:36:31 -0500


The use of a session management tool (like SQLSession, FSSession, or
CoreSessionTracking) in combination with an Access Rule (which by nature is
fired when the folder containing it is traversed) would seem to address many
of these issues as well.

----- Original Message -----
From: "Curtis Maloney" <curtis@cardgate.net>
To: "Gerald Gutierrez" <gutz@kalador.com>; <zope@zope.org>
Cc: <gutz@kalador.com>
Sent: Tuesday, March 06, 2001 11:16 PM
Subject: Re: [Zope] Sessions and authentication


> 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
>
> _______________________________________________
> Zope maillist  -  Zope@zope.org
> http://lists.zope.org/mailman/listinfo/zope
> **   No cross posts or HTML encoding!  **
> (Related lists -
>  http://lists.zope.org/mailman/listinfo/zope-announce
>  http://lists.zope.org/mailman/listinfo/zope-dev )
>