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 thi
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.
> >
> > I
> 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 ta
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
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
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 doe
> 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 inf
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
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
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
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 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::Cons
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 ques
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' a
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
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
PerlSetV
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:
> >
> >
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
> AuthN
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
PerlAuthzH
19 matches
Mail list logo
