Spring Security
  1. Spring Security
  2. SEC-1350

Javadoc on org.springframework.security.web.authentication.preauth.AbstractPreAuthenticatedProcessingFilter

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 2.0.5, 3.0.0
    • Fix Version/s: 3.0.1
    • Component/s: Docs and Website
    • Labels:
      None
    • Environment:
      all

      Description

      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);

        Activity

        Hide
        Luke Taylor added a comment -

        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?

        Show
        Luke Taylor added a comment - 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?
        Hide
        Luke Taylor added a comment -

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

        Show
        Luke Taylor added a comment - I've added some extra Javadoc to clarify the situation if credentials are null and the standard provider is in use.

          People

          • Assignee:
            Luke Taylor
            Reporter:
            David
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: