Project/codestates-final-project 29

9일차 / 요청에 대한 응답 더욱 더 세분화

한 것 토큰에 id랑 email만 담기 삭제시 이미 없는 id값 삭제하려고 할때 에러추가 (api문서도 수정) 수정시 여러개 한번에 수정하니까 new ~ new~ new~ 추가 (api 문서에도 추가) 수정시 이미 없는 id값 삭제하려고 할때 에러 추가 수정시 변한게 하나도 없을때 에러 추가 스몰톡시간에 토큰에는 비밀번호와같은 민감한정보 안넣고 변하기 쉬운 정보 안넣는다는 말을 들었다 변하기 쉬운 정보 안넣는 이유는 안에 있는 값이 바뀐다면 토큰이 유효하더라도 토큰에 있는 값과 db에 있는 값이 달라서 검증이 안되기 때문이기때문이다 그렇다면 토큰 검증하고 db와 비교하는 과정이 필요하다는 것인데 현재 코드상에 그런 로직은 없다 그런데 굳이 이 과정은 필요없다고 생각한다 왜냐하면 복호화 자체를 req.he..

8일차 / slack 완료 및 프론트 태그 도움

어제 const { WebClient, LogLevel } = require("@slack/web-api"); const client = new WebClient(process.env.SLACK_BOT_API, { logLevel: LogLevel.DEBUG, }); const channelId = process.env.SLACK_CHANNEL; exports.slack = async (message) => { try { const result = await client.chat.postMessage({ channel: channelId, text: message, }); console.log(result); } catch (error) { console.error(error); } }; 이렇게 모듈화 ..

7일차 / Slack Bot

한 것 환경변수들 추가 develoment와 production 데이터베이스 이분화 코드 간결화 전체적인 refactory가 끝났다 이제 기본 골자는 잡혔으니까 백엔드팀원과 서로 구현하고 싶은것을 각자구현하고 merge하기로 하였다 나는 slack을 이용해서 요청보낼때마다 slack에 메시지를 보내서 log를 남기기로 했다 구현한 과정은 링크로... JS로 slack bot 사용하기 (invalid_auth 에러 해결 법) await slack.slack("제목"); await slack.slack("내용"); 서버에 요청이 갈때마다 해당 요청정보를 slack 채널에 bot이 메시지를 보내는것을 구현하고자 함 우선 새 워크스페이스를 개설한다 https://slack.com/ S.. fullfish.tis..

6일차 / API fix, postman 자동화

한 일 상태코드 전반적 수정, 리프레시 토큰 수정 post시 입력 내용 부족하면 422 에러 리프레시토큰 401에러 3개로 세분화 (엑세스 토큰이 없을때, 리프레시 토큰이 없을 때, 엑세스와 리프레시 토큰 모두 만료시) res 응답 형식을 그냥 data만 전송하는 것에서 data키안에 data값을 넣고 같은 선상에 accessToken 추가 포스트맨 자동화 : https://fullfish.tistory.com/73 새로 안것 let a = 123 let obj = {a} console.log(obj) // {a:123} 위 코드처럼 obj = {a: a}로 안써도 된다

5일차 / postman자동화(미완), refreshToken

포트스맨 자동화는 내일 완성하고 쓰겠음 리프레시토큰은 엑세스토큰이 만료됐을때 재발행시켜주는 토큰. 일반적으로 아래처럼 엑세스토큰과 리프레시토큰을 발행한 후 엑세스토큰은 res로 보내고 리프레시토큰은 쿠키에 담는다 const accessToken = jwt.sign(payload, process.env.ACCESS_SECRET, { expiresIn: "1s" }); const refreshToken = jwt.sign(payload, process.env.REFRESH_SECRET, { expiresIn: "7d" }); res.cookie("refreshToken", refreshToken, { sameSite: "Strict", httpOnly: true, secure: true, }); res.st..

4일차 / SR 피드백

피드백 내용 에러로그 중요함 프론트엔드는 플로우차트가 정말 중요 백엔드는 API가 중요 DB는 수정하기 힘드니까 처음에 상세하게 짜야함 회원가입 중복의 경우 400말고 다른번호가 낫다 그리고 다음에 만났을때 다시 여쭤봐야할것이 2가지 조언받은부분에 대해서인데 1. /trip/:trip_id보다 trip/:id가 낫겠다 2. /user/:user_id/trip/:trip_id/diary/:diary_id를 /diary/:diary_id로만 만들어라인데 지금은 엔드포인트가 위의 2번경우처럼 다이어리를 삭제한다면 user : trip = 1 : N trip = diary = 1: N이라서 /user/:user_id/trip/:trip_id/diary/:diary_id (앞으로 a라고 하겠음)인데 /diary/..

2일차 / SR 완료

한것 프로토타입, API, DB 다이어그램 방의 인터넷이 나가서 핸드폰으로 참여했다 내일 고쳐지기를... Figma를 이용한 prototype https://www.figma.com/file/LcuNVrcQf6Uz7IqPZ1q95u/Untitled?node-id=4%3A3 Figma Created with Figma www.figma.com DBdiagram https://dbdiagram.io/d/624b8f7bd043196e39f587a3 API 문서 https://manseon.gitbook.io/api-docs/reference/api-reference/just-moment-trip just-moment-trip - API Docs http://www.remembertrip.com/trip/:tr..