속닥속닥은 우아한테크코스 크루들을 위한 익명 서비스이다. 우아한테크코스 크루들을 타겟으로 하니 서비스 사용자가 제한되었다. 더 많은 트래픽을 경험해보고 싶고 또 우아한테크코스 지원자들에게 도움을 주고 싶어 예비크루 게시판을 추가하기로 했다.
"우아한테크코스 지원자들이 크루들에게 궁금한 점을 물어볼 수 있는 공간"이란 컨셉으로 기획을 시작했다.

기획

• 지원자들을 위한 "예비 크루 게시판"이 있어야 한다.
• "예비 크루 게시판"은 기존 게시판에서 제공하는 모든 기능을 제공해야 한다.
• 지원자들은 기존 게시판의 글, 댓글을 조회만 할 수 있다.

개발 과정 및 고민

코드 중복을 줄이기 위한 고민

• 회원가입 프로세스를 일반화하여 같은 api를 사용하도록 함
  • 들어오는 request에 따라 크루/지원자를 구별하고 적절한 서비스 메서드를 호출
• 테이블을 추가 하지 않고 데이터를 구분할 수 있도록 함

크루와 지원자를 식별하기 위해 고민

• 사용자에게 'APPLICANT'란 Role을 부여해 구분

권한이 없는 기능을 지원자가 사용하지 못하게 하기 위해 고민

• 게시판에 따라 지원자가 사용할 수 있는 기능과 없는 기능을 판단할 수 있음

기능이 속한 게시판 정보(BoardId)를 어떻게 구할지 고민

1. Request Body를 통해 게시판 정보를 받아옴
   • 악의적인 사용자에 의해 Request Body가 수정되어 의도와 다르게 동작할 수 있음
   • 인터셉터나 필터를 사용할 경우 Request Body를 두 번 읽을 수 있도록 추가적인 처리가 필요
     • Request Body는 InputStream에 저장됨. InputStream의 데이터는 한 번 읽으면 휘발되므로 여러번 읽을 수 있게 추가적인 처리가 필요
     • ContentCacingRequestWrapper는 Request Body가 읽혔을 때 데이터가 저장됨. 핸들러가 실행되기 전 권한을 검증해야 함으로 사용할 수 없음. @RequestBody 이후 추가적으로 값을 읽어야 할때 사용할 수 있는 기능
     • HttpServletRequestWrapper를 상속해 requestBody를 계속 읽을 수 있게 하는 custom 객체를 만들어야 함. 이는 body를 여러번 읽어야 하는 상황에서 새로운 객체를 항상 생성하므로 좋은 방법이 아님.
2. Database를 통해 게시판 정보를 받아옴 (채택)
   • Database의 여러 테이블을 탐색하는 이슈가 발생
     • 테이블의 Primary key를 통해 탐색이 이루어짐. MySQL에선 primary key는 index를 이용해 탐색하기에 탐색에 시간이 많이 걸리지 않음

관리 포인트를 한 곳으로 모음

• AuthService에 권한을 확인하는 메서드를 만들고 지원자가 사용할 수 없는 기능에서 해당 메서드를 호출해서 검사하도록 함