Home  >  Article  >  Web Front-end  >  vue+springboot separates single point cross-domain login between front and back ends

vue+springboot separates single point cross-domain login between front and back ends

php中世界最好的语言
php中世界最好的语言Original
2018-04-13 10:23:392564browse

This time I will bring you vue springboot front-end and back-end separation single point cross-domain login, vue springboot front-end and front-end separation single point cross-domain login What are the precautions, the following is a practical case, Let’s take a look.

Recently I am working on a back-end management system. The front-end uses the popular vue.js, and the back-end is based on springboot. Because the backend system does not have a login function, but the company requires unified login, the login authentication uses the authentication system of the .net project team. That means doing single sign-on. As for students who don’t know what single sign-on is, I suggest you go to the all-purpose Du Niang.

When I first received this requirement, I thought with disdain: Just logging in is not important. However, the development process slapped me hard (a hot slap). . . , so I must record this lesson carefully this time to avoid stepping into such pitfalls in the future.

The first problem I faced was cross-domain. The browser console directly reported CORS. With my many years of development experience, I decisively configured the cross-domain configuration in the background. The code is as follows:

@Configuration
public class CorsConfiguration {
 @Bean
 public WebMvcConfigurer corsConfigurer() {
  return new WebMvcConfigurerAdapter() {
   @Override
   public void addCorsMappings(CorsRegistry registry) {
    registry.addMapping("/**")
      .allowedHeaders("*")
      .allowedMethods("*")
      .allowedOrigins("*");
   }
  };
 }
}

This configuration allows all mappings, all request headers, all request methods, and all sources. After changing the configuration, I decisively restarted the project to see the effect. I found that there was no way to redirect to the single sign-in page. Seeing that the browser error was caused by cross-domain, I first uploaded the code of my login interceptor

public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
 //用户已经登录
 if (request.getSession().getAttribute("user") != null) {
  return true;
 }
 //从单点登录返回之后的状态,本系统还不处于登录状态
 //根据code值去获取access_token,然后再根据access_token去获取用户信息,并将用户信息存到session中
 String state = request.getParameter("state");
 String uri = getUri(request);
 if (isLoginFromSSO(state)) {
  String code = request.getParameter("code");
  Object cacheUrl = request.getSession().getAttribute(state);
  if (cacheUrl == null) {
   response.sendRedirect(uri);
   return false;
  }
  HttpUtil client = new HttpUtil();
  StringBuffer sb = new StringBuffer();
  sb.append("code=").append(code)
    .append("&grant_type=").append("authorization_code")
    .append("&client_id=").append(SSOAuth.ClientID)
    .append("&client_secret=").append(SSOAuth.ClientSecret)
    .append("&redirect_uri=").append(URLEncoder.encode((String) cacheUrl));
  String resp = client.post(SSOAuth.AccessTokenUrl, sb.toString());
  Map<String, String> map = new Gson().fromJson(resp, Map.class);
  //根据access_token去获取用户信息
  String accessToken = map.get("access_token");
  HttpUtil http = new HttpUtil();
  http.addHeader("Authorization", "Bearer " + accessToken);
  String encrypt = http.get(SSOAuth.UserUrl);
  String userinfo = decryptUserInfo(encrypt);
  //封装成user对象
  User user = new Gson().fromJson(userinfo, User.class);
  request.getSession().setAttribute("user", user);
  return true;
 }
 //跳转到单点登录界面
 state = Const._SSO_LOGIN + Const.UNDERLINE + RandomUtil.getUUID();
 request.getSession().setAttribute(state, uri);
 String redirectUrl = buildAuthCodeUrl(uri, state);
 response.sendRedirect(redirectUrl);
 return false;
}

Later, the front-end vue requests the login interface method of the backend directly using

window.location.href=this.$api.config.baseUrl+"/system/user/login"

After the front-end accesses the system, you can jump directly to the single sign-on page. But when I entered my account and password and clicked to log in, I jumped back to the system and found that all request data interfaces could not be accessed normally. Debug found that all requests did not carry user information and were recognized by the interceptor as not logged in, so all requests could not pass. .

Why is it that even though I am logged in, the interceptor also sets user information to the session, why are the cookies gone? I initiated a request again and found that the JsessionId of each request was different. I checked a lot of information and found that I needed to add a configuration that allows authentication information to be added to the front end

axios.defaults.withCredentials=true;

The background also needs to make a corresponding configuration allowCredentials(true);

@Bean
public WebMvcConfigurer corsConfigurer() {
 return new WebMvcConfigurerAdapter() {
  @Override
  public void addCorsMappings(CorsRegistry registry) {
   registry.addMapping("/**")
     .allowedHeaders("*")
     .allowedMethods("*")
     .allowedOrigins("*").allowCredentials(true);
  }
 };
}

After adding this configuration, I ran the operation process again and found that I could jump to the system normally after logging in, and the page data was also displayed normally.

Just when I thought I was done, I suddenly clicked on a page and the data could not be displayed normally. I was so confused. I quickly F12 and found a request method I had never seen before, OPTIONS request. It turned out that this request method was obviously POST. Why did it change? Has it become OPTIONS? So I ordered several other POST requests and found that they all turned into OPTIONS requests. I was confused and quickly checked the information of OPTIONS requests. The Internet said that OPTIONS requests are called "pre-check requests", which means that in your formal Before the request is executed, the browser will first initiate a pre-check request. Only after the pre-check request passes can the formal request be executed. After reading it, I suddenly realized that OPTIONS was intercepted, so I could no longer execute my POST request. Then I just let the pre-check request pass. Just add this judgment to the interceptor

//option预检查,直接通过请求
if ("OPTIONS".equals(request.getMethod())){
 return true;
}

In this way, the interceptor finds that the request is a pre-check request and passes it directly, and then the next POST request can be executed.

I believe you have mastered the method after reading the case in this article. For more exciting information, please pay attention to other related articles on the php Chinese website!

Recommended reading:

Instructions for vue’s project structure

Detailed explanation of vue’s implementation of the small ball parabola effect of the shopping cart

The above is the detailed content of vue+springboot separates single point cross-domain login between front and back ends. For more information, please follow other related articles on the PHP Chinese website!

Statement:
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn