Small knowledge, big challenge! This article is participating in the creation activity of “Essential Tips for Programmers”
Foreword: today at the time of building project implementation before and after the separation, the front-end VUE is what I use is nginx make local disk as a service, the back-end using SpingBoot use jar packages on the server to start the project, the problem is this: the front can be given access to the backend interface, and then when they need to access interface to access to cross-domain anomalies.
Specific withdrawal: Because the permission is set on the back-end, the user must log in and the current user token permission contains the permission to access the interface. However, if no token is found in the request header during back-end interception, the request is illegal. I checked the front-end printing and request containing the corresponding token. During the request, the browser also sent an OPTIONS request to the back-end interface. There was no token information in the request, and the token value printed in the back-end log was NULL, throwing an exception. Therefore, none of the above problems exist before the interceptor is added, it is normal, so do not worry about the front-end problems, the problem must be in the back end, specifically the interceptor.
Understand the problem principle: In the case of complex CROS requests, an OPTIONS request will be sent first for sniffing to test whether the server supports the request. After the request succeeds, the real request will be sent. The OPTIONS request does not carry any data. If the request does not comply with our interceptor’s verification rules, it will be returned directly. The response header also does not carry the header information needed to solve the cross-domain problem, resulting in cross-domain problems. Therefore, in the browser, we find that the request does not carry the token, and the token is null in the backend log.
To solve
OPTIONS request resolution
We can allow OPTIONS requests directly from the back end
/ / whether the request for the requests of the OPTIONS, if is the direct release the if (" OPTIONS ". The equals (it. GetMethod (). The toUpperCase ())) {return true; }Copy the code
After the request is intercepted, the token is empty
In this case, we need the interceptor Filter described earlier to implement
package com.wzy.member.config; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; import org.springframework.web.cors.CorsConfiguration; import org.springframework.web.cors.UrlBasedCorsConfigurationSource; import org.springframework.web.filter.CorsFilter; @Configuration public class MyCorsConfig { @Bean public CorsFilter corsFilter() { CorsConfiguration config = new CorsConfiguration(); config.addAllowedOrigin("*"); config.setAllowCredentials(true); config.addAllowedMethod("*"); config.addAllowedHeader("*"); config.addExposedHeader("token"); UrlBasedCorsConfigurationSource configSource = new UrlBasedCorsConfigurationSource(); configSource.registerCorsConfiguration("/**", config); return new CorsFilter(configSource); }}Copy the code
And then we’re done
This is a problem I have encountered in my work. If you have any other problems about cross-domain, please leave a message in the comment section.