Announcement Announcement Module
Collapse
No announcement yet.
Intercept Oauth Access Token Respone Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Intercept Oauth Access Token Respone

    Hi,
    How can i set an additional http header in Oauth access token response when client access the /oauth/authorize URL to get the
    access Token?

  • #2
    What's the use case? A completely generic cross-cutting use case could be implemented using a ServletFilter - you can add headers as much as you want there. But what information do you need to put in the header?

    Comment


    • #3
      As per the use-case a Http Header is needed at client end with every http response. I wrote a Servlet filter just to intercept every response and it works fine for service responses but not for oauth access-token response.

      e.g.
      http://domain/context/service/employees returns expected response with header value but
      http://domain/context/oauth/authorize doesn't return header value but it returns oauth-acccess token

      Can you please let me know if there is any other way to intercept access-token http response? I tried to override Oauth2AuthorizationFilter but it couldn't work.

      Thanks for the reply.

      Comment


      • #4
        I guess maybe your filter is too late in the chain and the OAuth2 filter doesn't call chain.doFilter(). (The implementation of these endpoints will change soon, by the way, so this won't be a problem.) Probably it's easy to work around - e.g. can you just change the declaration order of your filters in web.xml?

        Comment


        • #5
          filters reordering in web.xml doesn't make any difference. here is the filter ordering in web.xml. I tried to change filter orders but no luck.

          <filter>
          <filter-name>springSecurityFilterChain</filter-name>
          <filter-class>org.springframework.web.filter.DelegatingFil terProxy</filter-class>
          </filter>

          <filter>
          <filter-name>postProcess</filter-name>
          <filter-class>com.filter.ResponseFilter</filter-class>
          </filter>

          <filter-mapping>
          <filter-name>springSecurityFilterChain</filter-name>
          <url-pattern>/*</url-pattern>
          </filter-mapping>

          <filter-mapping>
          <filter-name>postProcess</filter-name>
          <url-pattern>/*</url-pattern>
          </filter-mapping>

          Comment


          • #6
            It probably depends on the implementation of your filter. I would expect you would have to put your filter first to ensure that it is called. Does it only act at the end of the chain? Can you share the implementation?

            Comment


            • #7
              public class ResponseFilter implements Filter{

              @Override
              public void doFilter(ServletRequest request, ServletResponse response,
              FilterChain chain) throws IOException, ServletException {
              HttpServletResponse httpResponse = (HttpServletResponse)response;
              httpResponse.setHeader("Language", "English");
              chain.doFilter(request, response);
              }
              }

              I only want to set a HttpHeader in the response. That's the only requirement for me.

              Comment


              • #8
                That should work if you put it *before* the Spring Security filter then, since the later will be called in chain.doFilter().

                Comment


                • #9
                  It doesn't work even i put the filter before the security filter. One more point i want to add here is the /oauth/authorize/ URL is secured in my app. e.g.

                  <http use-expressions="true" entry-point-ref="basicAuthenticationEntryPoint">
                  <intercept-url pattern="/oauth/authorize" access="ROLE_USER"/>
                  <intercept-url pattern="/app/**" access="ROLE_USER" />
                  </http>


                  does it impacts the filter ordering??

                  Comment


                  • #10
                    Well, I can't really explain the filter behaviour yet (maybe if you can show the implementation of the filter)?

                    But you almost certainly do not want to use access="ROLE_USER" for the token endpoint - the out-of-the-box SECOAUTH client that uses this endpoint has no state, so it will never work. A custom client would work, but only if it authenticates separately, and in a way not covered by the OAuth2 spec.

                    Aside: I'm not sure how ROLE_USER behaves if you have use-expression="true", but they look incompatible. The use-expression="true" is definitely redundant in the sample you provide, since you don't use any expressions.

                    Comment


                    • #11
                      Thanks for the reply Dave. Yes you are right i am using customized authentication so the access="ROLE_USER" is redundant. But my main concern is
                      filter behavior.You can see my filter implementation as below. I just need to set a HTTP header in response.

                      public class ResponseFilter implements Filter{

                      @Override
                      public void doFilter(ServletRequest request, ServletResponse response,
                      FilterChain chain) throws IOException, ServletException {
                      HttpServletResponse httpResponse = (HttpServletResponse)response;
                      httpResponse.setHeader("Language", "English");
                      chain.doFilter(request, response);
                      }
                      }

                      Comment


                      • #12
                        That should work, so I guess you have a problem with your configuration somewhere (or else in the container, but that would be surprising). Can you debug into the filter chain and see why this filter is not being called? Or put a log statement in at least?

                        Comment

                        Working...
                        X