2024 11 13 논의점 - To-Letter/To-Letter-front GitHub Wiki

1. 재윤's 논의점

  1. 개별 편지 열람 api 필요한가?
    -> 지금 받은, 보낸 편지 데이터를 한번에 받아와서 그 데이터로 개별 편지 열람까지 하고 있어서.. 혹시 이거 말고 필요한 상황이 있나 모르겠어서 적어둡니다..
  2. 공유하기 기능에 대한 논의
    -> 공유하기 만들고 있는데 브리핑에 보인 사진처럼 기본 공유하기 기능에서 그칠것인지 아니면 여기에 각종 SNS들 버튼을 넣어서 만들건지 ex)카톡, 인스타 등
    참고로 SNS버튼 넣어서 만드려면 SNS API 다 가져오고 공유하기 모달창 커스텀해야함^^..
  3. 편지함, 편지에 무한 스크롤 구현할건지

2. 윤미's 논의점

  1. 편지쓰기 나가기 만들어주세오 확인했습니다~! 감사합니다!
    image
  2. [과제제안] 차후 nextJs로 갈아 엎을 것을 대비하여 최신 nextJs app-router 방식을 공부해볼 것을 요청합니다~!(기존에는 page-router 방식으로 동작했는데, 새로 만들고 싶은게 있어서 프로젝트 생성해보니까 많이 바뀌었더라구여 미리 바뀐 부분을 숙지해야 플젝 개편 때 혼란이 덜할 것 같습니다)
  3. 편지 api 관련
1. 삭제가 한 번에 되었음 좋겠습니다!
2. 검색 api가 가능했으면 좋겠어요!
2. 편지 데이터가 많아질 때의 처리 방안 필요
  1. 편지 읽기 부분 편지 이미지가 뜨기 전에 글자가 먼저 뜨는 부분 수정하면서 삭제 버튼 onoff가 가능한 공통 컴포넌트화 시켜도될까요??

  2. 프론트 배포 전에 체크할 것들을 따로 정리하는게 어떨까합니다..!
    -> 터미널에 뜨는, 에러는 아니지만 워닝 표시인 것들 확인
    -> seo 효율 처리 작업
    -> 재사용 컴포넌트 논의 후 리팩토링(계정/마이페이지 모달 및 편지함 관련)
    -> 변수명 규칙 재정립


3. 유정's 논의점

  1. JWT 토큰 저장 방식 논의

가. Header(현재 방식)
헤더의 경우 XSS 공격에 취약하며, 지금 AccessToken, RefreshToken 둘 다 웹 사이트에서 볼 수 있어서 토큰 탈취 가능

나. Cookie
쿠키의 경우 CSRF 공격에 취약함. 단 HTTPOnly 및 Secure 속성 설정, CSRF 토큰 등으로 쿠키의 안전한 사용 보장이 가능함.
단, 백엔드가 쿠키를 관리하다보니 서버에 부담이 된다고 함.

⚠️ **GitHub.com Fallback** ⚠️