Re: Authorization question
Jean-Michel Hiver wrote: It's pretty hard to truly separate these things. Nobody wants to use basic auth, which means there is a need for forms and handlers. How do you mean, 'nobody'? Users certainly don't mind! Sure they do. They want a nice HTML login screen, and features like "remember this login on this computer" (using cookies) which is standard on most major sites now. I admit that it's hard to get away without cookies and URI encoding schemes, but not impossible. There's a lot of tricks that you can do with path_info... But path_info is URI encoding. Also, most of the auth/access modules, including ones that stick to the auth and access phases, use cookies or URIs. There really is no other option except basic auth. If you build a generalized auth system, there may well be other people interested in it. However, it would have to be very easy to change the mechanisms for maintaining state (cookies, URIs, basic auth) and checking credentials (any kind of database with any kind of schema). The latter probably means some custom development on every installation. - Perrin
Re: Authorization question
On Thu, 27 Feb 2003, Bill Moseley wrote:
> On Thu, 27 Feb 2003, Perrin Harkins wrote:
>
> > Jean-Michel Hiver wrote:
> > > Yes, but you're then making the authorization layer inseparable from
> > > your applicative layer, and hence you loose the interest of using
> > > separate handlers.
> >
> > It's pretty hard to truly separate these things. Nobody wants to use
> > basic auth, which means there is a need for forms and handlers. Then
> > you have to keep that information in either cookies or URLs, and there
> > is usually a need to talk to an external data database with a
> > site-specific schema. The result is that plug and play auth schemes
> > only work (unmodified) for the simplest sites.
>
> Anyone using PubCookie?
>
> http://www.washington.edu/pubcookie/
All C, no?
- nick
--
Nick Tonkin {|8^)>
Re: Authorization question
> It's pretty hard to truly separate these things. Nobody wants to use > basic auth, which means there is a need for forms and handlers. How do you mean, 'nobody'? Users certainly don't mind! > Then you have to keep that information in either cookies or URLs, and > there is usually a need to talk to an external data database with a > site-specific schema. I admit that it's hard to get away without cookies and URI encoding schemes, but not impossible. There's a lot of tricks that you can do with path_info... For example, http://www.example.com/some/address/hello.txt,do_something This URL is easy to protect / authorize using LocationMatch directives. Basically I think you can use these simple schemes in complex applications if you're careful about your URIs. But it's true that it can be a real mindf*ck :) Basically each state of your application needs a different URI... However I find it well worth it, the promess of a truly modular, standard, pluggable authorization system is seducing, and also very 'marketable' I think. Cheers, -- Building a better web - http://www.mkdoc.com/ - Jean-Michel Hiver [EMAIL PROTECTED] - +44 (0)114 255 8097 Homepage: http://www.webmatrix.net/
Re: Authorization question
On Thu, 27 Feb 2003, Perrin Harkins wrote: > Jean-Michel Hiver wrote: > > Yes, but you're then making the authorization layer inseparable from > > your applicative layer, and hence you loose the interest of using > > separate handlers. > > It's pretty hard to truly separate these things. Nobody wants to use > basic auth, which means there is a need for forms and handlers. Then > you have to keep that information in either cookies or URLs, and there > is usually a need to talk to an external data database with a > site-specific schema. The result is that plug and play auth schemes > only work (unmodified) for the simplest sites. Anyone using PubCookie? http://www.washington.edu/pubcookie/ -- Bill Moseley [EMAIL PROTECTED]
Re: Authorization question
Jean-Michel Hiver wrote: Yes, but you're then making the authorization layer inseparable from your applicative layer, and hence you loose the interest of using separate handlers. It's pretty hard to truly separate these things. Nobody wants to use basic auth, which means there is a need for forms and handlers. Then you have to keep that information in either cookies or URLs, and there is usually a need to talk to an external data database with a site-specific schema. The result is that plug and play auth schemes only work (unmodified) for the simplest sites. - Perrin
Re: Authorization question
On Thu, 27 Feb 2003, Jean-Michel Hiver wrote:
> > I think this may be solved by architecture. If you have an Authz layer
> > maybe it needs to be called sooner than right when you need it.
> >
> > I have a Session-based auth system. When the user successfully
> > authenticates the Auth handler does a lookup in a db where we store all
> > users' authz information. The db has an access level for each user for
> > each widget in the application. These are all loaded into a hashref and
> > stored in the serverside session. An encrypted cookie has the key to the
> > session.
>
> Yes, but you're then making the authorization layer inseparable from
> your applicative layer, and hence you loose the interest of using
> separate handlers.
True. For the type of application I deal with, where authorization levels
and security are paramount, this is not a bad thing. And really, in my
system, the UI modules only need to know the user's authz level (0-4) to
produce content ... they do not care how the authz level was generated.
- nick
--
Nick Tonkin {|8^)>
Re: Authorization question
> I think this may be solved by architecture. If you have an Authz layer > maybe it needs to be called sooner than right when you need it. > > I have a Session-based auth system. When the user successfully > authenticates the Auth handler does a lookup in a db where we store all > users' authz information. The db has an access level for each user for > each widget in the application. These are all loaded into a hashref and > stored in the serverside session. An encrypted cookie has the key to the > session. Yes, but you're then making the authorization layer inseparable from your applicative layer, and hence you loose the interest of using separate handlers. I think it would be much nicer to write webapps on which you can plug any authorization / authentication handler chain and maintain those things as separate as possible. Then if your application uses the REST paradigm, all access control can be done using URIs, which is very neat. Cheers, -- Building a better web - http://www.mkdoc.com/ - Jean-Michel Hiver [EMAIL PROTECTED] - +44 (0)114 255 8097 Homepage: http://www.webmatrix.net/
Re: Authorization question
but DECLINED is almost certainly a bad idea. What was the idea behind return DECLINED if $r->is_inital_req; in auth handlers in the first place? I think it stems from the Eagle book, thus from Doug, but I'm not sure - I can't remember exactly. it was probably an attempt to reduce overhead for subrequests when authentication is expensive (say, a DB query) and you don't really care about whether lookups are authenticated or not. I tried to word it carefully in the book, saying using it depends on what you want to do in your application. clearly if you want to depend on proper authentication for lookups, then you don't want to use is_initial_req() logic at all. it wasn't until after it was too late that I realized DECLINED is problematic. my own particular problem with it was with the subrequests that mod_dir makes - IIRC, on a protected directory returning DECLINED on the subrequest really mucks things up. HTH --Geoff
Re: Authorization question
On Thu, 27 Feb 2003, Geoffrey Young wrote:
> I've decided that the
>
>return DECLINED if $r->is_inital_req;
>
> bit is a bad idea. after a few hours debugging an authorization
> application, I realized that this does nothing but cause problems - if you
> DECLINE a subrequest then it's picked up by mod_auth which, if you're not
> configured for flat file auth (in addition to your custom auth), mod_auth
> will return AUTH_REQUIRED (or worse).
>
> you may want to
>
>return OK if $r->is_inital_req;
>
> but DECLINED is almost certainly a bad idea.
What was the idea behind
return DECLINED if $r->is_inital_req;
in auth handlers in the first place?
- nick
--
Nick Tonkin {|8^)>
Re: Authorization question
On Thu, 27 Feb 2003, Jean-Michel Hiver wrote:
> Hi List,
>
> In theory Authentication / Authorization handlers are very cool, because
> the application underneath it doesn't need to know the logic of it, and
> as long as you design web applications with nice, RESTful, sensible URIs
> it would all work beautifully.
>
> BUT, I cannot figure out how to 'ask' apache wether a request would
> succeed or not. I'm wondering wether there would be a way to do:
>
> my $ok = $r->would_be_authorized ($uri);
>
> # or
> my $ok = $r->would_be_authorized ($uri, 'GET');
>
> # or
> my $ok = $r->would_be_authorized ($uri, 'POST', $fh);
>
>
> This would be handy because for example in your web application you
> might want certain controls or links to be replaced by proper messages
> rather than directing the user to a location that he/she doesn't have
> access to.
>
> If I missed something obvious please point out a URI so that I can RTFM!
> All ideas appreciated!
Salut,
I think this may be solved by architecture. If you have an Authz layer
maybe it needs to be called sooner than right when you need it.
I have a Session-based auth system. When the user successfully
authenticates the Auth handler does a lookup in a db where we store all
users' authz information. The db has an access level for each user for
each widget in the application. These are all loaded into a hashref and
stored in the serverside session. An encrypted cookie has the key to the
session.
All of this is tied into the UI such that the user's authz level
determines the content they see. Data such as '$student->first_name' are
displayed by a UI handler according to perms; the UI's methods can write
out either:
"First Name: $val" or
"First Name: " or
whatever, depending on the user's perms.
HTH,
- nick
--
Nick Tonkin {|8^)>
Re: Authorization question
Jean-Michel Hiver wrote:
On Thu 27-Feb-2003 at 11:39:32AM -, Richard Clarke wrote:
I've never had any reason to do this so there might be a shortcut but I
think something along the lines of the following should work (As long as
your access/auth handler doesnt make use of $r->is_intial_req())
I've decided that the
return DECLINED if $r->is_inital_req;
bit is a bad idea. after a few hours debugging an authorization
application, I realized that this does nothing but cause problems - if you
DECLINE a subrequest then it's picked up by mod_auth which, if you're not
configured for flat file auth (in addition to your custom auth), mod_auth
will return AUTH_REQUIRED (or worse).
you may want to
return OK if $r->is_inital_req;
but DECLINED is almost certainly a bad idea.
use Apache::Constants (:common);
my $subr = $r->lookup_uri('/new/request/?foo=bar');
my $status = $subr->status;
my $ok = $status==AUTH_REQUIRED ? 0:1;
I'd change that to
my $ok = $status == HTTP_OK ? 1 : 0;
since there are lots of other things that can be thrown other than
AUTH_REQUIRED - for instance FORBIDDEN from an access handler.
we talk about this in Recipe 3.15 in the Cookbook (which came up yesterday,
so see the archives for where you can find it for free).
Wow! Thanks for the tip :)
Is there a way to tell Apache::SubRequest that you're doing a HEAD / GET
/ POST / PUT / etc? Authorization handlers might behave differently
depending on the HTTP method being used.
unfortunately, no - GET is hardcoded in Apache:
API_EXPORT(request_rec *) ap_sub_req_lookup_uri(const char *new_file,
const request_rec *r)
{
return ap_sub_req_method_uri("GET", new_file, r);
}
and by the time you get the subrequest object back, it's too late to call
$sub->method('POST'). of course, theoretically GET and HEAD should be
equivalent :) but I see your point. I guess there's no way around that in
this case.
--Geoff
Re: Authorization question
On Thu 27-Feb-2003 at 11:39:32AM -, Richard Clarke wrote:
> I've never had any reason to do this so there might be a shortcut but I
> think something along the lines of the following should work (As long as
> your access/auth handler doesnt make use of $r->is_intial_req())
>
> use Apache::Constants (:common);
> my $subr = $r->lookup_uri('/new/request/?foo=bar');
> my $status = $subr->status;
> my $ok = $status==AUTH_REQUIRED ? 0:1;
Wow! Thanks for the tip :)
Is there a way to tell Apache::SubRequest that you're doing a HEAD / GET
/ POST / PUT / etc? Authorization handlers might behave differently
depending on the HTTP method being used.
Cheers,
--
Building a better web - http://www.mkdoc.com/
-
Jean-Michel Hiver
[EMAIL PROTECTED] - +44 (0)114 255 8097
Homepage: http://www.webmatrix.net/
Re: Authorization question
I've never had any reason to do this so there might be a shortcut but I
think something along the lines of the following should work (As long as
your access/auth handler doesnt make use of $r->is_intial_req())
use Apache::Constants (:common);
my $subr = $r->lookup_uri('/new/request/?foo=bar');
my $status = $subr->status;
my $ok = $status==AUTH_REQUIRED ? 0:1;
Ric.
- Original Message -
From: "Jean-Michel Hiver" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, February 27, 2003 10:42 AM
Subject: Authorization question
> Hi List,
>
> In theory Authentication / Authorization handlers are very cool, because
> the application underneath it doesn't need to know the logic of it, and
> as long as you design web applications with nice, RESTful, sensible URIs
> it would all work beautifully.
>
> BUT, I cannot figure out how to 'ask' apache wether a request would
> succeed or not. I'm wondering wether there would be a way to do:
>
> my $ok = $r->would_be_authorized ($uri);
>
> # or
> my $ok = $r->would_be_authorized ($uri, 'GET');
>
> # or
> my $ok = $r->would_be_authorized ($uri, 'POST', $fh);
>
>
> This would be handy because for example in your web application you
> might want certain controls or links to be replaced by proper messages
> rather than directing the user to a location that he/she doesn't have
> access to.
>
> If I missed something obvious please point out a URI so that I can RTFM!
> All ideas appreciated!
>
> Cheers,
> --
> Building a better web - http://www.mkdoc.com/
> -
> Jean-Michel Hiver
> [EMAIL PROTECTED] - +44 (0)114 255 8097
> Homepage: http://www.webmatrix.net/
>
>
>
Re: Authorization question and subdirectories
sterling <[EMAIL PROTECTED]> writes: > On 16 May 2001, Chris Strom wrote: > > > Mike Cameron <[EMAIL PROTECTED]> writes: > > > > > Is it possible to have the same PerlAuthzHandler use different require's > > > > > > on a subdirectory once a user has been authorized for a parent > > > directory? Here is what i would like to be acle to do: > > > > > > > > > SetHandler perl-script > > > AuthType MyAuth > > > AuthName MyAuth > > > PerlAuthenHandler MyAuth->authenticate > > > PerlAuthzHandler MyAuth->authorize > > > require valid-user > > > > How about: > > > > require valid-user administrator > > > > > > no - he just wants valid-user for the root location The MyAuth::authorize handler can be modified to reject user administrator unless the URI matches ^/admin (or whatever it was, sorry I cut that off in my earlier reply). > > > > > > > > > > shouldn't this be ? > > > > > no. > I'm pretty sure that it should be. This closes the tag. > > > sterling
Re: Authorization question and subdirectories
I got it working alright with the directive as follows SetHandler perl-script AuthType Consignline AuthName NONE PerlAuthenHandler Consignline::Shop::User PerlAuthzHandler Consignline::Shop::User->authorize require valid-user PerlHandler Consignline::Shop PerlSetVar DEBUG 6 PerlSetVar Config /home/user/Consignline.pm AuthName Admin require user administrator AuthName affiliate require group affiliate will the above not work the same using the location directive? It didn't for me unless I missed something obvious. Thanks for your responses. Chris Strom wrote: > Mike Cameron <[EMAIL PROTECTED]> writes: > > > Is it possible to have the same PerlAuthzHandler use different require's > > > > on a subdirectory once a user has been authorized for a parent > > directory? Here is what i would like to be acle to do: > > > > > > SetHandler perl-script > > AuthType MyAuth > > AuthName MyAuth > > PerlAuthenHandler MyAuth->authenticate > > PerlAuthzHandler MyAuth->authorize > > require valid-user > > How about: > > require valid-user administrator > > > > > shouldn't this be ? > > > > > > > SetHandler perl-script > > AuthType MyAuth > > AuthName MyAuthSupertight > > PerlAuthenHandler MyAuth->authenticate > > PerlAuthzHandler MyAuth->authorize > > require user administrator > > > > > > authenticate is working fine and when I debug the $r->requires in > > authorize it only returns the 'valid user' requirement and not the "user > > > > administrator" requirement even when i access /restricted. Right now > > the code in authorize just prints the requirements via $r->log_error() > > then returns OK; What am I missing? Why doesn't authorize see the > > second requirement for the URI /restricted?
Re: Authorization question and subdirectories
On 16 May 2001, Chris Strom wrote: > Mike Cameron <[EMAIL PROTECTED]> writes: > > > Is it possible to have the same PerlAuthzHandler use different require's > > > > on a subdirectory once a user has been authorized for a parent > > directory? Here is what i would like to be acle to do: > > > > > > SetHandler perl-script > > AuthType MyAuth > > AuthName MyAuth > > PerlAuthenHandler MyAuth->authenticate > > PerlAuthzHandler MyAuth->authorize > > require valid-user > > How about: > > require valid-user administrator > no - he just wants valid-user for the root location > > > > shouldn't this be ? > no. sterling
Re: Authorization question and subdirectories
Mike Cameron <[EMAIL PROTECTED]> writes: > Is it possible to have the same PerlAuthzHandler use different require's > > on a subdirectory once a user has been authorized for a parent > directory? Here is what i would like to be acle to do: > > > SetHandler perl-script > AuthType MyAuth > AuthName MyAuth > PerlAuthenHandler MyAuth->authenticate > PerlAuthzHandler MyAuth->authorize > require valid-user How about: require valid-user administrator > shouldn't this be ? > > > SetHandler perl-script > AuthType MyAuth > AuthName MyAuthSupertight > PerlAuthenHandler MyAuth->authenticate > PerlAuthzHandler MyAuth->authorize > require user administrator > > > authenticate is working fine and when I debug the $r->requires in > authorize it only returns the 'valid user' requirement and not the "user > > administrator" requirement even when i access /restricted. Right now > the code in authorize just prints the requirements via $r->log_error() > then returns OK; What am I missing? Why doesn't authorize see the > second requirement for the URI /restricted?
