FE 23일차

jae·2022년 6월 8일

어제의 오류 해결

검색기능에서
분명 리패치도 정상적으로 넣었고 ui도 그려넣었는데
검색을 실행 시 글목록 아이디나 글 번호등은 변경이 되고 패치가 되고 있는데 왜 안될까..
카운트는 정상적으로 리패치가 되니깐
카운트와 보드의 차이를 찾았고

export const FETCH_BOARDS = gql`
  query fetchBoards($page: Int) {
    fetchBoards(page: $page) {
      _id
      writer
      title
      createdAt
    }
  }
`;

수정 전

export const FETCH_BOARDS = gql`
  query fetchBoards($page: Int, $search: String) {
    fetchBoards(page: $page, search: $search) {
      _id
      writer
      title
      createdAt
    }
  }

수정후

쿼리를 받을 떄 페이지는 받았으나
서치에 대한 것이 없었다..
혹시나 하여 넣으니 정상 작동...ㅎ
한글자라도 놓치지말자..

오늘의 목표

로그인을 이해하려면 역사를 알아야 돼 Login
JWT토큰 이건 또 뭐야 JWT
로그인 인증 토큰은 어디에 저장해 Recoil

브라우저에서 아이디 비밀번호 입력하고 로그인을 시도하면
로그인과 비밀번호가 백에 전달을 함
백엔드 컴퓨터에서는 아이디와 패스워드가 db(User Table)에 있는지 검증을 하게 됨.
(아이디나 비밀번호는 UUID처럼 고유한 아이디로 저장이 됨)

DB에 유저가 있다면 로그인시도한 것을 백엔드컴퓨터의 메모리에 저장하게 됨
실무에서는 로그인이 무한으로 되는 것이 아니라 만료시간을 두기에 로그인 시작 시점 부터 만료시간까지를 검증하게 됨.

로그인이 시작되면 메모리 세션에서 세션아이디를 브라우저(브라우저메모리,쿠키등등)로 전송하게 됨

로그인을 시도하고 세션아이디를 받아오는 이 과정들을 인증이라 함.

로그인을 하고 가능한 요청(ex상품등록)을 한다 할때
요청 보내야할 내용을 백엔드로 보내면 백엔드에서는 로그인을 확인하고
로그인이 되어있지 않으면 거부 요청을 보내고
로그인이 되어있다면 요청 내용들을 DB로 보내어 요청을 진행한다.

요청에 대한 로그인이 되어있는지 확인하는 과정을 인가(Authorization)라고 함.

로그인 인증 시 메모리세션을 쓰는 것은 옛날 방식이고 사용량이 적은 곳에서는 아직 쓰이고는 있다

이렇게 유저의 정보를 백엔드 서버로 받다보니 여러명의 정보를 받기엔 한계가 있었음
이를 보완하고자

백엔드 컴퓨터를 scale-up(컴퓨터의 성능을 올려주는 것) 함

그 이후 컴퓨터의 성능을 올려도 더 많은 유저가 생기면 서버의 과부하가 발생되었음
그때 나온방법이 백엔드 컴퓨터를 여러 대로 하여 요청을 받는 것을 분산하였음

Scale out 똑같은 성능의 컴퓨터를 추가함
문제는 기존의 로그인 정보를 가진 컴퓨터가 아니라 다른 컴퓨터에서는 로그인정보를 찾을수 없음..

Scale out 문제점 보완하기

로그인 session을 Scale-out해오지 못하는 문제점을 보완하며 현재 많이 쓰이는 방법
로그인 session을 복사하지 못하니 로그인 정보를 db에 저장

but 로그인 정보를 DB로 옮기는 것이기에 DB의 과부하 발생

그래서 데이터를 쪼개서 해결방법을 찾음

데이터를 수직으로 쪼개는 수직 파티셔닝
데이터를 수평으로 쪼개는 수평 파티셔닝(샤딩)

수평 파티셔닝에서는 예를들어 유저 번호의 100번까지는 1번 데이터베이스
200번까지는 2번 데이터 베이스 등
이렇게 나누면 데이터 베이스를 분산할 수가 있어짐
disk에 저장된 데이터를 추출해 오는 것을 db를 긁는다(Scrapping)라고함

문제점 :

DB는 컴퓨터를 껐다가 켜도 데이터들이 저장되어있음.
안전하지만 느림

다시 이 문제점을 해결하기 위해서 Redis(메모리에 저장하는 임시 데이터베이스)에 저장해둔다.
redis는 메모리에 저장하기 때문에 위의 문제점을 해결해준다.

이렇게 저장된 특정 고유 ID(토큰)을 브라우저로 다시 돌려준다.
돌려받은 토큰은 브라우저 저장공간에 토큰을 저장해두고 어떤 행동을 할때 토큰을 같이 보내주어 사용자가 누구인지 식별한다.

stateless → 백엔드 컴퓨터에 상태를 가지고 있지 않음

2. JWT토큰 이건 또 뭐야 JWT

4번째 로그인의 역사 JWT 토큰

Encoded ⇒ 암호화
decoded ⇒ 복호화(암호를 푸는 것)

(exp는 만료기간)

로그인 정보를 서버나 db에 저장안하고 로그인
JWT 토큰은 유저 정보를 담은 객체를 문자열로 만들어 암호화한 후 암호화된 키(accessToken)를 브라우저에 줍니다.
암호화된 키는 브라우저 저장소에 저장해두었다가 유저의 정보가 필요한 API를 사용할 때 보냄
해당 키를 백엔드에서 복호화해서 사용자를 식별한 후 접근이 가능하도록 합니다.
JWT 토큰에는 해당 토큰이 발급 받아온 서버에서 정상적으로 발급을 받았다는 증명을하는 signature를 가지고 있음.
jwt 토큰을 복호화하면 json이 나오기 떄문에 DB나 radis에 안가도 됨

요청을 암호화한 JWT토큰을 글로벌 스테이트에 담아서 백엔드에 전달하면
백엔드에서는 그 내용을 복호화하여 exp를 확인한다음에 db에 전달을한다

백엔드에서는 복화할수 있는 Key를 가지고 있어서 인가와 인증을 실행할수 있다

플레이 그라운드에서 회원가입과 로그인 Docs

저 accessToken은 스테이트에 담겨있으며
암호화하고 복호화하는 Key는 백엔드에 저장되어있음.

키는 백엔드에 저장이 되어있지만
누구든지 암호화된 토큰을 열어볼수 있음.

https://jwt.io/

header : 토큰의 타입, 암호화시 사용한 알고리즘 정보
payload : 토큰 발행정보(누구인지, 언제 발행되었는지, 언제 만료될 것 인지)
signature : 토큰의 비밀번호

이 사이트를 통하게 되면 Key가 없으나 정보들을 열어볼수 있게됨...
따라서 중요한 데이터는 JWT 토큰에 저장해서는 안됨

Authorization 인가
Bearer 토큰 인증할때 그냥 들어가는 것
인가 절차를 거쳐 복호화하면 이제 로그인 정보를 받을 수 있음

암호화

암호화에는 단방향 암호화와 양방향 암호화가 있음
(jwt 토큰은 양방향 암호화)

양방향은 암호화를 하고 복호화를 할수 있음.
단방향은 암호화를 하고 복호화를 할수 없음

단방향 암호화(hash)
원본을 찾을 수가 없이 암호화를 함
복호화를 하려고해도 원본이 될수 있는 경우의 수가 많아서 찾을 수없음

요즘은 단방향을 레인보우 테이블이라는 것에 원본이 될 수 있는 경우의 수들을 전부 집어넣어 해킹하고자한다..

그래서 암호화된 내용에 salt 즉 소금을 뿌리듯 임의의 수를 넣어서 막고자함

3. 로그인 인증 토큰은 어디에 저장해 Recoil

이제 로그인을 하기 위해 토큰을 생성해서 로그인 페이지를 만드려고 하는데
이때 토큰을 일반 페이지에서 선언을 하고 가져오면 실행이 되지않는다.
토큰을 모든 페이지에서 실행하기 위해서
글로벌 스테이트에 담아서 사용 가능하게 하는 것이 효율 적이다.

글로벌 스테이트에 담긴 토큰을 이용하여

데일리 스크럼 객체

스택
출입구가 하나인 우물 형태의 데이터 구조
스택은 출입구가 하나이기때문에 가장 처음에 입력된 함수가 가장 나중에 스택을 빠져나감

이를 우리는 First In Last Out 이라고 하며, 앞글자를 따 FILO라고도 함

큐
양방향 출입이 가능한 파이프 형태의 데이터 구조
스택과 다르게 출입구가 나뉘어있어 가장 먼저 입력된 함수가 가장 먼저 빠져나감
이를 First in First Out 이라고 함

실행 컨텍스트와 실행컨텍스트로 인해 발생되는 현상

자바스크립트에 대해 이해하려면 중요한 핵심 내용인 실행컨텍스트

실행 컨텍스트: 실행할 코드에 제공할 환경정보를 모아둔 "객체"
함수에 대한 데이터가 생성이 되는건데
이 데이터를 저장해야하는데
자바스크립트는 콜스택(claa stack)에 저장해둠
스텍에 차곡차곡 쌓았다가 실행하는 것
큐에서 데이터 1,2,3, 등등이 쌓여있던 것이 실행 컨텍스트

실행컨텍스트로 파생되는 개념이 중요한데
실행컨텍스트를 이해해야 다른 언어를 할때도 받아드릴수 있음
실행 컨텍스트를 이해하는 것은 주니어 개발자는 어려울 수 있음.

해당 코드가 실행되지 않아도 자바스크립트는 선언된 변수를 이미 알고 있음
하단에 선언되어있던 코드가 상단로 끌어올려지는 호이스팅이 실행 컨텍스트때문에 생기는 것이였음.

스코프 체인이 일어난 코드
해당 함수 안에서 apple을 찾지 못해 해당 apple을 찾기 위해 위로 올라가서
망원 조준경처럼 해당 변수를 찾는 것

내가 함수의 상위 스코프는 선언된 곳이 아닌 선언된
본인의 선언 위치 기점으로 기준으로 상위인 함수임
터미널 언어로는 다이나믹 스코프라고 부름

closer 함수 위치별로 설명이 달라지기에 이부분에 대해서는 별도의 공부가 필요...ㅎㅎㅎㅎ

jae

이전 포스트

FE 22일차

다음 포스트

FE 23일차

오늘의 목표

Scale out 문제점 보완하기

2. JWT토큰 이건 또 뭐야 JWT

4번째 로그인의 역사 JWT 토큰

암호화

3. 로그인 인증 토큰은 어디에 저장해 Recoil

데일리 스크럼 객체

실행 컨텍스트와 실행컨텍스트로 인해 발생되는 현상

FE 22일차

FE 24일차

0개의 댓글

관련 채용 정보

FE 23일차

오늘의 목표

1. 로그인을 이해하려면 역사를 알아야 돼 Login

Scale out 문제점 보완하기

2. JWT토큰 이건 또 뭐야 JWT

4번째 로그인의 역사 JWT 토큰

암호화

3. 로그인 인증 토큰은 어디에 저장해 Recoil

데일리 스크럼 객체

실행 컨텍스트와 실행컨텍스트로 인해 발생되는 현상

FE 22일차

FE 24일차

0개의 댓글

관련 채용 정보