소켓 통신 테스트 및 소켓 인증 방식 리서치, Authentication / TrustedHost Middleware 추가

1. 소켓 통신 테스트

   • 데이터 송수신 테스트 및 채팅방 여러개 테스트 (아직 유저 구분은 하지 않았음)

   • 클라이언트가 페이지를 나가면 소켓 객체 삭제 → 이 부분은 나중에 알림과 같은 부분이 어떻게 구현되는지 보고 다시 봐야되겠다.

   • JSON 형식으로 데이터 주고 받기 → 인코딩 문제 있는데 서버에서 출력하면 제대로 나온다. 그럼 클라이언트에서 디코딩 해야되나?

     

2. 미들웨어 추가

   1. TrustedHost == allowed host
      • 지금 당장은 필요 없지만 보인 김에 같이 했다.
   2. Authentication
      • Django에서처럼 request.user를 하면 현재 로그인 된 유저가 나올 수 있도록 하기 위해서
      • 요청이 들어올때마다 매번 db에서 유저 객체를 가져오게 된다 → 별로 효율적이지 않지 않나 생각이 든다. → redis에 저장해놓고 불러옴으로써 해결

고민

1. 웹 소켓 주소는 1개로 가져가는가? 아니면 지금처럼 채팅방 별 주소를 부여하는가?
   • pub/sub 과 같은 구독 방식이라면 ws://.../{room_id}처럼 하는 것이라고 한다.
   • 그것이 아니라면 1개로 가져가는 것이다?
     • 생각해보면 지금 서버에서 connection manager에서 웹 소켓들을 관리하고 있다.
     • 이 말은 주소를 굳이 나누지 않더라도 메시지를 받을 소켓 객체들을 구분할 수 있다.
     • 그렇기에 1개로 하는 것이 맞는 것 같긴하다.
   • 이 부분은 좀 더 공부해보는 걸로
2. 소켓 통신에서 인증은 어떻게 하는가?

   • 그냥 http 통신에서 verify가 되었으면 소켓에서는 인증을 안해줘도 되는가?

     • 이건 아닌 것 같은데, 좀 더 찾아봐야겠다.

   • 인증을 해줘야한다면?

   • 지금 인턴에서 하는 것 처럼 토큰을 쿼리 스트링에 넣는다?

     • 근데 이건 생각해보면 보안이 그렇게 좋은 것 같진 않다.
     • 그럼 어떻게 해야될까...

   • 소켓 header, cookie, session, user 속성이 있길래 출력해보았다.

     • header는 그냥 http → websocket 업그레이드 헤더였다.
     • 이건 커스텀하게 바꾸지 못한다고 한다. 이는 jwt 토큰을 못싣는다는 것
     • 그럼 쿠키는? 실험해보니 http 쿠키랑 websocket 쿠키는 따로 관리된다.
     • 이것을 클라이언트 단에서 넣어서 보낼 수 있는가? 이건 나중에 프론트하고 리서치를 해봐야된다.

   • 다른 사람들은 어떻게 인증을 구현하는가?

     • 여기에 대해서도 논쟁이 조금 있는 듯 하다.

       Socket 인증 with API Gateway + Refresh JWT

   • 이 부분은 좀 더 찾아보고 생각해야되겠다.