로그인의 방식
-
세션방식
-
토큰방식
-
Access/Refresh
현재 가장 많이 사용되고 있는 로그인 방식.
회원가입
회원가입은 Email, PassWord를 입력받고, 등록할 시 Backend API가 처리하여 데이터 베이스의 유저테이블에 저장이 되는데,
유저테이블에 진위 여부를 판단하여 메세지를 보낸다.
주의해야 할 점은 비밀번호를 그대로 PassWord로 저장할 시 보안적으로 매우 큰 위험이 따른다. 따라서 PassWord는 암호화 작업이 필요하다.
-단방향 암호화:
Hash :
해시 함수는 원래의 문장을 복호화할 수 없게 뭉개버린다는 장점, 그리고 원문과 해시값 사이에 선형적 관계가 없다는 특성을 지니고 있기 때문에 보안에서는 자주쓰인다.
해시 함수의 결과물은 고정된 길이의 숫자이므로, 원래의 정보는 손실된다.
해시값만 가지고는 이미 뭉개진 원문을 복원해내는 것은 불가능하다.
따라서 비밀번호, 전자서명, 전자투표, 전자상거래와 같은 민감한 입력의 무결성을 검증할 때 사용된다.
-양방향 암호화
...
Session
프론트엔드에서 이메일,비밀번호를 입력하고 CreateUser()라는 요청이나 LoginUser() 라는 요청을 보낼 시
Backend에서 해당 요청을 처리할 준비를 하게된다.
그때 Backend의 메모리 상에 Email, Password를 저장한 후,
FrontEnd로 부터 게시판이나 물건의 데이터를 보여달라는 요청이 들어 온다면
해당 메모리의 정보를 사용한다. 만일 로그인이 되어있는 상태라면 그것을 토대로 DB에서 가져오고 요청하고 돌려준다.
이러한 방식을 세션방식이라 부르는데 만일 서비스가 비대해질 수록
이 세션을 처리해야할 컴퓨터의 부하가 필수불가결적으로 늘어나게 되고, 해당 세션을 들고있는 서버가 죽을 경우 해당 회원이 로그인을 햇다는 정보 역시 사라지기 때문에 또다시 로그인 요청을 해야하게되는 사태가 벌어진다.
이를 개선한것이 바로 토큰방식이다.
Token
토큰 기반 시스템은 stateless 하다. 무상태. 즉 상태유지를 하지 않는다
이 시스템에서는 더 이상 유저의 인증 정보를 서버나 세션에 담아두지 않기에
위에서 서술한 서버에서 유저의 인증 정보를 서버측에 담아둠으로서 발생하는 많은 문제점들이 사라진다.
예를 들자면
따라서 만일 로그인요청이 들어올 경우, 똑같은 정보를 가진 서버를 여러대 만들어둔 후,
해당 요청에 대한 토큰을 하나 만든다.
해당 요청에 대한 토큰을 111이라 했을때, 해당 토큰에 대한 정보를 저장해 둔다.
그리고 요청이 들어왔을때, 해당 토큰에 대한 검증을 실시한다 (토큰검증사전작업)
만일 토큰에 대한 정보가 토큰 테이블에 존재할 경우, 해당 요청에 대한 응답을 돌려준다.
웹서버에서 토큰을 서버에 전달 할 때에는, HTTP 요청의 헤더에 토큰값을 포함시켜서 전달한다.
Scale-Up
데이터베이스 파티션에는 수직, 수평 파티션이 존재하는데,
수평파티션은 다른 말로 샤딩이라 한다.
DBMS 한 개로 처리할 수 있는 데는 한계가 있으므로 데이터베이스 여러 개를 사용하는 방식으로 데이터 조회 한계를 극복해야 한다. 이를 위해 분산 환경을 고려해 만들어진 데이터베이스를 이용하는 방법도 있지만 범위 검색에 취약하거나 JOIN 연산을 사용할 수 없는 등 기능에 제약이 많다. 따라서 상대적으로 풍부한 기능을 사용하면서 데이터 확장을 꾀할 수 있는 방법은 RDBMS를 샤딩(sharding)하여 사용하는 것이다. 계속 증가하는 데이터에 장애 없이 효과적으로 대응할 수 있어야 하고 서비스마다 다른 데이터 특성과 모델에 어떻게 대처할 것인가가 샤딩 플랫폼의 핵심이다.
샤딩은 물리적으로 다른 데이터베이스에 데이터를 수평 분할 방식으로 분산 저장하고 조회하는 방법을 말한다. ‘회원’ 테이블이 여러 DB에 있을 때 직업이 '타이탄'인 회원 대한 정보는 A DB에, '워록' 회원에 대한 정보는 B DB에 저장되도록 하는 방식이다. 여러 데이터베이스를 대상으로 작업해야 하기 때문에 경우에 따라서는 (JOIN 등) 기능에 제약이 있을 수 있고 일관성(consistency)과 복제(replication) 등에서 불리한 점이 많다. 예전의 샤딩은 애플리케이션 서버 레벨에서 구현하는 경우가 많았지만 최근에는 이를 플랫폼 차원에서 제공한다.
JWT - Access / Refesh Token
Props
상세페이지는 댓글페이지의 부모컴포넌트이고 등록컴포넌트는 별개의 컴포넌트라 보았을때
전체를 감싸는 컴포넌트는 app.js이다.
부모가 자식에게 props로 값을 넘겨줄 수 있는데,
이를 보자면 app.js에 정의된 Apollo의 Cache State를 자식컴포넌트에 전달하여 쓸 수 있었기에
따로 정의를 하지 않아도 사용할 수 있던것이다.
따라서 Apollo State가 변경될 시 해당 컴포넌트로 화면이 다시 그려지는것이다.
이러한 전역으로 상태를 관리하는 스테이트는 redux, modex등이 있는데 이를 잘 활용 하면 좋다.
하지만 redux를 사용할 시, 우리가 사용할 임의의 데이터도 redux에 넣어줄 수 있다.
apollo역시 redux랑 비슷하나, 쿼리한 내용들을 자동으로 넣어주기에, axios로 받아온것 말고 다른,
즉 우리가 직접 만든 데이터도 직접 사용 하기도 편하다.
이렇게 글로벌 스테이트를 더 편하게 관리 하도록 만들어진 api가 있는데
이를 context api라 한다.
context로 state를 묶는다면 props를 전달 받지 않고, 묶어서 사용할 수 있으나 context로 묶어줄 컨테이너가 필요하기 때문에 사용처에 알맞게 사용해야 할것이다
