해결된 질문
작성
·
73
0
채팅과 관련된 API를 설계할 때 보면 Controller 레이어에서 @AuthenticationPrincipal 파라미터를 사용해서 사용자의 정보를 가지고 오는 것이 아닌 Service 레이어에서 SecurityContextHoler를 통해 사용자의 정보를 가지고 오는데 이는 웹소켓 같은 경우에는 Header에 JWT 토큰 정보를 담을 수 없기 때문이다라고 이해하면 될까요??
답변 2
1
일반 api는 사실 웹소켓과는 무관합니다!! 일반 api 요청시엔 @AuthenticationPrincipal 을 통해 email정보를 받으셔도 무관합니다. 해당 어노테이션과 authentication에서 email을 찾는 방법의 원리는 결국 동일합니다.
다만 security context holder를 활용한 방식은 controller계층 뿐만 아니라 어떤 레이어에서도 사용이가능하기에 저의 선호에 따라 코드가 그렇게 작성되었다고 보시면 되겠습니다.
0
안녕하세요, 인프런 AI 인턴입니다. 박철현님.
질문 주신 내용에서, 웹소켓 환경에서의 사용자 인증 처리 방법에 관한 부분을 말씀하신 것으로 이해했습니다. 일반적인 HTTP 요청에서는 @AuthenticationPrincipal
을 통해 컨트롤러 단에서 사용자의 정보를 쉽게 얻을 수 있지만, 웹소켓의 경우 조금 다른 접근법이 필요할 수 있습니다.
웹소켓에서는 초기 핸드셰이크 요청 시에만 HTTP 헤더가 사용되지만, 이후 메시지는 별도의 HTTP 헤더를 포함하지 않습니다. 따라서 웹소켓은 상태 비저장을 이유로 사용자의 상태 정보를 유지하는 데 한계가 있습니다. 이러한 맥락에서 다음과 같이 설명드릴 수 있습니다:
JWT 토큰 사용: 일반적인 HTTP 요청에서는 보안 컨텍스트(SecurityContext)에서 인증된 사용자 정보를 쉽게 접근할 수 있는데, 웹소켓 처리 시에는 운영되는 방식이 다릅니다. 웹소켓에서는 수신된 메시지에 JWT를 포함하기 위한 전략이 필요하며, 초기 연결 시 JWT를 통해 인증하는 방법이 많습니다.
초기 핸드셰이크: 웹소켓 연결 시 초기 핸드셰이크 단계에서 헤더에 JWT 토큰을 포함하여 인증을 수행한 후, 연결이 완료되면 이 정보를 토대로 설정된 사용자 세션 또는 보안 컨텍스트에서 사용자를 추적할 수 있습니다.
SecurityContext 이용: 웹소켓 환경에서는 서비스 레이어에서 SecurityContextHolder를 통해 사용자 정보를 가져오는 방식이 많이 사용됩니다. 이는 서비스의 전반적인 로직에서 사용자 권한 또는 세션 정보가 필요할 경우유용합니다.
이와 관련된 내용들을 다룬 질문과 답변으로 도움을 받을 수 있습니다:
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.