((TIL)) Node.js express로 인스타그램 구현하기3

🐯 intro

오늘은 로그인 기능을 구현했다. 
카카오 소셜 로그인 기능도 구현하고 싶었는데 자바스크립트 문법도 모르니까 참고한 블로그들의 코드들이 이해가 안간다.
해당 개념 Oauth도 다시 공부하면서 진행해야겠다. 

1. DB에 저장된 아이디인지 검사
2. 아이디가 일치하는 유저의 비밀번호인지 검사 (bcrypt.compare)
3. 모두 일치하면 access token, refresh token 발급

소셜로그인은 조금 더 개념 및 논리를 공부한 다음에, 내일 재도전..!!! 딱 기다려

---

🐯 쿠키, 세션, 토큰

Stateless한 프로토콜(HTTP)을 stateful한 서비스로 구현하기 위해 사용된다. 매 요청마다 로그인하라 한다면 너무 성가시다. 따라서 누가 로그인 중인지 상태를 기억하기 위해 쿠키,세션,토큰을 사용한다.

쿠키

• 공개 가능한 정보를 사용자의 브라우저에 저장한다(그렇다고 탈취되도 된다는 뜻 아님)
• 클라이언트가 서버로 데이터를 요청할 때 마다 쿠키자체를 담아서 보내기 때문에 유출 및 조작의 위험이 크다.

세션

• 세션은 쿠키 기반이다.
• 비밀번호같은 클라이언트의 인증 정보는 쿠키가 아닌 서버에 저장한다.
• 클라이언트가 서버로 로그인 요청을 보내면, 인증정보는 서버에 저장하고 클라이언트 식별자 JSESSIONID를 쿠키에 담아 보낸다.
• 그러면 클라이언트는 요청때마다 JSESSIONID 쿠키를 보내고, 서버는 해당 쿠키의 유효성을 판별해 클라이언트를 식별한다.
• 세션id는 중요한 정보가 아니기 때문에 탈취되어도 쿠키보단 안전하지만, 해커가 위장해서 요청하면 방법이 없다. 또 서버의 자원을 소모하기 때문에 서버 부하가 크고 서버를 거치니 속도도 느리다.

토큰

• 토큰은 인증을 위해 사용되는 암호화된 문자열로, 세션/쿠키와 함께 사용되는 대표적인 인증 수단 중 하나다.
• JWT는 인증에 필요한 정보들을 암호화시킨 토큰으로 쿠키/세션과 비슷하게 JWT토큰을 HTTP 헤더에 실어서 서버가 클라이언트를 식별할 수 있게 한다.
• header, payload, signature로 구성되어있다.

- header : jwt를 검증할 때 쓰일 알고리즘, 토큰의 타입이 담겨있다.
Base64 URL-Safe 인코딩된 문자열이다(암호화 X)

- payload : 클라이언트의 고유 ID(PK)같은 값 및 유효기간처럼 토큰에 담을 정보들이 담겨있다.
암호화하지 않기 때문에 중요한 정보는 담으면 안된다.

- signature : 인코딩된 header와 payload를 가지고 signature를 생성하기 때문에 데이터 위변조를 예방한다. 별도 저장소가 필요없고 한번 발급되면 유효기간 만료전까지 계속 사용가능하다. 그렇기 때문에 토큰 탈취 시 대처가 불가하며 이를 위한 대책방안으로 access token, refresh token을 사용한다.

refresh token

• access token의 유효기간을 짧게 생성하고, refresh token은 길게 생성한다.
• refresh token은 access token을 발급받기 위한 용도로 쓰이며, DB에 저장한다.
• refresh token에는 유저정보를 안담는다.
• DB에 저장해야하기 때문에 서버의 자원을 소모하며, access token이 만료될 때 마다 HTTP요청 횟수가 많아진다는 단점이 있다.

from https://tansfil.tistory.com/59

 

🐯 Layered Pattern

애플리케이션 설계와 개발에 있어서 가장 대표적인 아키텍처를 의미한다.
구성되는 계층의 갯수에 따라 N-tier architecture라고도 부르고,
각 계층은 어플리케이션 내에서의 특정 역할과 관심사별로 분리한다(관심사의 분리) 그리고 해당 계층에 관련된 기능만 수행해야한다.

3 계층 구조는 아래와 같다.

• 유저+브라우저와 상호작용하는 로직이 존재하는 Presentation layer
• 요청에 맞는 비즈니스 로직을 처리하는 Business layer
  비즈니스 로직이란, 데이터의 CRUD를 수행하기 위한 데이터의 모든 처리 - 이메일 중복여부, 비밀번호 양식 검사 등
• 데이터를 저장하고 관리하는 Persistence layer

장고에서는 프로젝트의 흐름이 urls.py -> views.py -> ORM -> Database -> views.py 로 이뤄졌다.

노드에서는 아래처럼 이뤄지는 걸 경험했다.

• Presentation Layer -> userController.py
• Business Layer -> userService.py
• Persistence Layer -> userDao.py

1. routes로 request가 들어온다.
2. controller로 request를 받는다.
3. service에서 비즈니스 로직을 처리하고
4. model에서 ORM을 적용한다
5. database에서 CRUD작업을 하고
6. model ORM 실행 결과의 반환값을 service로 전달한다.
7. service 전달받은 데이터를 가공해서 controller로 전달한다
8. controller 상태코드와 response를 전달한다.

왜 이렇게 여러가지 폴더를 생성하고 코드들을 분리해야하는지 잘 이해하지 못했는데.. 가만히 생각해보니까 다른 사람들과 프로젝트를 진행할 때 하나의 폴더에 모든 코드를 다 때려넣어서 작성했다면.. 코드의 충돌이 어마무시할테고, 유지보수나 테스트 코드 작성시 상당히 번거로울 것 같다. 코드의 가독성을 높이고, 유지보수성을 높이니까 이렇게 코드들을 분리해서 작성하는 걸 깨달았다.