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'
$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
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
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())
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
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
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
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
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
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
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
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
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
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
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:
Location /
SetHandler perl-script
AuthType MyAuth
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:
Location /
I got it working alright with the Directory directive as follows
Directory /home/user/html/
SetHandler perl-script
AuthType Consignline
AuthName NONE
PerlAuthenHandler Consignline::Shop::User
PerlAuthzHandler Consignline::Shop::User-authorize
require valid-user
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
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:
Location /
SetHandler perl-script
AuthType MyAuth
AuthName MyAuth
PerlAuthenHandler MyAuth-authenticate
19 matches
Mail list logo
