vue+springboot는 단일 지점 교차 도메인 로그인을 프런트엔드와 백엔드에서 분리합니다.

이번에는 vue+springboot 프론트엔드와 백엔드 분리의 싱글 포인트 크로스 도메인 로그인에 대해 알려드리겠습니다. vue+springboot 프론트엔드와 프론트엔드 분리 싱글 포인트 크로스의 주의사항은 무엇인가요? 도메인 로그인에 대한 실제 사례는 다음과 같습니다.

현재 백엔드 관리 시스템을 작업 중입니다. 프론트엔드는 널리 사용되는 vue.js를 사용하고 백엔드는 springboot를 기반으로 합니다. 백엔드 시스템에는 로그인 기능이 없지만 회사에서 통합 로그인을 요구하기 때문에 로그인 인증은 .net 프로젝트 팀의 인증 시스템을 사용합니다. Single Sign-On이 무엇인지 모르는 학생들은 만능 Du Niang을 추천합니다.

처음 이 요구 사항을 받았을 때 나는 '로그인만 하는 것이 중요하지 않다'는 생각에 경멸했습니다. 그런데 개발 과정에서 정말 큰 충격을 받았습니다. . . , 그래서 앞으로는 그런 함정에 빠지지 않도록 이번에는 이 교훈을 주의 깊게 기록해야 합니다.

제가 직면한 첫 번째 문제는 크로스 도메인이었습니다. 브라우저 콘솔이 CORS를 직접 보고했습니다. 다년간의 개발 경험을 바탕으로 과감히 백그라운드에서 크로스 도메인 구성을 구성했습니다.

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

이 구성은 모든 매핑, 모든 요청 헤더, 모든 요청 방법 및 모든 소스를 허용합니다. 구성을 변경한 후 효과를 확인하기 위해 과감하게 프로젝트를 다시 시작했는데, 싱글 로그인 페이지로 리디렉션할 수 있는 방법이 없다는 것을 알게 되었고, 크로스 도메인으로 인해 브라우저 오류가 발생한 것을 보고 먼저 의 코드를 업로드했습니다. 내 로그인 인터셉터

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;
}

나중에 프런트엔드 Vue는

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

를 사용하여 직접 백엔드의

로그인 인터페이스

를 요청합니다. 프런트 엔드가 시스템에 액세스한 후 Single Sign-On 페이지로 직접 이동할 수 있습니다. 그러나 내 계정과 비밀번호를 입력하고 로그인을 클릭했을 때 시스템으로 다시 돌아가서 모든 요청 데이터 인터페이스에 정상적으로 액세스할 수 없다는 사실을 발견했습니다. 디버그에서는 모든 요청이 사용자 정보를 전달하지 않고 인터셉터에서 로그인되지 않아 모든 요청을 통과할 수 없습니다.

로그인했는데도 인터셉터가 사용자 정보를 세션에 설정하는 이유는 무엇입니까? 쿠키는 왜 사라지나요? 다시 요청을 시작했는데 각 요청의 JsessionId가 다르다는 것을 확인했습니다. 많은 정보를 확인해보니 프런트 엔드에 인증 정보를 추가할 수 있는 구성을 추가해야 한다는 것을 알았습니다

axios.defaults.withCredentials=true;

백엔드에서도 해당 구성을 만들어야 합니다. allowedCredentials(true);

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

이 구성을 추가한 후 작업 프로세스를 다시 실행해 보니 로그인 후 시스템으로 정상적으로 점프할 수 있고, 페이지 데이터도 정상적으로 표시되는 것을 확인했습니다.

끝났다고 생각한 순간 갑자기 페이지를 클릭했는데 데이터가 정상적으로 표시되지 않네요. 너무 혼란스러워서 재빨리 F12를 눌러 본 적 없는 요청 방법, OPTIONS 요청이 나온 것으로 나타났습니다. 요청 방법은 분명히 POST였습니다. 왜 변경되었습니까? 그래서 몇 가지 다른 POST 요청을 주문했는데 모두 OPTIONS 요청으로 바뀌는 것을 발견했습니다. 나는 혼란스러워서 OPTIONS 요청의 정보를 재빨리 확인했습니다. 인터넷에서는 OPTIONS 요청을 "사전 확인 요청"이라고 합니다. 이는 공식 Before를 의미합니다. 요청이 실행되면 브라우저는 먼저 사전 확인 요청을 시작합니다. 사전 확인 요청이 통과된 후에만 정식 요청이 실행될 수 있습니다. 읽은 후 갑자기 OPTIONS가 가로채어 더 이상 POST 요청을 실행할 수 없다는 것을 깨달았습니다. 그런 다음 사전 확인 요청을 통과시켰습니다. 이 판단을 인터셉터

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

에 추가하세요. 이런 방식으로 인터셉터는 요청이 사전 확인 요청임을 알아내고 바로 전달한 후 다음 POST 요청을 실행할 수 있다.

이 기사의 사례를 읽은 후 방법을 마스터했다고 생각합니다. 더 흥미로운 정보를 보려면 PHP 중국어 웹사이트의 다른 관련 기사를 주목하세요!

추천 도서:

vue 프로젝트 구조 지침

vue 장바구니의 작은 공 포물선 효과 구현에 대한 자세한 설명

위 내용은 vue+springboot는 단일 지점 교차 도메인 로그인을 프런트엔드와 백엔드에서 분리합니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!