👋 What is Eng-Fluencer?

Eng-Fluencer는 영어공부를 위한 화상채팅 사이트입니다!
Eng-Fluencer와 함께 재밌는 영어 스터디를 시작해보세요!

https://engfluencer.co.kr

개발자 Discord : https://discord.com/invite/dG8WHNwX

메인기능

🎥화상통화

openVidu 라이브러리를 사용하여 실시간 화상 통화가 가능하도록 구현하여 캠스터디를 구성했습니다.

✉채팅

sockjs와 stomp를 사용하여 실시간 채팅이 가능하도록 구현했습니다.

📑스크립트

서버에서 스크립트를 받아와서 리덕스로 저장하여 화면에서 확인이 가능하도록 제작했습니다. 원하는 태그를 클릭하면 해당 스크립트가 출력됩니다.

📜메모장

캠스터디를 진행하며 공부한 내용을 작성할 수 있도록 메모장 기능을 구현했습니다. 작성한 메모장은 마이페이지에서 확인이 가능합니다.

부가기능

⏰타이머

본인의 공부시간을 기록할 수 있도록 타이머 기능을 구현했습니다. 공부시간은 마이페이지에서 확인가능합니다.

🐦번역

스크립트 채팅방에서 한/영 번역 기능을 이용할 수 있습니다.

🥊악성유저 제어

웹소켓을 통해 실시간으로 van타입 유저를 받아서 강제퇴장 및 재입장 불가능하도록 구현했습니다.

👨‍👩‍👦‍👦참가자 목록 제공

웹소켓을 통해 입퇴장시 참가자 목록을 받아서 실시간으로 참가한 유저의 목록과 참가자 수를 확인할 수 있습니다

👑방장권한

악성유저 강제 퇴장 및 방장 권한 위임의 기능을 추가하여 스터디 참가 유저 관리를 용이하게 했습니다.

🖥둘러보기

메인화면&로그인

방 생성하기

입장 전 권한 확인

채팅&공지

신고&방장위임&강제퇴장

스크립트 방 기능

캠스터디방 둘러보기 &마이 페이지

🛠 Service Architecture 🛠

🔥트러블 슈팅

🔥 비정상적인 접속종료 유저를 구별하는 방법(Custom Ping-Pong)

• 문제 정의

  • 특정 상황에서 유저가 방에 남아있는 경우 발생

• 사실 확인

  • 나가기, 뒤로가기가 아닌 브라우저 강제종료 등의 방법으로 접속 종료 시 실제로는 접속이 종료됬지만 서버에서는 파악이 불가능
  • 이로 인하여 추후 재접속시 방 생성, 입장이 불가능한 오류 발생

• 해결 방안

  1. window.onbeforeunload 를 사용하여 검증
  2. 실시간으로 유저 접속상태를 검증

• 문제 해결

  Re.1 window.onbeforeunload 사용 시 새로고침, 페이지이동, 브라우저 종료시에 disconnect 함수를 작동시키는데 새로고침시에만 disconnect함수가 호출되지 않도록 하는것이 불가능따라서 실시간 유저 접속상태 검증(Ping-Pong)을 구현하기로 결정

  Re.2 Custom Ping-Pong (채팅방 입,퇴장시 서버DB에 저장하여 관리중)

  1. [FE] : 유저 입장시 3초 간격으로 서버에 WebSocket Request (Type : 8)
  2. [BE] : 받은 WebSocket의 시간은 Member Entity에 저장, 현재시간과 비교하여 알고리즘동작
     1. DB에 저장되어있고 정상적으로 WebSocket Request가 이루어진 유저 : 정상 유저
     2. DB에 저장되어있지만 WebSocket Request가 없는 유저 : 비정상적인 접속종료 유저 Member Entity의 Ping 시간 초기화 후, DB에 입장 정보 삭제
     3. DB에 없지만 WebSocket Request가 있는 유저 : 비정상적인 접근 유저 강제 퇴장처리 요청
  3. [FE] : Type: 8 로 전달받은 Response 실행(Case : 2-c)
     Response에 담긴 Id가 Local Storage에 저장된 접속중인 유저의 Id와 동일할경우
     Redirect를 통한 퇴장처리

🔥 Refresh-Token의 대안책

• 문제 정의

  • 스터디진행시간이 토큰 유효기간보다 길 경우에도 만료없이 지속적인 채팅이 가능하도록 유지해야된다고 판단

• 사실 확인

  • Access-Token이 탈취당할시 발생하는 피해를 최소화하기 위해 주로 Access-Token의 만료기간을 짧게하고 만료기간을 길게한 Refresh-Token을 발급
  • 그러나 상용화된 스터디 서비스를 참고하였을때, 접속시간이 24시간을 넘는 경우도 많음, 따라서 Refresh-Token이외의 대안책이 필요하다고 판단

• 해결 방안

  1. 만약 Refresh-Token을 사용한다면 채팅방 입장시마다 만료, 퇴장시 재발급 하는 방법
  2. Access-Token만을 활용, 대신 Local Storage에 저장시 암호화(Kakao Developers 참고)

• 문제 해결

  Re.1 비정상적인 접속 종료 및 만료되었을때에 탈취와 같은 요인들로 인하여 비효율적이라고 판단

  Re.2 Kakao Developers의 경우 Subject + Token으로 구성된 JWT 발급 중(이중 암호화) 그러나, 현재 토큰에 들어있는 정보를 기반으로 인증을 진행하기때문에 다른 방법을 고려

  Access-Token 발급시 FE에서 토큰을 3개로 분할, 이후 허수 값을 포함한 5개 정도의 값을 Local Storage에 저장, 서버에 요청을 보낼시 env에 처리된 3개의 값만 추출하여 재 조합후 헤더에 담아 전송, 만약 잘못된 조합으로 서버에 요청을 보낼시 탈취와 같은 문제라고 판단

🔥 유저 신고기능

• 문제 정의

  • 화상채팅과 일반채팅을 사용하기 때문에 악성 유저에대한 고려는 필수적이라고 판단

• 사실 확인

  • 현재 상용중인 타 서비스들은 주로 채팅신고/유저신고 방식으로 운영중

• 해결 방안

  1. 채팅신고 : 문제가되는 채팅을 직접적으로 fork 하여 관리자에게 전달하는 방법
  2. 유저신고 : 문제가되는 유저를 신고한뒤 관리자가 로그를통해 해당 유저에대한 문제점을 확인하는 방법

• 문제 해결

  Re.1 채팅신고 : 해당 채팅을 신고하여도 관리자 입장에서는 전반적인 채팅 맥락을 반드시 확인해야한다고 판단하였고, 채팅이 많이 진행되는경우 해당 채팅을 찾아 신고하는것이 UX적으로 비효율적이라고 판단

  Re.2 유저신고 : 신고된 유저에 대한 제제를 위해선 저장된 채팅 전체를 확인해야하므로 [어느방에서, 누가, 대략적인 신고받은시간] 을 서버에 전달하여 관리자가 최종적으로 확인하는 구조 고려 단, 관리자가 직접 제제하는 정책이다보니 제제 규정을 수립해야할 필요성이 있다고 판단

👍Member

Back

정민우 👑

임소윤

정동섭

Front

임다은

이예솔

김보미

Front

Communication

Back