티스토리 뷰

프로젝트를 순탄하게 진행했을 때, 프론트에서 요청이 왔습니다.

😱: 올바른 요청을 했는데 500 에러가 발생해요!!

로그인 파트에서 발생한 에러인데, 문제는 커스텀 에러를 반환하지 않았던 것입니다.
백엔드에서는 도메인, 에러 종류별로 커스텀 에러 코드를 반환하도록 하는데 이 경우에는 500을 반환하여 이유를 알 수 없었습니다.

(스웨거에서는 너무 잘 작동하고...)

 

보통 로컬에서 개발할 때, 이런 상황이 발생하면 콘솔에 찍거나 디버그를 돌리는 것이 가장 쉬운 방법이지만,
서버 배포된 상황에서 발생하는 에러는 할 수 없으니 로그를 까보기로 했습니다!

 

시스템 아키텍처

저희 프로젝트의 시스템 아키텍처는 위와 같습니다.

따라서 도커 로그를 확인하게 되었습니다. 방법은 다음과 같습니다.

 

1. docker ps를 통해 CONTAINER ID 확인하기.

2. docker logs CONTAINER ID -tf <- 명령어 입력하기

 

위 과정을 진행하면 오류가 발생한 로그를 확인할 수 있습니다.

 

그래서 무슨 에러

에러 로그는 다음과 같았는데, 

더보기

When allowCredentials is true, allowedOrigins cannot contain the special value "*" since that cannot be set on the "Access-Control-Allow-Origin" response header. To allow credentials to a set of origins, list them explicitly or consider using "allowedOriginPatterns" instead.

원인은 이러했습니다.

 

CORS를 처리해주었는데 이때 .addAllOrigin("*")으로 모든 경로를 열어주었습니다.
문제는 addAllOrigin과 .allowCredentials(true)를 같이 사용할 수 없다는 것 입니다.

 

addAllOrigin("") 대신 .addAllOriginPatterns("")를 사용하여 해당 에러를 잡을 수 있었습니다.

 

 

땀;;

로컬에서는 디버깅이나 콘솔 확인으로 해결할 수 있는데, 배포가 된 이상 그럴 수 없습니다.

그렇기 때문에 서비스에서 에러에 대한 로그를 잘 관리하는 것이 빠르게 대처할 수 있는 방법인 것 같습니다. 

 

로그... 소중해

공지사항
최근에 올라온 글
최근에 달린 댓글
«   2024/11   »
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30