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