I hear what you're saying, BUT, both my UI also uses the REST API. So, unless I'm missing something, I may have to settle for less than ideal and just accept that rest clients will be redirected to the login form.
Perhaps though, I could one copy of the API at say, /ui-api which does the form login and another at /api which does basic auth... Dan On Wed, Apr 20, 2011 at 7:13 PM, Jared Bunting < [email protected]> wrote: > 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? > > > -- Dan Diephouse http://netzooid.com/blog
