The parent class's behavior of throwing an exception if the token was null was intended to represent a programming error. There must be a token to authenticate, and if there isn't, it seems that something would be wrong w/ the implementation. Funny enough, this check our own programming ;).
The question for me is - is this the correct behavior? If we change the behavior to allow null return values, and automatically show the access denied page, the security subsystem (Realm and authentication listeners, etc) would never be notified that an authentication attempt was made. Is this ok? Thoughts? Les On Sun, Oct 18, 2009 at 5:18 AM, Peter Ledbrook <[email protected]> wrote: > Hi, > > As reported here: > > http://jira.codehaus.org/browse/GRAILSPLUGINS-869 > > BasicHttpAuthenticationFilter throws an exception if the username or > password are not provided. The problem stems from the filter returning > null from the its createToken() method, whereas AuthenticatingFilter > throws an IllegalStateException if the token is null. > > The reason I'm raising this on the list is because I'm not sure > whether BasicHttpAuthenticationFilter should always produce a valid > authentication token (I have a local fix that takes this approach) or > AuthenticatingFilter should handle a null token gracefully (by denying > access). > > If people agree that the first approach is better, then I'll commit my fix. > > Cheers, > > Peter >
