[hunchentoot-devel] Re: hunchentoot authorization

[Cyrus Harmon]

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

> 1. 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.

> 2. 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.

> 3. 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 at 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):
>
> 1. How do you enable users of hunchentoot-auth to use their own design
>   for the login and rejection pages?
>
> 2. Where do you end up if the login was successful?  Is it the same
>   page for all users?
>
> 3. 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.