<div id="readability-page-1" class="page"><div>백엔드 서버 배포를 마친뒤 실제 프론트엔드와 연동해 데모하는 과정에서 일부 API에서 CORS 문제가 발생했다.
엥 CORS? 그게 뭐지?
<img src="https://velog.velcdn.com/images/0_0_yoon/post/d32bba6c-9ecf-430f-9060-b766fc698c00/image.png">(프론트엔드 서버와 백엔드 AWS 서버, 출처가 다르다.)
CORS 란 교차 출처 리소스 공유로 한 출처에서 실행 중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에서 알려주는 체제이다. 
보안 상의 이유로, 자바스크립트는 같은 출처에 대해서만 허용하고 다른 출처의 리소스를 불러오려면 그 출처에서 올바른 CORS 헤더를 포함한 응답을 반환해줘야한다.
즉 프론트엔드에서 요청을 보냈을 때 백엔드 서버에서 CORS 헤더를 포함한 응답을 반환해줘야 문제가 해결된다.
<pre><code>@Configuration
public class WebConfig implements WebMvcConfigurer {

 public static final String ALLOWED_METHOD_NAMES = "GET,HEAD,POST,PUT,DELETE,TRACE,OPTIONS,PATCH";

 @Override
 public void addCorsMappings(final CorsRegistry registry) {
 registry.addMapping("/**")
 .allowedMethods(ALLOWED_METHOD_NAMES.split(","))
 .exposedHeaders(HttpHeaders.LOCATION);
 }
}</code></pre>
하지만 레거시 코드에 이미 CORS 허용 설정이 되있었고, 일부 GET 메서드 요청에서는 문제가 없는 상황이였다. 
<img src="https://velog.velcdn.com/images/0_0_yoon/post/ce6cb218-7853-4862-b908-4193bb175c2e/image.png"> 
(이미 모든 출처에 대해서 허용돼있었다.)
문제 해결을 위해서는 예비 요청(Preflighted request) 에 대해 알아야했다.
CORS가 동작하는 방식이 세가지 있는데
<ol>
<li>
Simple requests
단순요청은 예비 요청을 보내지 않고 바로 서버에 본 요청을 한다.
언제나 단순요청만 할 수 있는건 아니고 아래 조건을 만족 해야한다.
<ol>
<li>
GET, HEAD, POST 중 하나의 메서드일 것.
</li>
<li>
유저 에이전트가 자동으로 설정한 헤더외에, 수동으로 설정할 수 있는 헤더는 <a href="https://fetch.spec.whatwg.org/#cors-safelisted-request-header">Fetch 명세에서&nbsp;“CORS-safelisted request-header”로 정의한 헤더</a> 뿐이다.
Accept
Accept-Language
Content-Language
Content-Type
</li>
<li>
Content-Type 헤더는 다음의 값들만 허용한다.
application/x-www-form-urlencoded
multipart/form-data
text
</li>
</ol>
*POST 메서드의 경우 대부분 Content-Type 이 application/json이기 때문에 단순요청이 아닌 예비 요청을 보낸다.
</li>
<li>
Preflighted request
예비 요청은 먼저 OPTIONS라는 HTTP 메서드를 통해 본 요청을 보내기전 브라우저가 스스로 안전한 요청인지 확인한다.
<img src="https://velog.velcdn.com/images/0_0_yoon/post/3a9e5ad4-a894-46fb-871a-c4175667f44c/image.png"> 
(POST 요청이지만 Content-Type이 application/json 이기 때문에 예비 요청을 한다.)
<img src="https://velog.velcdn.com/images/0_0_yoon/post/161a1de8-0461-40d5-9a04-8eb4185c7c1c/image.png"> 
(예비 요청에 대한 서버 응답의 헤더)
</li>
<li>
Credentialed requests
인증정보를 포함한 요청(Credentialed requests)은 쿠키와 인증 정보를 인식한다.
기본적으로 XMLHttpRequest 객체나 fetch API는 헤더에 쿠키와 인증 정보를 담을 수 없다. 그래서 XMLHttpRequest 객체나 Request 생성자가 호출될 때 특정 플래그를 설정해야 한다.
인증정보를 포함한 요청을 하게 되면 브라우저에서는 응답 헤더에서 두가지를 확인한다.
<ol>
<li>Access-Control-Allow-Credentials: true 가 존재하는지</li>
<li>Access-Control-Allow-Origin: *가 아닌 정확한 출처를 지정했는지</li>
</ol>
</li>
</ol>
내가 맞닥뜨린 문제의 원인은 앞서 말했듯이 예비 요청에 있었다.
이번 미션에서 인증과 인가를 할때 토큰을 사용했고 그 토큰의 유효성 검증은 interceptor의 preHandle 메서드 에서 해줬다.
예비 요청의 OPTIONS 메서드의 헤더에는 토큰 정보가 없었기 때문에 preHandle 메서드에서 걸러졌고 프론트에서 본 요청을 보낼 수 없었던 것이다. 그래서 preHandle 메서드에 다음과 같이 로직을 추가해서 해결했다.
<pre><code>@Override
 public boolean preHandle(final HttpServletRequest request, final HttpServletResponse response, final Object handler)
 throws Exception {
 //OPTIONS 메서드로 요청이 오면 토큰을 검사하지 않는다.
 if (HttpMethod.OPTIONS.matches(request.getMethod())) {
 return true;
 }

 final String token = AuthorizationExtractor.extract(request);
 validateExpiredToken(token);
 return true;
 }</code></pre>
이번에 직접 배포를 해보고 프론트엔드와의 협업을 해보니 네트워크 지식의 필요성을 뼈저리게 느끼고있다..
결론 네트워크 공부를 하자!
참고자료: <a href="https://developer.mozilla.org/ko/docs/Web/HTTP/CORS">https://developer.mozilla.org/ko/docs/Web/HTTP/CORS</a>, 
<a href="https://prolog.techcourse.co.kr/studylogs/2414">https://prolog.techcourse.co.kr/studylogs/2414</a></div></div>

0_0_yoon.log

yoon

백엔드 서버 배포를 마친뒤 실제 프론트엔드와 연동해 데모하는 과정에서 일부 API에서 CORS 문제가 발생했다.
엥 CORS? 그게 뭐지?
(프론트엔드 서버와 백엔드 AWS 서버, 출처가 다르다.)
CORS 란 교차 출처 리소스 공유로 한 출처에서 실행 중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라우저에서 알려주는 체제이다. 
보안 상의 이유로, 자바스크립트는 같은 출처에 대해서만 허용하고 다른 출처의 리소스를 불러오려면 그 출처에서 올바른 CORS 헤더를 포함한 응답을 반환해줘야한다.
즉 프론트엔드에서 요청을 보냈을 때 백엔드 서버에서 CORS 헤더를 포함한 응답을 반환해줘야 문제가 해결된다.
@Configuration
public class WebConfig implements WebMvcConfigurer {
    public static final String ALLOWED_METHOD_NAMES = "GET,HEAD,POST,PUT,DELETE,TRACE,OPTIONS,PATCH";
    @Override
    public void addCorsMappings(final CorsRegistry registry) {
        registry.addMapping("/**")
                .allowedMethods(ALLOWED_METHOD_NAMES.split(","))
                .exposedHeaders(HttpHeaders.LOCATION);
    }
}
하지만 레거시 코드에 이미 CORS 허용 설정이 되있었고, 일부 GET 메서드 요청에서는 문제가 없는 상황이였다.
(이미 모든 출처에 대해서 허용돼있었다.)
문제 해결을 위해서는 예비 요청(Preflighted request) 에 대해 알아야했다.
CORS가 동작하는 방식이 세가지 있는데
Simple requests
 단순요청은 예비 요청을 보내지 않고 바로 서버에 본 요청을 한다.
 언제나 단순요청만 할 수 있는건 아니고 아래 조건을 만족 해야한다.
GET, HEAD, POST 중 하나의 메서드일 것.
유저 에이전트가 자동으로 설정한 헤더외에, 수동으로 설정할 수 있는 헤더는 Fetch 명세에서 “CORS-safelisted request-header”로 정의한 헤더 뿐이다.
 Accept
 Accept-Language
 Content-Language
 Content-Type
Content-Type 헤더는 다음의 값들만 허용한다.
 application/x-www-form-urlencoded
 multipart/form-data
 text
*POST 메서드의 경우 대부분 Content-Type 이 application/json이기 때문에 단순요청이 아닌 예비 요청을 보낸다.
Preflighted request
 예비 요청은 먼저 OPTIONS라는 HTTP 메서드를 통해 본 요청을 보내기전 브라우저가 스스로 안전한 요청인지 확인한다.
 
 (POST 요청이지만 Content-Type이 application/json 이기 때문에 예비 요청을 한다.)
 
 (예비 요청에 대한 서버 응답의 헤더)
Credentialed requests
 인증정보를 포함한 요청(Credentialed requests)은 쿠키와 인증 정보를 인식한다.
 기본적으로 XMLHttpRequest 객체나 fetch API는 헤더에 쿠키와 인증 정보를 담을 수 없다. 그래서 XMLHttpRequest 객체나 Request 생성자가 호출될 때 특정 플래그를 설정해야 한다.
 인증정보를 포함한 요청을 하게 되면 브라우저에서는 응답 헤더에서 두가지를 확인한다.
Access-Control-Allow-Credentials: true 가 존재하는지
Access-Control-Allow-Origin: *가 아닌 정확한 출처를 지정했는지
내가 맞닥뜨린 문제의 원인은 앞서 말했듯이 예비 요청에 있었다.
이번 미션에서 인증과 인가를 할때 토큰을 사용했고 그 토큰의 유효성 검증은 interceptor의 preHandle 메서드 에서 해줬다.
예비 요청의 OPTIONS 메서드의 헤더에는 토큰 정보가 없었기 때문에 preHandle 메서드에서 걸러졌고 프론트에서 본 요청을 보낼 수 없었던 것이다. 그래서 preHandle 메서드에 다음과 같이 로직을 추가해서 해결했다.
@Override
    public boolean preHandle(final HttpServletRequest request, final HttpServletResponse response, final Object handler)
            throws Exception {
            //OPTIONS 메서드로 요청이 오면 토큰을 검사하지 않는다.
        if (HttpMethod.OPTIONS.matches(request.getMethod())) {
            return true;
        }
        final String token = AuthorizationExtractor.extract(request);
        validateExpiredToken(token);
        return true;
    }
이번에 직접 배포를 해보고 프론트엔드와의 협업을 해보니 네트워크 지식의 필요성을 뼈저리게 느끼고있다..
결론 네트워크 공부를 하자!
참고자료: https://developer.mozilla.org/ko/docs/Web/HTTP/CORS,
https://prolog.techcourse.co.kr/studylogs/2414

[2레벨] 좌충우돌 CORS 허용기

댓글