If possible, it would help me greatly if we could come up with a quick list of 'requirements' of what we'd like to solve. Any ideas?
Thanks again, Les On Mon, Sep 19, 2011 at 6:48 PM, Les Hazlewood <[email protected]> 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 > <[email protected]> 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
