Ok, that was just way to obvious for me. That works perfectly. Thanks!!! Dan
On Thu, Apr 21, 2011 at 8:26 AM, Jared Bunting < [email protected]> wrote: > 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 > > > -- Dan Diephouse http://netzooid.com/blog
