회고록 (24.05.20 - 24.05.26 )

1. 공부했던 내용들

• BookShop 프로젝트

1. API 설계
2. app.js 구현
3. users, books, likes, carts, orders, categories 모듈화 및 틀 구성
4. books, categories, users 데이터베이스 테이블 생성
5. Controller.js 구현 (Book, Category, User)

• http-status-codes 모듈을 활용한 status code 사용
• crypto 모듈을 이용한 hashing : users 테이블의 비밀번호 hashing
• picsum ─ 테스트용 더미 이미지 웹사이트
• SQL - JOIN , DATE_SUB , BETWEEN ,NOW() 이용, 한달 이내 데이터 가져오기
• SQL - LIMIT _ OFFSET _ 이용, 개수 제한하여 데이터 가져오기 ( 페이징 )

2. 궁금했던 점들

• Q : BookShop 프로젝트의 강의에서, likes 테이블을 만들고 book_id , user_id 컬럼을 만들어서 개수를 세서 좋아요를 나타낸다고 하였는데,
  만약 likes 테이블에 몇 만개의 데이터가 들어가 있다면, 이 경우에는 사용자 입장에서 데이터를 조회할 때마다 매번 테이블 전체를 조회해서 서버에 부하가 생길 것 같다.

• A : Redis 라는 in-memory 방식의 DB관리 시스템이 있다. Python, JAVA, Node.js 등 다양한 환경에서 지원해준다.
  mariaDB를 이용했을 때처럼 컨테이너에 redis 이미지를 설치해서 실행시켜야 하고,
  Node.js 환경에서는 모듈처럼 npm install 하여 설치하여 사용할 수 있다.
  Redis는 인메모리 방식이기 때문에, 데이터의 읽기속도가 매우 빠르다고 한다.
  이 Redis DB서버를 캐시 역할로 사용해서, 자주 요청되는 값들은 Redis를 통해 메인 DB에 주기적으로 업데이트하고, 드물게 요청되는 자료들은 바로바로 메인 DB에 저장되도록 하여 사용자에게 좋아요 수를 빠르게 돌려주는 것처럼 수행할 수 있다.
  Redis 설계 - 자세한 내용(https://waspro.tistory.com/697)

• Q? : 강의에서는, 비밀번호 초기화 API에서 request의 body 값에 email을 받아서, 해당 email의 데이터값들을 변경했다.
• A : 근데 어차피 비밀번호를 초기화하려면 로그인 세션이 유지된 상태여야 할 것이고, 로그인할 때 jwt에 email에 대한 정보가 이미 있으니까, jwt를 decode해서 이메일을 불러서 사용해봤다.

Q : hashing(해싱)과 encryption(암호화) 의 차이는?

• 공통점 - 해싱과 암호화 모두 보안을 강화하기 위한 방법
• 차이점 -

1. 해싱 : 단방향 ( 복호화 불가 )
ex)

  const salt = crypto.randomBytes(10).toString('base64');
  const hashPassword = crypto.pbkdf2Sync(password, salt, 10000, 10, 'sha512').toString('base64');

위 코드에서 hashPassword를 다시 password로 돌려낼 수 있는 방법은 없다.
salt를 데이터베이스에 따로 저장한 뒤, 이를 이용해 사용자가 입력한 password를 저장된 salt로 hashing해서 해싱된 문자열을 비교하는 방법밖에 없다.
2. 암호화 : 양방향 ( 복호화 가능 )

암호화는 암호화를 수행할 때 사용했던 Key값을 알고만 있다면,
해싱과 달리 password를 복호화 할 수 있다.

결론 :
비밀번호처럼 굳이 복호화를 안해도 salt값을 같이 저장하여 사용자에 대한 정보를 식별할 수 있는 경우 해싱을 사용한다. 해커가 salt와 hashedPassword 값을 알아내도, 원래 password 값을 알아낼 수 없다.
메시지, 컨텐츠 등 사용자에게 보여져야 할 정보들을 복호화를 해서 원래 형태로 보여줘야 할 경우에는 암호화를 사용한다.