403 problem after configuring https

403 problem after configuring https

Maintaining an old project, after configuring https, the post request always responds to 403.

The known request process is: https=>nginx=>http=>tomcat

View the nginx log, the request is normally received and proxied, and the 403 is responded by the upper application

Check the tomcat log, the request is received and responded normally, and the 403 is responded by the business application

Check the application log, only see the output of Shiro's Found Cookie, and the target method does not have any log printing, indicating that the request has entered the application, and a 403 is directly responded by somewhere in the application

Comparing the client's http request header and https request header, it is found that there is an extra origin in the https request header. In nginx, the proxy_set_header Origin http://xxxx.xxx.comclient's https request is forced to be set as an http request, and the business responds normally.

It can be seen that this problem is a cross-domain problem:

When our browser makes a cross-site request, a well-behaved server will verify that the current request is from an allowed site. The server is judged by the value of the Origin field.
When the configuration of the server is wrong, such as configuring https://baidu.com/, it may cause some incomprehensible problems.
For example, some browsers (IE) can request success, while some browsers fail to request (Chrome). This is not because the previous browser behaved correctly, but because the previous browser did not bring the Origin with the request and the latter browser brought the correct Origin. On the server side, because there is no Origin Header, it is considered that this is not a CORS request, so no CORS verification is performed. This in turn requires the server to force the request to bring the Origin Header to further ensure the security of the server.

Check the cross-domain configuration in the project, and see the following configuration in web.xml:

<filter>
    <filter-name>shiroFilter</filter-name>
    <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
  </filter>
  <filter-mapping>
    <filter-name>shiroFilter</filter-name>
    <url-pattern>/*</url-pattern>
  </filter-mapping>
  
   <filter>
    <filter-name>CorsFilter</filter-name>
    <filter-class>org.apache.catalina.filters.CorsFilter</filter-class>
    <init-param>
      <param-name>cors.allowed.methods</param-name>
      <param-value>GET,POST,HEAD,OPTIONS,PUT</param-value>
    </init-param>
    <init-param>
      <param-name>cors.allowed.headers</param-name>
      <param-value>Access-Control-Allow-Origin,Content-Type,X-Requested-With,accept,Origin,Access-Control-Request-Method,Access-Control-Request-Headers</param-value>
    </init-param>
  </filter>
  <filter-mapping>
    <filter-name>CorsFilter</filter-name>
    <url-pattern>/*</url-pattern>
  </filter-mapping>

org.apache.catalina.filters.CorsFilter is used for cross-domain settings, and its parameters can be set as follows:

Then add allow-origins to the cros configuration:

<filter>
    <filter-name>CorsFilter</filter-name>
    <filter-class>org.apache.catalina.filters.CorsFilter</filter-class>
    <init-param>
      <param-name>cors.allowed.methods</param-name>
      <param-value>GET,POST,HEAD,OPTIONS,PUT</param-value>
    </init-param>
    <init-param>
      <param-name>cors.allowed.origins</param-name>
      <param-value>*</param-value>
    </init-param>
    <init-param>
      <param-name>cors.allowed.headers</param-name>
      <param-value>Access-Control-Allow-Origin,Content-Type,X-Requested-With,accept,Origin,Access-Control-Request-Method,Access-Control-Request-Headers</param-value>
    </init-param>
  </filter>

The shiro output can be seen in the application log because in the filter configuration, shiro comes first and cros comes after. The request is intercepted at cros and responds with 403!