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