헤더에 토큰값을 담아서 보내주었습니다.
// Jwt 토큰 생성, response에 넣기
String token = jwtUtil.createToken(id,nickname,username);
// Jwt 헤더에 저장.
jwtResponse.addHeader("authorization",token);
return new LoginResponseDto("로그인 성공");
그런데 프론트 측에서 header 콘솔에 토큰값이 없다고 요청하여서 몇 시간 동안 고생했는데 진전이 없었습니다.
PostMan에서도 Reaponse Header에 키값과 토큰값이 잘 담겨 왔습니다.

처음에는 다른 백엔드 조에서 작성한 코드와 비교했을 때 다른 부분이 없어서
프론트쪽의 문제라고만 생각 했었습니다.
addHeader 가 아닌 setHeader . : 실패
HttpHeaders 객체를 직접 생성 . : 실패
HttpHeaders httpHeaders = new HttpHeaders();
httpHeaders.add("authorization",token);
문제의 원인은... CORS 설정에서 exposedHeader 설정을 해주지 않아서였습니다.
@RestController
@RequestMapping("/api")
@CrossOrigin( origins = "*" , exposedHeaders = "*" )
@RequiredArgsConstructor
public class UserController
위 코드로 문제는 해결되었습니다.
Origins와 exposedHeaders의 경로는 프론트와 협의하여 정확하게 작성해 주어야 할 것 같습니다.
그리고 @CrossOrigin 어노테이션을 사용하는 방식 말고 Configuration 클래스를 따로 만들어 CORS설정을 하는 방식으로도 작성해 보았습니다.
개발자 도구에서 network텝에서 볼 수 있는 response header는 그저 영수증에 불과하다는 사실을 알았습니다. 정보를 읽을 수는 있지만 꺼내와서 사용할 수는 없는 것입니다.
따라서 Header의 콘솔에 데이터가 담기게 해야하는데
exposedHeaders 설정을 하지 않으면 콘솔에 데이터가 드러나지 않기 때문에 서버측에서 정보를 보내주어도(본 글에서는 jwt 토큰값) 클라이언트 측에서는 데이터를 사용 할 수 없게 되는 것입니다.
++ 구현에 중점을 두고 CORS에 대해 꼼꼼하게 공부하지 않아서 에러픽스를 하는데 엄청난 시간을 투자해보면서 하나를 공부하더라도 정확하게 공부해야겠다고 느꼈습니다.
++ allowedHeader vs exposedHeader
Access-Control-Allow-Headers vs Access-Control-Expose-Headers 의 차이
Allow는 preflight request에 대한 응답으로 어떤 헤더가 사용될 수 있는지 알려주는 것이다.
Expose는 allowlist에 특정한 헤더들을 더해주어서 그 헤더들을 브라우저가 접근할 수 있게 해 주는 것이다.
글 잘 봤습니다, 많은 도움이 되었습니다.