fix : 그룹 캡슐 요약 조회 api 수정 #490

[seokho-1116]

작업 내용 (Content)

• 그룹 캡슐 요약 조회 API 로직 수정
• 응답 필드 추가
• 테스트 추가

링크 (Links)

• fix : 그룹 캡슐 요약 정보 필드 변경 #490

기타 사항 (Etc)

• 조금 복잡한 한 방 쿼리로도 해결이 가능했는데 그룹에 대한 권한을 먼저 확인하니까 이때 그룹원을 가져와서 조립하는게 더 깔끔했음

1. 그룹원을 먼저 조회
2. 그룹원에 요청한 사용자 여부 확인
3. 2에서 없으면 예외
4. 그룹 캡슐 요약 조회
5. 1, 4와 2에서 현재 요청한 사용자 그룹장 여부, 캡슐 개봉 여부와 함께 최종 DTO 구성

Merge 전 필요 작업 (Checklist before merge)

희망 리뷰 완료 일 (Expected due date)

[GaBaljaintheroom]

근데 나 궁금한게 사용자가 capsuleId만 가지고 있으면 그 그룹 캡슐을 조회할 수 있다는 권한이 있는거고 그룹 캡슐 요약 조회를 할 수 있는거 아닌가?

[seokho-1116]

근데 나 궁금한게 사용자가 capsuleId만 가지고 있으면 그 그룹 캡슐을 조회할 수 있다는 권한이 있는거고 그룹 캡슐 요약 조회를 할 수 있는거 아닌가?

캡슐 아이디는 특별한 값이 아니고 정수니까 그룹원이 아닌 사용자도 요청은 할 수 있고(항상 좋은 상황만 생각한다면 캡슐 아이디만 들고 있으면 권한이 있다는건데 어떤 행동이든 할 수 있는 클라이언트를 믿으면 안되니깐)
사용자(클라이언트)가 캡슐 아이디를 준다고 해도 그룹의 소유물이니(이외에는 볼 수 없음) 권한 확인을 꼭 해야하지 않을까 싶어서 권한 확인을 한거였음

jwt는 우리가 서명해서 클라이언트에 넘기고 클라이언트한테 받아서 서명을 검증해서 jwt의 subject값을 사용하는 것처럼 클라이언트가 넣어주는 값을 그대로 쓰기만 하는건 위험하지 않을까라고 생각했어. 어떤 권한을 가진 사람만이 볼 수 있어야 하니깐?

앱 자체가 내 소유물에 대한 권한 확인이 필요한 부분이 많으니까 성능 문제 발생이 예상되지 않으면 검증하는 부분을 빡빡하게 하는 것도 나쁘지 않을까 싶었어

[GaBaljaintheroom]

아하 APP이니깐 URL 노출이 잘 안되서 그렇게 생각했어. 근데 그래도 이게 맞긴하겠다. 굿굿

[GaBaljaintheroom]

수고했엉~