So lösen Sie das domänenübergreifende Single-Sign-On-Problem durch die Trennung des Front-Ends und des Back-Ends von vue+springboot

Der Code lautet wie folgt:

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

Diese Konfiguration ermöglicht alle Zuordnungen, alle Anforderungsheader, alle Anforderungsmethoden und alle Quellen. Nachdem ich die Konfiguration geändert hatte, startete ich das Projekt entschlossen neu, um den Effekt zu sehen. Da ich sah, dass der Browserfehler durch domänenübergreifendes Umleiten verursacht wurde, fügte ich zunächst den Code hinzu Mein 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;
}

Verwenden Sie

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

, um direkt über das Front-End-Vue die Back-End-Anmeldeschnittstelle anzufordern. Anschließend greift das Front-End auf das System zu und kann direkt zur Single-Sign-In-Seite springen. Aber als ich mein Konto und mein Passwort eingegeben und auf „Anmelden“ geklickt habe, sprang ich zurück zum System und stellte fest, dass nicht auf alle Anforderungsdatenschnittstellen normal zugegriffen werden konnte. Debug stellte fest, dass alle Anforderungen keine Benutzerinformationen enthielten und vom Interceptor als erkannt wurden nicht angemeldet, daher konnten nicht alle Anfragen angenommen werden.

Warum bin ich eindeutig angemeldet und der Interceptor setzt auch Benutzerinformationen auf die Sitzung. Warum sind die Cookies weg? Ich habe erneut eine Anfrage initiiert und festgestellt, dass die JsessionId jeder Anfrage unterschiedlich war. Nachdem ich viele Informationen überprüft hatte, stellte ich fest, dass dem Frontend eine Konfiguration hinzugefügt werden muss, die Authentifizierungsinformationen ermöglicht. Eine entsprechende Konfiguration muss ebenfalls vorhanden sein im Backend erstelltallowCredentials(true);

axios.defaults.withCredentials=true;

Nachdem ich diese Konfiguration hinzugefügt habe, habe ich den Vorgang erneut ausgeführt und festgestellt, dass ich nach der Anmeldung normal zum System springen kann und die Seitendaten auch normal angezeigt werden.

Gerade als ich dachte, ich wäre fertig, klickte ich plötzlich auf eine Seite und die Daten konnten nicht normal angezeigt werden. Ich war so verwirrt, dass ich eine Anfragemethode fand, die ich noch nie zuvor gesehen hatte dass diese Anfragemethode POST ist. Warum ist sie zu OPTIONS geworden? Also bestellte ich mehrere andere POST-Anfragen und stellte fest, dass sie alle zu OPTIONS-Anfragen wurden. Ich war verwirrt und überprüfte schnell die Informationen von OPTIONS-Anfragen. Im Internet hieß es, dass OPTIONS-Anfragen „Vorabprüfungsanfragen“ heißen Nachdem die Anforderung ausgeführt wurde, initiiert der Browser zunächst eine Vorabprüfungsanforderung. Erst nachdem die Vorabprüfungsanforderung erfolgreich war, kann die formelle Anforderung ausgeführt werden. Nachdem ich es gelesen hatte, wurde mir plötzlich klar, dass OPTIONS abgefangen wurde, sodass ich meine POST-Anfrage nicht mehr ausführen konnte. Dann ließ ich die Vorabprüfungsanfrage einfach passieren. Fügen Sie dieses Urteil einfach dem Interceptor hinzu

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

Wenn der Interceptor auf diese Weise feststellt, dass es sich bei der Anfrage um eine Vorabprüfungsanforderung handelt, leitet er sie direkt weiter und die nächste POST-Anfrage kann ausgeführt werden.

Das obige ist der detaillierte Inhalt vonSo lösen Sie das domänenübergreifende Single-Sign-On-Problem durch die Trennung des Front-Ends und des Back-Ends von vue+springboot. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!