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. >>>> >>> >>> >> >
