[cgiapp] Re: user authentication / rights management

[Mark Stosberg <suppressed>]

On 2006-02-18, Cees Hek <suppressed> wrote:
>
>> # Has the user paid for this feature?
>> unless ( $self->authz('paid_features')->authorize('ad_removal')) {
>>    $t->param( $self->ad_tokens );
>> }
>
> That is a very nice example!

Thanks. Feel free to borrow it for the official docs. 

>> I've posted the code for my "Auth By Group" stuff here:
>> http://mark.stosberg.com/perl/AuthByGroup.pm
>>
>> I wrote it as its own plugin, but I think these functions are
>> appropriate to include in the Authorization plugin.
>
> I agree.  What I really need is to sit down with some people and
> brainstorm some of this stuff.  I kind of have an idea in my head of
> how it all should work, but it isn't crystal clear, and that is
> holding me back (as well as the usual time constraints).

If "sit down" could be IRC, a conference call of some variety or even
a video chat, I'd be glad to volunteer for that. Otherwise, I suppose
the Toronto crowd seems like the way to go. 

> I am planning to add direct support for these authentication modules
> to the Authen plugin.  So you can use them like this:
>
> MyCGIApp->authen->config(
>        DRIVER => [ 'Authen::Simple::SMTP', { host => 'smtp.company.com' } ],
>  );
>
> The API for Authen::Simple is not that different from the Drivers in
> the Authen plugin, so this will not be a difficult task to integrate
> the two.

Awesome.

Here's some related feedback while I'm thinking about it. Both these
components really try to be standard, lightweight interfaces, where all
the heavy lifting is done by drivers. 

This provides some abstraction so methods like "redirect_to_login" can
exist, which are generally useful. 

In some cases, I think this service of standardization could be more
transparent by insteading using the proposed stand 'config()' syntax. 

I picked 'redirect_to_login' because I think it's candidate for this
kind of refactoring. Let's look:

Currently, these different parts are involved to use this service: 

 1. Define LOGIN_URL in your config file. 
 
 2. Call authen->config(), and define LOGIN_URL there. 
 
     MyApp->authen->config(
         LOGIN_URL => $self->config('LOGIN_URL'), 
     );
 
 3. Call redirect_to_login(), which looks up the authen config values,
    which gets them from your config file. 

#####

Now contrast that flow with this one:

0. Optionally, document that LOGIN_URL is a standard config key to use,
   so their components can share in the fun.

1. $self->redirect($self->config('LOGIN_URL'));


Easy. Two common plugins are used together, and the
system is simply less complex. 

Now, this isn't quite a fair comparison because redirect_to_login()
might actually redirect three different ways! However, you can't tell
the result by looking at the function call what it will do. You have to
read the documentation about the three different results, and then look
at how you call authen->config() to see what will actually happen. 

One of the other possible outcomes of redirect_to_login() is being
sent to a default login page, a nice service for prototyping an
application. 

Since I like that feature, I'll propose an alternate way to provide it.

Scaffolding. 

Instead of locking up HTML and CSS in Perl code, some basic
templates, images, CSS and skeleton Perl modules can spit
out a helper script. Borrowing the Catalyst syntax, that might look like
this:
o
script/create.pl Authentication::Scaffold

I find I typically have the following run modes in a Auth.pm module:

  login
  login_process
  
  logout
  logout_process
  
  forgot_passwd
  forgot_passwd_process

The runmodes due tend get tweaked a bit per-application, and it's nice
to be able edit them directly, rather than dealing with abstracted
framework. 

I'll have to admit, though that I do have a 'redirect_to_login' in my
own standard toolkit. Mine is different in that it always produces the
same kind of result, and provides added value in two ways:  

 - It supports "continuations" by storing complete address (including
   GET or POST params) of the location at which access is being denied).
   The login_process runmode checks for this value in the session and
   then returns the user to "continue" there and resets the value in the
   session.

   This is very handy, and more robust than passing the value in the
   URL, because it means the right result will still happen even 
   if we have to send the user an e-mail and have them click on 
   a link to get back to the login form. 

 - It passes a query string token to indicate the reason the user
   is being sent to the login page.  Like:
    "You must login before viewing the page you requested."

sub redirect_to_login {
    my $self = shift;

    $self->session->param('return_url', $self->query->self_url );

    my $login_url = $self->config('LOGIN_URL')
        || croak "LOGIN_URL is required config key";
    $self->redirect( "$login_url?not_authorized_p=1");
}


    Mark


-- 
http://mark.stosberg.com/ 


---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/suppressed/
              http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed