2024 11 13 논의점 - To-Letter/To-Letter-front GitHub Wiki
- 개별 편지 열람 api 필요한가?
-> 지금 받은, 보낸 편지 데이터를 한번에 받아와서 그 데이터로 개별 편지 열람까지 하고 있어서.. 혹시 이거 말고 필요한 상황이 있나 모르겠어서 적어둡니다.. - 공유하기 기능에 대한 논의
-> 공유하기 만들고 있는데 브리핑에 보인 사진처럼 기본 공유하기 기능에서 그칠것인지 아니면 여기에 각종 SNS들 버튼을 넣어서 만들건지 ex)카톡, 인스타 등
참고로 SNS버튼 넣어서 만드려면 SNS API 다 가져오고 공유하기 모달창 커스텀해야함^^.. - 편지함, 편지에 무한 스크롤 구현할건지
-
편지쓰기 나가기 만들어주세오확인했습니다~! 감사합니다!
- [과제제안] 차후 nextJs로 갈아 엎을 것을 대비하여 최신 nextJs app-router 방식을 공부해볼 것을 요청합니다~!(기존에는 page-router 방식으로 동작했는데, 새로 만들고 싶은게 있어서 프로젝트 생성해보니까 많이 바뀌었더라구여 미리 바뀐 부분을 숙지해야 플젝 개편 때 혼란이 덜할 것 같습니다)
- 편지 api 관련
1. 삭제가 한 번에 되었음 좋겠습니다!
2. 검색 api가 가능했으면 좋겠어요!
2. 편지 데이터가 많아질 때의 처리 방안 필요
-
편지 읽기 부분 편지 이미지가 뜨기 전에 글자가 먼저 뜨는 부분 수정하면서 삭제 버튼 onoff가 가능한 공통 컴포넌트화 시켜도될까요??
-
프론트 배포 전에 체크할 것들을 따로 정리하는게 어떨까합니다..!
-> 터미널에 뜨는, 에러는 아니지만 워닝 표시인 것들 확인
-> seo 효율 처리 작업
-> 재사용 컴포넌트 논의 후 리팩토링(계정/마이페이지 모달 및 편지함 관련)
-> 변수명 규칙 재정립
- JWT 토큰 저장 방식 논의
가. Header(현재 방식)
헤더의 경우 XSS 공격에 취약하며, 지금 AccessToken, RefreshToken 둘 다 웹 사이트에서 볼 수 있어서 토큰 탈취 가능나. Cookie
쿠키의 경우 CSRF 공격에 취약함. 단 HTTPOnly 및 Secure 속성 설정, CSRF 토큰 등으로 쿠키의 안전한 사용 보장이 가능함.
단, 백엔드가 쿠키를 관리하다보니 서버에 부담이 된다고 함.