I emailed Edi a week or so with some half-baked ideas about authorization/authentication and hunchentoot. He suggested continuing this discussion on the list, so I'm forwarding his initial comments below. For some background here, my initial approach to authorization with hunchentoot can be found at:
http://git.cyrusharmon.org/cgi-bin/gitweb.cgi?p=hunchentoot-auth.git
quoting my initial message, (some of) the motivation for this is to have:
* HTML-based login, rather than the standard browser authentication dialog box * some notion of users/groups/realms * an easy way to serve content to: ** non-authenticated users ** authenticated but not necessarily authorized for this page users ** authenticated and authorized users
Edi's questions and some answers are
- How do you enable users of hunchentoot-auth to use their own design
for the login and rejection pages?
Yes, this is one of the main issues with the current design. Right now this is handled through the authorized-page macro. It allows for users (developers) to pass in a :login-page-function which should handle that.
- Where do you end up if the login was successful? Is it the same
page for all users?
authorized-page is a macro that wraps each authorized page, so you end up on the selected page. not the most elegant way to do things. I'd like to remove the use of the macro here and tap into ht's dispatch machinery to do this more elegantly.
- Do you have a mechanism where, if I enter the URL of a page which
needs authorization, I first have to log in but will then be redirected to the page I wanted to go to in the first place?
yes, that's what the authorized-page macro does. again, there's probably a better approach.
This also raises the question how these are stored. Maybe provide hooks or a backend API so that one can use an existing database and/or combine with your own user class? (I.e. the USER class of hunchentoot-auth should probably be prepared to be a mixin.)
For ht-auth, this is stored in the realm class. It would certainly be simple enough to have a generic realm class along with a simple-realm or some such that has the current (admittedly trivial) functionality of storing the users/password-hashes in a local file.
Further thoughts/comments on authorization and hunchentoot from the list?
thanks,
Cyrus
On Apr 11, 2008, at 12:41 AM, Edi Weitz wrote:
Hi Cyrus,
I've looked at this (a bit!) now and I'm adding my thoughts about the issue below. Sorry for the delay.
On Thu, 3 Apr 2008 11:52:32 -0700, Cyrus Harmon cyrus@cyrusharmon.org wrote:
The issue is authentication. Hunchentoot kindly provides some basic services, but I'd like a more full-featured authentication mechanism with features like:
- HTML-based login, rather than the standard browser authentication dialog box
- some notion of users/groups/realms
- an easy way to serve content to: ** non-authenticated users ** authenticated but not necessarily authorized for this page
users ** authenticated and authorized users
I agree that all of this is usually needed/wanted in a "modern" web application and I've often implemented at least parts of this myself.
Possible problems that I'm seeing here (if you want a flexible and general solution):
- How do you enable users of hunchentoot-auth to use their own design
for the login and rejection pages?
- Where do you end up if the login was successful? Is it the same
page for all users?
- Do you have a mechanism where, if I enter the URL of a page which
needs authorization, I first have to log in but will then be redirected to the page I wanted to go to in the first place?
- an administrative UI for managing users/groups/realms
This also raises the question how these are stored. Maybe provide hooks or a backend API so that one can use an existing database and/or combine with your own user class? (I.e. the USER class of hunchentoot-auth should probably be prepared to be a mixin.)
- a UI for requesting new accounts, possibly with some sort of admin step hook or email based confirmation of accounts
Yep.
Would it make sense to continue this discussion on the mailing list?
Cheers, Edi.