I'd like to add to this. While I am in favor of this feature and still intend to submit the patch, I'm not sure it really makes sense in your case.
Are browser users and api users really hitting the same urls? What should happen when the user doesn't provide credentials? A browser user expects a redirect but an api client expects a 401. You need a way to handle that. My use case involves allowing basic auth, oauth, and a legacy header-based method but I'm not sure that I see how combining basic and form makes sense. Wouldn't you end up needing to look at user agent or something to figure out what sort of response to send? -Jared Jared Bunting <[email protected]> wrote: I wrote some code to do this awhile back. I won't be back at my computer till morning but I think I should still have it. If I find it, I'll send it. >From what I recall though, I did what you said not to Les...I allowed every request to fall through. The way I see it, the basic and form filters currently do two things - allow a user to login, and enforce that the user must be logged in to proceed. I simply turned off the second thing, and let my authorization level handle that. -Jared Les Hazlewood <[email protected]> wrote: My recommendation would be to add some feature/property that triggered allowing the request through the chain, even though the authentication conditions haven't been met. That way, one filter doesn't need to know about another. But that trigger should only ever work if we know that they're visiting a login page - not just any request should fall through. Maybe something like what the PassthruAuthenticationFilter and/or FormAuthenticationFilter does with their calls to the superclass 'isLoginRequest' method. As always, patches are appreciated :) Les On Wed, Apr 20, 2011 at 5:21 PM, Dan Diephouse <[email protected]> wrote: > Any suggestions? I was just looking through the code. While it's clean and > all, I'm trying to figure out a way to do this without ripping everything > apart :-) > Dan > > On Wed, Apr 20, 2011 at 2:39 PM, Les Hazlewood <[email protected]> > wrote: >> >> The trick would be to make this flow cleanly. BASIC and Form >> authentication are different concerns, and if you'd want to make them >> work together, a pluggable approach would be ideal (instead of either >> 'knowing' about the other and writing convoluted code to support >> that). For example, it should work just as well if you'd want to >> enforce HTTP digest authentication + Form authentication as a >> backup... >> >> On Wed, Apr 20, 2011 at 1:43 PM, Dan Diephouse <[email protected]> wrote: >> > Yeah, this is pretty much what I'm thinking as well. >> > >> > On Sun, Apr 17, 2011 at 10:46 AM, Jared Bunting >> > <[email protected]> wrote: >> >> >> >> I would suggest that BasicHttpAuthenticationFilter have an option to >> >> enable the following workflow: >> >> >> >> If user presents authentication info, attempt to validate it, if it >> >> fails >> >> return authorization challenge. >> >> If user does not present authentication info, pass the request through. >> >> If subsequent processing throws an UnauthenticatedException, then >> >> return >> >> the authorization challenge. >> >> >> >> I would suggest something similar with the FormAuthenticationFilter >> >> (although I am less familiar with it). Only block access if the user >> >> attempts to authenticate and fails, otherwise only challenge if an >> >> UnauthenticatedException is thrown. >> >> >> >> >> >> -Jared >> >> >> >> -----Original Message----- >> >> From: [email protected] on behalf of Les Hazlewood >> >> Sent: Sun 4/17/2011 1:08 PM >> >> To: [email protected] >> >> Cc: Dan Diephouse >> >> Subject: Re: Allowing form or basic auth, logouts >> >> >> >> For https://issues.apache.org/jira/browse/SHIRO-283, how do you >> >> propose that would work? >> >> >> >> In the BasicHttpAuthenticationFilter, if the Subject is not >> >> authenticated, the BASIC challenge is sent as a response and the >> >> Filter chain is not allowed to continue. >> >> >> >> How would the BasicHttpAuthenticationFilter (or a variant of it) know >> >> to let the request pass through to a form instead of send the >> >> challenge? >> >> >> >> Regards, >> >> >> >> Les >> >> >> >> On Sat, Apr 16, 2011 at 10:21 PM, Dan Diephouse <[email protected]> >> >> wrote: >> >> > Here are the JIRAs: >> >> > https://issues.apache.org/jira/browse/SHIRO-283 >> >> > https://issues.apache.org/jira/browse/SHIRO-284 >> >> > Thanks for the response, >> >> > Dan >> >> > >> >> > On Fri, Apr 15, 2011 at 11:16 AM, Les Hazlewood >> >> > <[email protected]> >> >> > wrote: >> >> >> >> >> >> Hi Dan, >> >> >> >> >> >> On Thu, Apr 14, 2011 at 4:30 PM, Dan Diephouse <[email protected]> >> >> >> wrote: >> >> >> > I have two probably basic questions. >> >> >> > 1) I want to allow users to do either form OR basic >> >> >> > authentication. I >> >> >> > can >> >> >> > only see how to allow one at a time or both. Is this possible? >> >> >> >> >> >> It would be possible if you wrote a custom AuthenticatingFilter to >> >> >> do >> >> >> this. You'd essentially need to merge the logic of >> >> >> BasicHttpAuthenticationFilter and FormAuthenticationFilter where you >> >> >> 'fallback' to a form if there are no authentication headers. Could >> >> >> you please create a Jira issue for this? Also, if you do any work >> >> >> on >> >> >> something like this, I'd love to see it! >> >> >> >> >> >> > 2) Does Shiro have a logout filter? Just wondering if there is an >> >> >> > out >> >> >> > of >> >> >> > the >> >> >> > box url I can hit to do a logout for a user. >> >> >> >> >> >> Now that I think about it, I'm surprised that we don't have this out >> >> >> of the box - it would be _incredibly_ easy to write. We'd just have >> >> >> to >> >> >> >> >> >> 1. Subclass PathMatchingFilter >> >> >> 2. Call subject.logout in the onPreHandle method implementation >> >> >> 3. Redirect to a configured 'redirectUrl' property. >> >> >> >> >> >> And that's it. Can you please add a Jira issue for this?
