If you'd like to see it in Shiro, please create a Jira request - it will be lost in mailing list threads otherwise.
Cheers, -- Les Hazlewood | @lhazlewood CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282 On Wed, Jan 15, 2014 at 4:27 AM, Bai Shen <[email protected]> wrote: > That's the problem I was having. I have my authentication filter next in > the chain, and I need to skip it. An OPTIONS request would hit that filter > and be denied since there is no user info yet. > > The CORSFilter is now part of Tomcat. Since 7.0.41, I believe. The > documentation is here. > > https://tomcat.apache.org/tomcat-7.0-doc/config/filter.html > > > > > On Tue, Jan 14, 2014 at 6:56 PM, Les Hazlewood <[email protected]> > wrote: >> >> if isAccessAllowed returns true, then that filter will allow the request >> to continue down to the filter chain (down to any other filters behind it, >> or the terminal servlet or JSP). >> >> Do you have a link to the CORSFilter? We could include it in Shiro in a >> future release (please open a Jira issue if you'd like to see this so the >> issue is not lost). >> >> Cheers, >> >> -- >> Les Hazlewood | @lhazlewood >> CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282 >> >> >> On Tue, Jan 14, 2014 at 12:34 PM, Bai Shen <[email protected]> >> wrote: >>> >>> And that prevents Shiro from continuing down the filter chain? >>> >>> What I ended up doing and has been working so far was using Tomcat 7's >>> new CORSFilter. It handles the OPTIONS call itself and therefore I don't >>> have to worry about Shiro authentication. >>> >>> >>> On Tue, Jan 14, 2014 at 3:32 PM, Les Hazlewood <[email protected]> >>> wrote: >>>> >>>> You can override the AuthenticationFilter#isAccessAllowed method to >>>> return true for your scenario (and super.isAccessAllowed for all others). >>>> >>>> HTH, >>>> >>>> -- >>>> Les Hazlewood | @lhazlewood >>>> CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282 >>>> >>>> >>>> On Tue, Jan 14, 2014 at 5:02 AM, Bai Shen <[email protected]> >>>> wrote: >>>>> >>>>> I'm using Shiro to protect my server. I'm making CORS requests to the >>>>> server, which causes an OPTIONS call to be made before my method call. >>>>> Because my user isn't authenticated yet, the OPTIONS call gets a 401 code >>>>> returned and my method call is never made. >>>>> >>>>> I can't use HttpMethodPermissionFilter as that deals solely with >>>>> permissions and requires a logged in user. I've tried writing my own >>>>> filter >>>>> to recognize the OPTIONS call and allow it to pass unauthenticated, but >>>>> the >>>>> filter chain always continues to my authentication filter and fails there >>>>> with the 401 response. >>>>> >>>>> How do I stop the chain from continuing or tell the authentication >>>>> filter that it's okay to allow an unauthenticated user access? >>>>> >>>>> Thanks. >>>> >>>> >>> >> >
