Announcement Announcement Module
Collapse
No announcement yet.
AbstractProcesingFilter.requiresAuthentication() and servlets... Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • AbstractProcesingFilter.requiresAuthentication() and servlets...

    Hi!

    I have been working on integrating the new spring-security release into my app. I did a small "sandbox" example to familiarize myself with all the declarative security goodies and everything worked great. When I tried to incorporate security into my larger application though, I ran into a problem. Rather than a having a simple war file with just one serlvet (mapped to server "/*" requests) I have my servlets mapped to specific patters ("/session", "/admin", and "/api"). /admin is the servlet that I am trying to secure via spring security, and it is the servlet that will server my custom login page. This setup was not working for some reason.

    I stepped through the code and found that the culprit was the default implementation of "requiresAuthentication()". This method reads as follows:


    protected boolean requiresAuthentication(HttpServletRequest request, HttpServletResponse response) {
    String uri = request.getRequestURI();
    int pathParamIndex = uri.indexOf(';');

    if (pathParamIndex > 0) {
    // strip everything after the first semi-colon
    uri = uri.substring(0, pathParamIndex);
    }

    if ("".equals(request.getContextPath())) {
    return uri.endsWith(filterProcessesUrl);
    }

    return uri.endsWith(request.getContextPath() + filterProcessesUrl);
    }


    This method does not account for the fact that my URL, "platform/admin/j_spring_security_check", needs to be authenticated! If there is a context path, this method checks for "platform/j_spring_security_check" and does not authenticate if this is not the URL.

    My fix for this was to make my own subclass to overide that method with this one:

    protected boolean requiresAuthentication(
    HttpServletRequest request, HttpServletResponse response)
    {
    String uri = request.getRequestURI();
    int pathParamIndex = uri.indexOf(';');

    if (pathParamIndex > 0) {
    // strip everything after the first semi-colon
    uri = uri.substring(0, pathParamIndex);
    }

    return uri.endsWith(getFilterProcessesUrl());
    }


    Which basically just ignores the context string. My question is, is there another way to do this? Is this a bug in the original method? Is there something I should be concerned about in circumventing the context string check?

    -Brian

  • #2
    I'm not quite sure what the problem is here. The login is handled by a filter, which by default processes the URL "/j_spring_security_check", so if you render the login page with

    Code:
    request.getContextPath() + "/j_spring_security_check"
    as the form action, then that should be all that's required. The servlet mapping shouldn't really make any difference.

    Comment


    • #3
      The problem is that

      request.getContextPath() + "/j_spring_security_check"

      doesn't map to anything in my war file because I have no "/*" url mapping in my web.xml. All 3 of the servlets that I have configured actually map to a servlet name (and not doing so breaks something else). The result is that tomcat doesn't even direct me to a filter because it knows that /platform/j_spring_security_check doesn't map to a servlet whereas /platform/(admin|api|session)/j_spring_security_check does.

      Comment


      • #4
        Ok, I see what you mean. So if you set the filterProcessesUrl property to "/admin/j_security_check" won't that do the trick?

        Comment


        • #5
          ah ha! That raises another question that I have. I am sure that would work, so my question now is this: is there a way for me to set the attributes on a filter that is configured using the security namespace, or do I need to continue to declare a separate filter of my own?

          Comment


          • #6
            Obviously you can only set the properties that are supported by namespace attributes - you can find these by using a decent XML editor and the schema file. Otherwise you would declare a custom filter.

            The "login-processing-url" on the form-login element can be used to set the URL which handles the login.

            Comment


            • #7
              Thanks Luke!! Very helpful.

              Comment

              Working...
              X