문제 상황

• Backend 에서 Spring Security 기능을 JWT 토큰 인증 방식으로 구현하여 붙이고 난 후, Frontend 에서 갑작스런 CORS 문제가 발생했다.
• 문제는 CORS 401 이슈가 인증 실패의 401 이슈와 코드가 같다는 점이었다. 덕분에 이게 CORS 인지 코드가 달라서인지 불분명한 상황에서 axios, jotai, react-query, localstorage, 브라우저 캐시 이용 상황 등 다양한 부분들을 모두 의심해가며 꽤 많은 삽질을 하게 되었다.
• 게다가 간헐적으로 문제가 발생하기도 하고 cypress, storybook 에서는 되었다가 local server는 안 되었다… 하며 여러가지를 시도하던 중 우연찮게 얻어걸린 캐시의 문제가 발새하며 문제 상황을 더 헷갈리게 만들어주었다.
  • 지금 생각해보면, backend 에서 security 를 해제한 상태에서 preflight 가 날라가 통과한 것이 캐시가 되었던 것 같다.
• 발생한 문제들을 해결하다보니 여러 개념들이 좀 정립된 것이 있어 한번 정리해두고자 한다.

백엔드 부분의 문제…?

• Security 를 붙였다. 그게 전부이다ㅋㅋ

protected SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
http.

...

      .antMatchers("/store/**").authenticated()
      .anyRequest().permitAll()

      .and()
      .apply(new JwtSecurityConfig(tokenProvider));

    return http.build();
  }

• 관련해서 permitAll 에 들어간 녀석들은 요청 헤더에 Authorization 토큰을 박아준 채로 잘만 동작하는데, 왜 authenticated() 에 걸린 녀석들은 잘 되지 않을까?

  • 상당히 곤혹스러웠다. 디버거로도 잡히지 않는… Swagger 로 Auth 를 시도하면 또 잘 되고… 분명 프론트엔드의 문제일텐데…? 란 결론이 나기도 했다.

  • 헌데 실상은 백엔드의 결론이었다.

  • 이미 문제를 해결했으니 당시 상황을 재현해보면,

  • Security 에 걸려있지 않아 잘 들어오는 Request

    

  • Security에 걸린 문제의 Request

    

  • reqeust.getMethod() 에서 보면 OPTIONS 일 때 Authorization 토큰이 비어있는 것을 볼 수 있다. 당시 당연히 GET 일줄 알고 request.getMethod() 를 안 찍어보아 3시간을 더 소비했구나ㅋㅋ

  • 공식가이드에 설명이 있다.

    • (https://docs.spring.io/spring-security/reference/reactive/integrations/cors.html)
    • Security 에 들어오기 전에 CORS 처리가 먼저 되어야 한다. 그래야 OPTIONS 처리가 정상적으로 되는 것이다.

    

  • 키워드를 잡고 baeldung 을 확인해보니 해결책이 있다.

  • https://www.baeldung.com/spring-security-cors-preflight

    • http.cors() 를 통해 security 보다 CORS 처리를 먼저 하게 해주니 깔끔하게 해결되었다.

    <aside> 💡 The cors()  method will add the Spring-provided CorsFilter  to the application context, bypassing the authorization checks for OPTIONS requests.

    </aside>

  • 이 가이드를 따름으로서 충분하다.

프론트엔드의 문제…?

• axios 와 react query 를 활용하는데, 분명히 axios 로 request 가 가며 request header 가 붙어있음에도 불구하고, 왜 백엔드에서는 request header 가 확인되지 않았을까…

• 프론트엔드에서는 브라우저 캐시가 OPTIONS 를 이용한 preflight 요청을 날리면 이후 그 요청을 캐싱하여 더 이상 같은 요청을 날리지 않는다.

  • 그래서 평소에는 axios 를 통해 http 요청이 날라갈 때 크롬 개발자 도구에서 Preflight 요청이 보이지 않다가, CORS 가 발생하는 문제에서는 Preflight 가 보여졌던 것이다.
  • 사실상 평소에는 캐시로 인해 Preflight 가 전혀 날아가지 않았던 것. 덕분에 5년만에 이 사실을 깨달았다..^^

• OPTIONS 가 잘 된 경우 최초 요청의 모습

  

  • 2번의 verify 가 날아갔고 그 중 한 건은 OPTIONS 이다.

    

• 이후 캐시가 동작하면, options 는 날아가지 않고 POST 만 한 번 날아간다. verify 가 한건만 날아간 것을 볼 수 있다.

• list 도 마찬가지

• 그러고 브라우저에서 캐시를 날려버리면,

• 또다시 두건이 날아간다.

  영상.mp4