Project1 - 2일 차: pr 리뷰, merge/ "userServices 회원가입, 로그인", 회고

이튿날: 대략적으로 한 것

어제 초기화 세팅을 완료, push 후 pr 했던     https://pm-developer-justdoit.tistory.com/85

초기화 세팅 pr 리뷰 및 commit, close , main에 merge와 

로그인, 회원가입 함수를 담은 'userservices' branch 깃허브에 추가 생성 후, push, pr 요청까지 하였다.

 

pr 리뷰 처음 해보았다.

주말에 foundation test로 깃허브 복습과 

깃허브에 branch 생성 후 clone, push 하는 거까지는 했었다. 

 

Project1- 1. 초기세팅 PR 후 commit (1)

 

Project1- 1. 초기세팅 PR 후 commit (2)

 

그리고 오후 standing meeting을 통해 

프론트와 백엔드의 진행상황 체크, 

이후 진행 방향을 정하였다.

 

1. 

프론트 두 분이서 구현해야 할 기능이 많기에, 필수 기능부터 마무리 하기로 하고,

우리도 api에 코드를 push 할 때에 필수 기능만 담기로 하였다. 

 

2. 프론트는 mock data를 기반으로,

백엔드 함수를 console.log으로 찍어보았을 때 나올 객체의 key와 value값을 보며 예상하며

기능 구현을 하기에,

백엔드의 api 함수의 key 값을 mockdata와  통일하기로 했다. 

 

모든 기준점은 mockdata.

 

오늘까지 백엔드는 mockdata 수정. (camelcase로 , api 에 필수 기능 코드만 넣기로) 

- 아래 링크에 나오겠지만, database mysql에는 snake로 언더바로 해야함. 프론트에 영향 없음. 

그리고 updatedat과 같은, 백엔드가 모델링하면서 추가한 칼럼은 프론트에 영향 없으므로 빼지 않아도 됨. 

---

백엔드 API 만들기: 1. "userServices 회원가입"

초기세팅 branch가 아닌 새 branch를 userservice로 

회원가입과 로그인 함수를 넣기로 하였다. 

 

이전에 해본 회원가입 로그인 함수에서 추가된 것은,

특수기호. 

 

1. email에는 . 과 @ 이 필수 포함되어야 합니다.
2. 비밀번호는 10자리 이상 필요합니다.
3. 닉네임에는 제한 사항이 없습니다.
4. profile image의 기본 이미지 링크

 

닉네임에는 제한 사항이 없지만, 우리팀은 이메일 중복 코드와 같이,

닉네임 중복 방지 코드도

에러 핸들링으로 넣었다.

---

다른 팀의 코드와 비교해보면서, 학습의 기회도 가졌는데,

 

이메일 중복여부는 해야하고, 

닉네임에는 제한 사항이 없기에, 중복여부 체크 안한 팀도 있었다. 

---

동기들의 코드를 보면서 코드 리뷰, 코드 비교를 스스로 해보았다.

>> 회원가입 시 이메일 중복 확인

 

회원가입 시 이메일 중복 확인에서,

 하나라도 있을 경우, 오류문 실행 파트에서

 

나는

 

    if (existingUser.length > 0) {
      const error = new Error("DUPLICATED_EMAIL_ADDRESS");
      error.statusCode = 400;
      throw error;
    }

// 배열로 찍을 때 하나라도 1이상 나오면 다 오류

 

동기는

 

if (existingUser.length) {
      const error = new Error("SAME_EMAIL")
      error.statusCode = 400
      throw error
    }

// existingUSer 배열에 하나라도 있으면 안된다

 

 

또다른 코드

//   if(existingData.length != 0){
            const error = new Error("alreadyEmail")
            error.statusCode = 400
            error.code = "alreadyEmail"
            throw error
        }

 

>> 회원가입 시 특수문자 포함

 

나는 

 

// 비밀번호에 특수문자 없을 때 에러 메세지
    const regExp = /^[a-z0-9_]{4,20}$/;
    if (!regExp) {
        const error = new Error("비밀번호 특수문자 사용");
        error.statusCode = 400;
        throw error;}*/

 

 

동기는 

// email 특수문자 (./@ 포함)
      const emailRegex = /[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}/g;
      const extractedEmails = email.match(emailRegex);
      if(!email.match(emailRegex)) {
        const error = new Error("특수문자 사용 안함")
        error.statusCode = 400
        throw error
      }
        console.log(extractedEmails);
  

 

팀 동기는 

        // 특수기호 함수선언
        function superStrongPassword(password) {
            const regex = /^(?=.[!@#$%^&()_+{}\[\]:;<>,.?~\\-]).{8,}$/
            return regex.test(password)
        }
        // 특수기호 사용 여부
        if (superStrongPassword(password) == false) {
            const error = new Error("NOT_STRONG")
            error.statusCode = 400
            throw error
        }

---

비밀번호 해쉬화

비밀번호를 회원가입 함수에서 해쉬화 해야 하는데,

비밀번호를 해쉬화 해야 하는 이유를 팀원에게 들었다.

 

아직 진도를 나가지 않은 부분이라, 내일 배울 것

 

아직 안 배웠지만, 팀원이 해 놓은 코드로 공부하기로! 

 

   // 비밀번호 해쉬화
  // const hashedPassword = await bcrypt.hash(password, 10)

---

백엔드 API 만들기: 2. "userServices 로그인 "

 

email, password를 필수 data 로 가져가고, 

이외의 예외처리나 요구사항이 없어서. 

 

데이터베이스에 고객의 이메일과 

그 이메일에 해당되는 패스워드가 있는지로 짰다. 

---

그런데 짜는 과정에서, 

의문점 의구심이 생겼고, 팀과 토의하며 해결했다. 

 

1. 로그인을 할 때에도 

회원가입할 때처럼 이메일에 특수문자가 있는지, 패스워드가 10자리 이상인지 확인해야 하는가?

-> NO!  

이메일, 패스워드가 조건에 맞는지가 아니라

저장된 데이터베이스와 일치하는지 여부를 보면 되니까. 

 

2. " app.post(/login,  async (req, res) => { "으로 시작하는 함수로 적을 것인가,

or

const logIn = async (req, res) => {

로 할 것인가?

 

const logIn = async (req, res) => { 로 한다면, 

 

1) userSerivce.js 파일에 아래 코드를 추가해야 햐고, 

module.exprots = {
  signUp: signUp,
  logIn: logIn,
  getUsers: getUsers,
}; 

 

2) app.js 파일에 아래 코드를 추가해야 하는데, 이미 깃허브에 push 후 main에 merge 했는데..?  

const userService = require("./services/userService.js");

app.post("/users", userService.signUp);
app.post("/login", userService.logIn);
app.get("/users", userService.getUsers);
app.delete("/users", userService.deleteUser); // 가장 마지막 user를 삭제하는 엔드포인트
app.put("/users/1", userService.updataeUser); 

---

내일 할 일 

1. 코드 분리 복습

 

2. posting 함수 쓰기

 

3. layered

 

4. 이후 토큰을 게시물 헤더에 올라가는 거 내일 게시물 함수 만들 때 

const authorizastion = req.header 이용해서 해보기 

 

---

2일차 회고 :[다시 복습한 것]

아직 jwt토큰에 대한 이해가 되지 않은 다른 팀의 동기들, 팀원들이 있어서 알려주며 복기.

 

"토큰을 발행 후에,

프론트가 토큰을 주면,

백엔드가 디코딩을 해서,

그 안의 id를 보고 안다.

패스워드는 위험해서 담지 않는다.

 

토큰은 '로그인 했다, 내가 누구이다'를

알려주는데, 누구인지는 id로 알 수 있다. " 

 

 

그리고 우리팀 팀원에게는

토큰 코딩에 대한 분석을 다시 하며 

알려주었다. 

 

토큰 코드의 위치와 그 이유,

jwt.sign() 함수와 그 인자 

user.id와 그를 담는 변수와 변수에 해당하는 객체와

두번째 인자 signature에 대한 설명.