shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jared Bunting <>
Subject Re: SHIRO-283 design: supporting both Form & BASIC authc simultaneously
Date Wed, 04 Jan 2012 03:55:16 GMT
Well, I thought that I had replied to this, but it doesn't appear that I

The difference is that, if AUTH information is provided it is accepted. 
If it is not and the application later throws an "UnauthorizedException"
then the filter will perform the challenge method.

That being said, your explanation of the contract of the
AuthenticatingFilter makes sense.  Since I'm not really sure of a better
way of solving this without significant change to the filters, I'm fine
with removing this and revisiting with composition-based filters in a
later release.


On 09/19/2011 08:48 PM, Les Hazlewood wrote:
> I'm revisiting this in an effort to resolve it for 1.2, but I have
> some questions:
> It is not readily apparent to me why the 'permissive' flag exists (it
> has been a month, forgive me).  Doesn't it basically just ignore the
> authc check and allow the request to pass through no matter what,
> thereby invalidating its security purpose?  If so, what is the benefit
> of doing this?
> At the moment with my little understanding this has the feeling of a
> workaround rather than a 'correct' solution (which is sometimes ok,
> but I'd prefer to have the latter in an actual release if at all
> possible).
> Thanks,
> Les
> On Mon, Aug 15, 2011 at 10:51 AM, Jared Bunting
> <> wrote:
>> On 08/15/2011 11:48 AM, Les Hazlewood wrote:
>>> It might also be helpful to think about this in a general sense,
>>> without being too coupled to Form + BASIC.
>>> I believe the problem we're trying to solve is:
>>> 1.  I don't care how my user is authenticated - just that they are
>>> authenticated.
>>> 2.  If they're not authenticated yet, I want them to be authenticated
>>> via one of X, Y or Z (or more) means.
>>> It might be better to come up with a mechanism for this rather than
>>> focusing on Form + BASIC details specifically (e.g. throw X.509 into
>>> the mix or something else).
>> I agree on coming up with a more general solution.  I feel like this
>> problem is a subset of another problem, and perhaps related to yet another.
>> 3. At this particular filter level, I don't care if my user is
>> authenticated.
>> (I'm using AOP to do authorization in my application code, and there's a
>> decent chance that certain required permissions are assigned to the
>> anonymous-user or some functionality may not even have authorization
>> requirements).
>> I'm all for a general solution, and something composition-oriented
>> sounds great.  I think what I'm interested in is separating the logic of
>> "authenticate" from "guarantee user is authenticated".
>> Thanks,
>> Jared

View raw message