[cgiapp] Re: user authentication / rights management

[Mark Stosberg <suppressed>]

On 2006-02-17, Michael Graham <suppressed> wrote:
>
>> http://www.summersault.com/community/weblog/2006/02/04/access-in-urls-considered-harmful.html
>
> Hmmm... you make a good argument in that post.  I think I've grown
> accustomed to URL-based schemes mainly through the legacy of HTTP Basic
> Auth (e.g. .htaccess files).  You make a good case for why the web is
> outgrowing that model.
>
> But having a private /admin area does give me the security to know
> that a whole great big part of my application is completely shut off to
> most of the world. 

Sure. I will still use "/admin" with .htaccess for simple projects, or a
quick protection scheme. 

> Mind you, since CAP::Config::Context can also do context matching based
> on Application (i.e. the Module of the currently running webapp), I can
> probably still do this but avoid hiding behind access-based URLs:
>
>     <App MyBlog::Admin>
>         auth_protected = 1
>         auth_groups    = admin
>     </App>

Neat. 

> But of course this doesn't address your main point:  often two users
> with different privileges will run the same application.  For this,
> you'd want runmode matching as well, something like this:
>
>     <App MyBlog::Comment>
>         auth_protected = 0
>     </App>
>
>     <App MyBlog::Comment/post>
>         auth_protected = 1
>         auth_groups    = user
>     </App>
>
>     <App MyBlog::Comment/delete>
>         auth_protected = 1
>         auth_groups    = admin
>     </App>

Isn't "auth_protected" redundant if "auth_groups" is present? 

> But (alas) CAP::Config::Context doesn't do runmode matching (yet). I
> had originally wanted to add this feature, but I ended up leaving it
> out at the last minute, because real world apps often set the run mode
> *after* they load the config file.

Right. 

> But now that the new C::A::Dispatch sets the run mode before the app
> even starts, this feature starts to become feasible again.  I'll look
> into adding it when I get some time to experiment with the new Dispatch
> module.

Ah, that's a nice synergy.

> Side note:  it's important to note that in this discussion, we're only
> addressing controller-oriented security.  Data-oriented security (i.e.
> which particular users have access to which particular blog posts) is
> something else entirely (IMO).

Agreed. For example, if some users pay an extra fee they have access to
a specific feature. This might not be represented well by calling people
with this a right a group, because of the exponential and dynamic
number of possible user-to-paid-feature mappings.  

For that I envision an additional check that happens within the runmode,
but I haven't tackled it yet. 

However, I think Cees had in mind just this kind of thing when he
created the Authorization system, which supports a syntax like this:

# Has the user paid for this feature? 
unless ( $self->authz('paid_features')->authorize('ad_removal')) {
   $t->param( $self->ad_tokens ); 
}

> Sounds interesting!

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. 

And so we aren't working on Authen/Authz stuff in a vacuum, I'll point
out a related release on CPAN that seems interesting. 

chansen, a Catalyst contributor has published "Authen::Simple" with a
lot of backends. On the first look the design looks nice and clean. 

 http://search.cpan.org/~chansen/

I'm not sure how it plugins into Catalyst, though. 

    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