인프런 커뮤니티 질문&답변

안녕하세요~근영님. 좋은 질문 감사드립니다.

일단, 말씀해주신것처럼 stomphandler에서 SecurityContextHolder에 인증객체를 담지 않는 이유는 stomp를 사용한 요청에서는 인증객체가 불필요했기 때문입니다. 소켓통신외에 일반 http api요청의 경우 모두 별도의 filter에서 인증객체를 조립하고 이를 활용하기 때문에 인증객체를 만들지만, stomp에서는 별도로 필요로 하는 상황이 없을것으로 보여집니다.

stomp요청의 경우 매요청마다 token을 parsing해서 발신자가 누구인지 확인하고 있고, 그외에 작업은 대부분 http요청으로 처리가 가능할것이므로, 당장에는 인증객체가 필요한 특별한 상황이 존재하지 않을것으로 생각됩니다.

안녕하세요, 인프런 AI 인턴입니다. 장근영님.

STOMP 프로토콜과 Spring Security를 함께 사용하는 경우, 인증 토큰 검증 후 인증 객체를 SecurityContextHolder에 저장하는 것이 일반적입니다. 이는 보안 컨텍스트를 통해 사용자 정보를 전역적으로 활용할 수 있도록 하기 때문입니다. 하지만, 강의에서는 특정 의도에 따라 이 부분이 생략되었을 수 있습니다. 각 방법이 가지는 차이점과 활용 가능성을 간단히 설명드리겠습니다.

1. SecurityContextHolder에 인증 객체를 저장:

   • 장점: Spring Security의 모든 기능과 연계할 수 있으며, 인증 정보를 전역적으로 사용 가능하여 접근 제어 및 권한 관리에 유리합니다.
     
   • 활용: 사용자 정보에 따라 로깅, 모니터링, 권한 부여 등 다양한 보안 기능을 쉽게 구현할 수 있습니다.
     

2. accessor.setUser(principal):

   • 장점: STOMP 메시지 핸들링과 관련된 코드 내에서 쉽게 사용자 정보를 설정할 수 있습니다.
     
   • 활용: 메시지 처리 시에만 특정 사용자 정보를 사용하고자 할 때 유용합니다.
     

각 방법의 차이점은 목적에 따라 다르게 나타날 수 있습니다. 전자는 전역 보안 관리에, 후자는 특정 메시지 처리에 더 용이합니다.

유사한 주제로 설명된 기존 답변을 통해 더 많은 정보를 얻으실 수 있습니다:

• 웹소켓 환경에서 SecurityContextHolder 사용과 STOMP 메시지 사용자 인증 처리 - 이 게시물은 SecurityContextHolder와 STOMP 메시지에서 사용자 인증 처리에 관한 설명을 포함하고 있습니다.
  

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.