SEC-1350: Javadoc on org.springframework.security.web.authentication.preauth.AbstractPreAuthenticatedProcessingFilter #1594

Closed
spring-issuemaster opened this Issue Jan 4, 2010 · 2 comments

1 participant

@spring-issuemaster

David (Migrated from SEC-1350) said:

improve javadoc to detail exactly what is expected when overriding the methods for custom pre-auth - while there are a few examples on the web it took a bit of digging to find - my issue was not knowing i had to at least return an empty string from getPreAuthenticatedCredentials() and what object type to return from getPreAuthenticatedPrincipal()

perhaps add a little more detail on the methods to something like:

/**

  • Override to extract the principal information from the current request.
  • return either a String object with the principal name or a subclass of java.security.Principal. */ protected abstract Object getPreAuthenticatedPrincipal(HttpServletRequest request);

/**

  • Override to extract the credentials (if applicable) from the current request. Ensure to return at least an empty string in the case of no credentials, as returning null will cause an exception to be thrown and the pre-authentication filter to fail. */ protected Object getPreAuthenticatedCredentials(final HttpServletRequest request);
@spring-issuemaster

Luke Taylor said:

The pre-authentication framework is very flexible (it's main purpose is for customization), so neither of these assumptions really hold in all cases. We should probably clarify that the standard PreAuthenticationProvider, if used, will reject null credentials, but where does the assertion that the principal must be a String or a Principal instance come from?

@spring-issuemaster

Luke Taylor said:

I've added some extra Javadoc to clarify the situation if credentials are null and the standard provider is in use.

@spring-issuemaster spring-issuemaster added this to the 3.0.1 milestone Feb 5, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment