전후단이 분리된 후 크로스 도메인에서 쿠키를 전달할 수 없는 문제를 요청합니다. 최근에 회사에서 작은 프로젝트를 할 때 구덩이를 만났습니다. 기록해 주세요.

전후단이 분리된 후 크로스 도메인에서 쿠키를 전달할 수 없는 문제를 요청합니다. 최근에 회사에서 작은 프로젝트를 할 때 구덩이를 만났습니다. 기록해 주세요.

앞말

도메인 간 문제

쿠키 질문

차단기로 인한 도메인 간 문제

후기

전언
그날은 졸업 후 직장 생활 30일째입니다. 처음으로 전후단 분리 개발을 접했습니다. 저는 마치 전후단 분리 개발의 참뜻을 천천히 깨달은 것 같습니다. 아마도 전후단 분리 개발일 것입니다.
장면은 프론트 데스크톱에서 페이지를 미친 듯이 클릭하여 요청을 보냈지만 백엔드 서버는 항상 응답하지 않았다. 백엔드 인터페이스는 인터럽트를 쳤지만 인터럽트에 들어갈 수 없었다.
전단: 보내달라고 했어요. 데이터 형식도 맞았어요. 인터페이스 문서는 그렇게 썼어요. 인터페이스 문서의 요구에 따라 썼어요. 서버가 왜 그래요? 인터페이스가 맞아요, 바라바라...
백스테이지: 내 인터페이스 문서를 잘 썼어. 응, 내 쪽postman 테스트는 할 수 있어. 내가 테스트를 통과해서 쓴 문서야. 응, 너 쪽은 뭐야? 네가 보낸 요청이 맞았어, 바라바라...
장면 2 프론트 데스크에서 로그인할 때 인증 코드가 계속 검사를 통과하지 못합니다
전단: 내가 입력한 인증코드는 바로 그림 속의 인증코드인데 왜 백스테이지에서 계속 검증을 통과하지 못했는지 어떻게 뚱뚱해졌는지 네 백스테이지 인터페이스가 맞았어? 논리적 판단이 맞았어, 바라바라...
백스테이지: 틀림없어. 내 쪽은 내가postman으로 테스트를 통과했어. 너 쪽은 어떻게 된 거야. 내 백스테이지에서 너의session 응, 바라바라...
도메인 간 문제
장면 1은 전형적인 크로스 인터페이스 문제이다. 전후단을 분리하여 개발할 때 전방 백엔드 코드가 한 서버에 없기 때문에 전방 페이지 서버가 백엔드 인터페이스를 방문하려고 할 때 브라우저의 동원 정책 때문에 이러한 방문을 거절하고 백엔드에서 이런 요청을 받지 못한다.
백그라운드를 설정해야 합니다.

  /**
   *       
   */
@Configuration
public class CorsConfig {
    private CorsConfiguration buildConfig() {
        CorsConfiguration corsConfiguration = new CorsConfiguration();
        // 1       
        corsConfiguration.addAllowedOrigin("*");
        // 1.1      
        corsConfiguration.addAllowedOrigin("http://localhost:8032");
        // 2     
        corsConfiguration.addAllowedHeader("*");
        // 3      （post、get ）
        corsConfiguration.addAllowedMethod("*");
        // 4   withCredentials   
        corsConfiguration.setAllowCredentials(true);
        return corsConfiguration;
    }
    @Bean
    public CorsFilter corsFilter() {
        UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
        source.registerCorsConfiguration("/**", buildConfig());
        return new CorsFilter(source);
    }
}

가장 간단하고 난폭한 것은 어떤 소스로부터의 요청도 받는다.
질문
크로스 액세스 시 브라우저는 기본적으로 쿠키를 가지고 가지 않습니다. 그러면 매번 백엔드에서 요청에 따라 새로운session이 생기고 인증 코드 값은 각자의session에 저장됩니다. 물론 영원히 검증이 통과되지 않습니다!
프론트 데스크톱에서 Ajax 요청을 보낼 때 브라우저에 크로스오버 쿠키를 허용한다고 알려 줍니다. (이것은 구덩이입니다. 주의하십시오.)아래와 같이 쓰시오.

$.ajax({
	type: "POST",
	url: serverPath + "/api/v1/login",
	contentType: 'application/x-www-form-urlencoded;charset=utf-8',
	data: {username:$("#username").val(), password:$("#password").val(), rememberMe},
	dataType: "json",
	xhrFields: {
		withCredentials: true  //    cookie
	},
	success: function(data){
		if(data.code == 200){
			layer.msg(data.msg);
			window.location.href="index.html";
		}else{
			layer.msg(data.msg);
		}
	},	
})

차단기로 인한 전역 문제
위의 문제가 모두 해결된 후에 마지막으로 시스템에 차단기를 넣는다.전역 문제가 또 왔다.
우리는 차단기 안에서 옵션을 실행해야 한다. 이 방법은 브라우저가 보낸 탐지 방법이다. 목표 호스트가 크로스 영역을 허용하는지 탐지한다. 결과적으로 탐지할 때 차단기에 의해 차단되고 보낸 정찰병의 소식이 전무하면 브라우저는 목표 호스트에게 요청을 보내지 않는다.cros크로스 인터페이스 오류를 보내지 않는다.

public class MyFormAuthenticationFilter extends FormAuthenticationFilter {

    /**
     *    controller       ，  json，      。
     * @param request
     * @param response
     * @return true-      ，false- filter       ，          
     * @throws Exception
     */

    @Override
    protected boolean isAccessAllowed(ServletRequest request, ServletResponse response, Object mappedValue) {
        if (request instanceof HttpServletRequest) {
            if (((HttpServletRequest) request).getMethod().toUpperCase().equals("OPTIONS")) {
                return true;
            }
        }
        return super.isAccessAllowed(request, response, mappedValue);
    }
}

후기
몇 년 후, 아마도 내가 가장 많이 한 말은 다음과 같다.

이쪽은 쓸 수 있어요

나한테는 잘 돼

postman 테스트 통과

너 캐시 안 풀었지