5월 27일 회의 내용

5월 29일 회의 내용

토론(?) 내용

회원가입 API 시, /api/customers/signup vs /api/customers

→ 어떤게 더 명시적인가?

• 커스텀한 에러 코드를 정해서 서버에서 던지는 예외메시지가 프런트에 의존적이지 않게 한다. (서버에서 던지는 예외 메시지는 프런트의 참고(?)용)

• refresh Token필요이유

  → access token의 유효기간을 1년으로 하고 이를 localStorage에 저장한다면, access token을 탈취해서 httprequest를 만들어서 서버에 보낼 수 있음

  → access token의 유효기간을 짧게하자.(ex. 15분)

  → 새로고침등의 문제를 해결하기 위해서 refresh token 사용

  aceess token의 진위여부 확인(통과)

  access token의 유효기간은 만료 → 확인하고 → front에서 refresh와 access를 보냄 → refresh도 확인하고, 새로 access 발급

  → 쿠키에 http-only 옵션을 달아서 access token을 보내주면 이는 js로 접근 불가

  → access 가지고 httprequest만들어서 서버로 보내는 문제는 해결이됌

  → 그러면 access 토큰의 유효기간을 1년으로 하고 http-only옵션이 달린 쿠키로 저장하면 되지 않을까?

  → 쿠키는 기본적으로 요청을 보낼 때 담겨져서 보냄. → 따라서 직접 httprequest를 만들어서 보낼 수는 없지만…. (병민씨 보충 부탁)

• 회원 정보 조회

  /api/customers/me vs /api/auth/me

  JWT(JSON Web Token)로 로그인 REST API 만들기

  auth랑 customers 중 요청을 보낼 때 무엇이 더 중요하다고 생각하냐면, “나를 인증해줘" 보다는 “내 정보를 조회해줘" 의 의미이기 때문에 api/customers/me 가 더 적절하다고 생각한다. -아스피-

  /api/customers/me vs /api/customers/{customer_username}

  프론트엔드에서 사용자 정보를 최대한 숨기는게 좋다. -루나-

  /api/me vs /api/customers/me

  • url에 customers가 꼭 붙어야 하는가?
    • 접근하려는 api를 제한한다는 느낌으로 붙이는게 좋다.

에러

에러 상태 코드는 헤더에, 예외 메시지는 body에

• 회원가입 [400, Bad Request]

  • 이메일 중복
  • 패스워드 규칙이 맞지 않음
  • SpringValidation → 각각이 null 또는 빈값일때, 이메일 형식

• 로그인 [400, Bad Reqeust]

  • 이메일 또는 패스워드가 맞지 않음

    (이메일 또는 패스워드가 일치하지 않습니다.)

• 회원 정보 조회 / 수정 / 탈퇴

  • 로그인 되지 않은 상태로 내 정보 조회 [401, Unauthorized]

  • 토큰 만료

    → refresh & access

    기간 refresh(30일) access(7일)