Sessions and authentication
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. - When a user accesses the site, he has a session but is not logged in - He can log in through a form - 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) - 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 - 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. So essentially, I need URL rewriting for session management, and a form based login, with a flexible set of rules for the actual authentication process. I need cookies to be used as an optional feature which can auto-log in a user. If the user uses cookies, he can be auto-logged in. If not, he can't and must do it manually each time he visits. I had tried some of this myself, but with little success. Core Session Tracking is well documented, but LoginManager was much more complicated than I had thought, using many jargons that were hard to understand. In the end, I couldn't get much of it working. If someone tell me whether this is all doable with current packages, and a brief explanation of how, I would appreciate it very, very much. Thanks. Gerald.
On Tue, 6 Mar 2001, Gerald Gutierrez wrote:
- The app would use URL rewriting for session management. - When a user accesses the site, he has a session but is not logged in - He can log in through a form - 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) - 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 - 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.
URL rewriting might be a tad tricky in Zope (I think it's a messy solution in any language, actually). Perhaps two cookies: a permanent you've-logged-in-before one, and a just-for-this-time one, which provides the session ID? Permanent is there to autofill login name and such, temporary one has a recent expiration date, and is used to handle page-to-page session stuff. Then, things would be relatively easy to implement in Zope. I've never used Login Mgr, etc. I'm sure they're better solutions than hand-coding this, though! As far as PHP vs Zope goes: I'd focus on larger scale things than just user authentication. How manageable is the PHP solution? I find it _very_ hairy to work on some else's PHP code. Zope seems more than a tad better in this respect. Good luck. If you learn anything about the session management, consider a HOWTO. -- Joel Burton <jburton@scw.org> Director of Information Systems, Support Center of Washington
URL rewriting might be a tad tricky in Zope (I think it's a messy solution in any language, actually). Perhaps two cookies: a permanent you've-logged-in-before one, and a just-for-this-time one, which provides the session ID? Permanent is there to autofill login name and such, temporary one has a recent expiration date, and is used to handle page-to-page session stuff.
Part of what I'm doing requires talking to cell phones via WML and HDML. While the transport is still HTTP, the phones don't, as per the standards, support cookies. So cookies cannot be made mandatory. It is a "value added feature", as I described, because some WAP gateways support them as an extension. Hence this requirement.
Then, things would be relatively easy to implement in Zope.
I've never used Login Mgr, etc. I'm sure they're better solutions than hand-coding this, though!
I agree, but I'm feeling that authentication/authorization in Zope is limited to what products are available, and building a new product takes a relatively significant amount of time. The requirements I listed are really what I need, and if I can't find a user manager that handles them all, then I believe that I am out of luck. If there is a user manager that works, but I then need a new feature in the auth that isn't supported, then again I'm out of luck.
As far as PHP vs Zope goes: I'd focus on larger scale things than just user authentication. How manageable is the PHP solution? I find it _very_ hairy to work on some else's PHP code. Zope seems more than a tad better in this respect.
Yes. abstraction capability (e.g. SQL as methods), acquisition, and other features in Zope have led me to investigate it in detail. But like the rest, it isn't ideal. I've been able to do everything I have to in J2EE because the API it provides is extremely comprehensive, but the drawback to it is that one needs to maintain an obscene amount of code from XML descriptors to JSPs to servlets to EJBs. I'm just trying to pick out some of the more obvious scenarios and see how they all compare. Is LoginManager the most generalized of the bunch, in terms of the methods that can be used to authenticate? Can the LoginManager be used with URL rewriting?
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
- 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.
I understand the pros and cons; the question here is /how/ to do all this in the context of Zope. It seems I'm more or less confined to use one of a number of User Folder replacements. Is there a user folder that can do all of the following: - do form login - use URL rewriting to keep tracked of a logged in user - do automatic redirection when a restricted page is accessed - use an optional cookie for "persistent logins" - has customizable, flexible rules for authenticating against a database ? I've been unable to make anything work close to this yet in Zope. I'm looking for some pointers on /how/ I must approach this problem. What products must I use? Are there peculiarities in their configuration to get this to work? Must I write some custom code? I would appreciate any help that anyone can give. Thanks. Gerald.
On Wed, 7 Mar 2001 15:38, Gerald Gutierrez wrote:
- 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.
I understand the pros and cons; the question here is /how/ to do all this in the context of Zope. It seems I'm more or less confined to use one of a number of User Folder replacements. Is there a user folder that can do all of the following:
- do form login - use URL rewriting to keep tracked of a logged in user - do automatic redirection when a restricted page is accessed - use an optional cookie for "persistent logins" - has customizable, flexible rules for authenticating against a database
? I've been unable to make anything work close to this yet in Zope. I'm looking for some pointers on /how/ I must approach this problem. What products must I use? Are there peculiarities in their configuration to get this to work? Must I write some custom code?
Well, as I understand it the Generic User Folder was designed to allow you to make it work how YOU wanted, instead of world+dog writing their own UF variant. This product, however, has not had any updates or releases since late May last year. As I understand it, LoginManager is the modern, more general variant of the GUF. If provides you with 'interfaces' to Users and Login Methods, and you fill in the blanks. From what I read of the documentation, it will check object permissions, and, if neccesary, challenge the user in whatever way you write. So, to address your points: -do form login .......... LoginManager - usr URL rewriting to keep tracked of a logged in user .......... CookieLess Session - do automatic redirection when a restricted page is accessed .......... LoginManager - use an optional cookie for 'persistent login" .......... LoginManager - has customizable, flexible rules for authenticating against a database .......... LoginManager
I would appreciate any help that anyone can give.
So, it looks like a hands down choice, here. However, I will reiterate, I have not used Login Manager, and am only working on what it claims from the documentation on Zope.org ( http://www.zope.org/Members/tsarna/LoginManager )
Thanks.
Gerald.
Have a better one, Curtis Maloney
So, it looks like a hands down choice, here. However, I will reiterate, I have not used Login Manager, and am only working on what it claims from the documentation on Zope.org ( http://www.zope.org/Members/tsarna/LoginManager )
Hi Curtis. I understand what you mean; thanks for your input. :) However as they say, the devil is in the details. I just posted one message before I read this one. The LoginManager supports, by default, cookie login, HTTP auth login, and "REMOTE_USER" login. I take this to mean that it can either authenticate using HTTP basic authentication, or let the LoginManager set a cookie with the browser, or use this REMOTE_USER thing. I can't use HTTP basic auth but require form-based login, and I cannot use cookies in my application, and I don't know what this REMOTE_USER thing is. It seems that I will be unable to use the LoginManager. I'm unsure as to how to proceed, as I'm finding that the options are running out as I dive more into the details.
On Wed, 7 Mar 2001 16:52, Gerald Gutierrez wrote:
So, it looks like a hands down choice, here. However, I will reiterate, I have not used Login Manager, and am only working on what it claims from the documentation on Zope.org ( http://www.zope.org/Members/tsarna/LoginManager )
Hi Curtis. I understand what you mean; thanks for your input. :)
However as they say, the devil is in the details. I just posted one message before I read this one. The LoginManager supports, by default, cookie login, HTTP auth login, and "REMOTE_USER" login. I take this to mean that it can either authenticate using HTTP basic authentication, or let the LoginManager set a cookie with the browser, or use this REMOTE_USER thing. I can't use HTTP basic auth but require form-based login, and I cannot use cookies in my application, and I don't know what this REMOTE_USER thing is. It seems that I will be unable to use the LoginManager.
I'm unsure as to how to proceed, as I'm finding that the options are running out as I dive more into the details.
I'm getting the feeling here that you don't want to have to write _ANYTHING_ to get this happening. Well, it doesn't work that way. LoginManager will let you write YOUR OWN login methods... it just happens to come default with those three. What you should look into doing is using CookieLess Sessions in conjunction with LoginManager to effect what you want. This should simply be a matter of putting the acl_users folder inside a CookieLess Session folder, and making your LoginMethod object use the session to store authentication information. Have a better one, Curtis Maloney
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 )
participants (5)
-
Chris McDonough -
Curtis Maloney -
Gerald Gutierrez -
Gerald Gutierrez -
Joel Burton