Wicket
  1. Wicket
  2. WICKET-5266

Issue with TomcatWebSocketFilter and Spring Security

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 6.9.0
    • Fix Version/s: 6.10.0, 7.0.0
    • Labels:
      None
    • Environment:
      Tomcat

      Description

      Spring Security has a way of wrapping HTTP servlet requests seems to clash with the code in org.apache.wicket.protocol.ws.tomcat7.Tomcat7WebSocketFilter. The request has to be unwrapped before being cast to RequestFacade.

      Before:

      		((RequestFacade) req).doUpgrade(tomcatWebSocket); // Crashes with class cast exception
      

      Should be:

      		while (req instanceof HttpServletRequestWrapper) {
      			req = (HttpServletRequest) ((HttpServletRequestWrapper) req).getRequest();
      		}
      		((RequestFacade) req).doUpgrade(tomcatWebSocket);
      

      This happens when configuring Spring Security in the web.xml with:

      	<filter>
      		<filter-name>springSecurityFilterChain</filter-name>
      		<filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
      	</filter>
      	<filter-mapping>
      		<filter-name>springSecurityFilterChain</filter-name>
      		<url-pattern>/*</url-pattern>
      	</filter-mapping>
      

        Activity

        Hide
        Martin Grigorov added a comment -

        Which version of Tomcat do you use ?
        I haven't seen ClassCastException or other problem so far in this code.

        Show
        Martin Grigorov added a comment - Which version of Tomcat do you use ? I haven't seen ClassCastException or other problem so far in this code.
        Hide
        Christophe Levesque added a comment -

        I'm seeing it with 7.0.37. I don't think this is related to Tomcat though. Spring (and Spring Security) is usually configured as a "listener" in the web.xml and I believe it will wrap the request before it gets to the Wicket servlet.

        From my web.xml:

        	<listener>
        		<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
        	</listener>
        	<context-param>
        		<param-name>contextConfigLocation</param-name>
        		<param-value>classpath:applicationContext*.xml</param-value>
        	</context-param>
        	<filter>
        		<filter-name>springSecurityFilterChain</filter-name>
        		<filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
        	</filter>
        	<filter-mapping>
        		<filter-name>springSecurityFilterChain</filter-name>
        		<url-pattern>/*</url-pattern>
        	</filter-mapping>
        	<filter>
        		<filter-name>wicket</filter-name>
        		<filter-class>org.apache.wicket.protocol.ws.tomcat7.Tomcat7WebSocketFilter</filter-class>
        		<init-param>
        			<param-name>applicationFactoryClassName</param-name>
        			<param-value>org.apache.wicket.spring.SpringWebApplicationFactory</param-value>
        		</init-param>
        	</filter>
        	<filter-mapping>
        		<filter-name>wicket</filter-name>
        		<url-pattern>/*</url-pattern>
        		<dispatcher>REQUEST</dispatcher>
        		<dispatcher>ERROR</dispatcher>
        	</filter-mapping>
        
        Show
        Christophe Levesque added a comment - I'm seeing it with 7.0.37. I don't think this is related to Tomcat though. Spring (and Spring Security) is usually configured as a "listener" in the web.xml and I believe it will wrap the request before it gets to the Wicket servlet. From my web.xml: <listener> <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class> </listener> <context-param> <param-name>contextConfigLocation</param-name> <param-value>classpath:applicationContext*.xml</param-value> </context-param> <filter> <filter-name>springSecurityFilterChain</filter-name> <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class> </filter> <filter-mapping> <filter-name>springSecurityFilterChain</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> <filter> <filter-name>wicket</filter-name> <filter-class>org.apache.wicket.protocol.ws.tomcat7.Tomcat7WebSocketFilter</filter-class> <init-param> <param-name>applicationFactoryClassName</param-name> <param-value>org.apache.wicket.spring.SpringWebApplicationFactory</param-value> </init-param> </filter> <filter-mapping> <filter-name>wicket</filter-name> <url-pattern>/*</url-pattern> <dispatcher>REQUEST</dispatcher> <dispatcher>ERROR</dispatcher> </filter-mapping>
        Hide
        Martin Grigorov added a comment -

        I still sleep
        It is clear now. Thanks!
        This improvement should be done for all **WebSocketFilters, not just Tomcat's one.

        Show
        Martin Grigorov added a comment - I still sleep It is clear now. Thanks! This improvement should be done for all **WebSocketFilters, not just Tomcat's one.
        Hide
        Christophe Levesque added a comment -

        No worries.

        After playing with it, I realized that it's actually the Spring Security module that wraps the request (not Spring Core). I updated the bug description with the relevant part of the web.xml.

        Show
        Christophe Levesque added a comment - No worries. After playing with it, I realized that it's actually the Spring Security module that wraps the request (not Spring Core). I updated the bug description with the relevant part of the web.xml.
        Show
        Christophe Levesque added a comment - Saw the change on https://git-wip-us.apache.org/repos/asf?p=wicket.git;a=blob_plain;f=wicket-experimental/wicket-native-websocket/wicket-native-websocket-tomcat/src/main/java/org/apache/wicket/protocol/ws/tomcat7/Tomcat7WebSocketFilter.java;hb=HEAD . Thanks for the quick fix!

          People

          • Assignee:
            Martin Grigorov
            Reporter:
            Christophe Levesque
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development