Remember, this is only for login. I'm assuming that what you mean by UI uses the REST API, you have javascript (or flash, or something client side in the browser that hits the REST api).
If you put the form auth filter on the "web page" portion of your UI, and the http basic filter on the REST portion, then I would imagine the interaction would go like this: Browser User: Hit UI front page (index.html?). Not logged in, redirected to login page by form auth filter. Use UI feature that hits REST api in the background. User is already logged in and therefore doesn't get stopped by the basic filter. Direct API User: Hits REST endpoint, gets stopped by http basic filter, supplies auth credentials, etc. The important thing is to make sure that when your UI hits the REST stuff, the user is already authenticated and to ensure that all sensitive urls are protected by SOMETHING that prevents an unauthenticated user from hitting them. Am I making sense? -Jared On 04/21/2011 10:09 AM, Dan Diephouse wrote: > 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] > <mailto:[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] > <mailto:[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] <mailto:[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] > <mailto:[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] > <mailto:[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] > <mailto:[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] > <mailto:[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] > <mailto:[email protected]> on behalf of Les Hazlewood > >> >> Sent: Sun 4/17/2011 1:08 PM > >> >> To: [email protected] <mailto:[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] > <mailto:[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] <mailto:[email protected]>> > >> >> > wrote: > >> >> >> > >> >> >> Hi Dan, > >> >> >> > >> >> >> On Thu, Apr 14, 2011 at 4:30 PM, Dan Diephouse > <[email protected] <mailto:[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
signature.asc
Description: OpenPGP digital signature
