로그인을 이해하려면 역사를 알아야돼!! Login
JWT토큰?? 이건또 뭐즤? JWT
로그인 인증토큰은 어디에 저장해?? recoil(글로벌스테이트)
리코일로 리덕스를 대신하기에는 조금모자람...
react-query,apolloclient에 더해
api가 아닌 데이터를 어떻게 저장할 것인가??? 했을때 추가적으로 사용하게 되는것이 recoil이다!!
export default function FetchPolicyTest() {
const { data } = useQuery(FETCH_BOARDS,{
fetchPolicy: "network-only"
});패치폴리시를 네트워크온리로 하면 캐쉬에서 안가져오고 새로운 에이피아이를 요청한다.
로그인
인증기반 에이피아이를 사용할때 과정이 굉장히 복잡하고 에이피아이요청을 할때마다 bd를 긁어야하는 번거로움이있었는데 현재는 어떻게 바뀌었을까?????
브라우저에서 프론트엔드접소하면 htmlcssjs를 받아옴
그러고 브라우저에서 아이디비번피고 로그인하면
프론트통해서 벡엔드로 아뒤비번 날라감
옛날에는 벡엔드에 메모리세션(변수)을 둬서
로그인을 기록하고 세션아이디를 프론트에 리턴한다.
컴퓨터에는 메모리(램에 저장,변수에 저장한거라 끄고키면 사라짐) 디스크(껏다켜도 안날라가는거)가있다.
판매등록이나 결제의 경우에는 세션아이디를 보내줘야함(+상품이름,가격)!! 그럼 백에서
세션아이디가 누구인지 찾아서상품등록해줌
영희 훈이도 로그인하면 세션아이디에 로그인데이터가 점점차기 시작한다.
등록,조회요청오면 그걸 보내주면서도 한곳에 저장을(메모리/램에 임시저장) 해줘야한다.
이러한 메모리 공간을 늘여주는걸 <스케일 업!!> 이라고 부름!
메모리를 늘여줘도 안될정도로 사용자가 늘면....??
컴퓨터 한대 더 ㄱㄱ...<스케일 아웃!!>
추가된컴퓨터에도 같은 소스코드 실행~
그럼 요청이 분산되게된당..!! 또부족하면 또 컴퓨터 ㄱㄱ
이런식으로 트래픽부화를 분산시키는것
근데 a컴퓨터에 에이피아이로그인요청하고 b컴터에 상품등록요청하면 b컴터의 세션에는 로그인 정보가없좌놔...???(세션있는곳은 스테이트풀, 세션없는곳은 스테이트리스)
벡엔드 서버가 스테이트풀상태에서 스케일 아웃을 하게되면 부화를 분산하기가 쉽지 않다...
스테이트 리스 상태(세션정보가 없는곳에서 에이피아이 요청하고 할때)일때 어떻게 로그인을 편안하게 할까??
세션아이디=인증토큰아이디
메모리세션을 디비로 옮긴가면???
결국엔 디비에 부화가 몰리게될테니까... 완벽한 해결책이라고 보기에는 어렵돳..!!
그럼 디비를 똑같이 늘이면 되지않을까???
그럼 디비 늘이고
테이블을 나눠가지자!!
유저테이블이라고 했을때
테이블을 나누는방식??
수직으로 나누는법!===수직파티셔닝!
수평으로 나누는법!===수평파티셔닝!!(샤딩)
크리에이트프로덕스면 백에서 디비가서 로그인정보확인하고, 크리에이트하고 브라우저로 결과보여줌!
여기서 발생하는 문제는 DB가 디스크에 저장되었다는 것임.
영구저장(디스크저장)에서 정보를 가져오는것도 시간이 걸리고, 정보를 등록하는데도 시간이걸려서 단점임.... ===>디비를긁는다.
디스크 말고 메모리에 저장하는법은없나???
메모리기반 DB!! 사용하자 === Redis에 저장!!
레디스에 저장하니까 엄청 빨라졌다!!
현재 가장 많이 사용하는 로그인 방식
1) Redis DB에 세션저장하긔~~~(아직도 굉장히 많이씀)
2) 두번째는?? JWT토큰!!!(이것도 굉장히 많이씀!)
JWT토큰!!!이란?
만약에 redis에도 저장안해도되는 방법이 있으면 정말루 대단할텐데... 그런거 없나??
객체를 만들어놓고
객체에서 아이디는 지우고 네임과 만료일을 넣어놓을후 암호화하는것!!!!!!!!
암호화해서 들고다니다가 필요할때는 복호화해서 사용하자~!!!!
암호화된 데이터를 토큰아이디로 쓰구!
이런 암호화된 정보를 JWT토큰 제이슨웹토큰(Javascript Object Notation)
브라우저에서 로그인하면 백에서 디비가서 디비에 저장된 애가 맞는지 확인하고 백에서 객체형태로해서 토큰내용을 만든다면 토큰을 암호화해서 브라우저로 보냄!!!
브라우저 저장소 또는 state에 저장하고
상품등록할때 이름,가격,토큰아이디(JWT토큰)을 보냄
그럼백에서 바로 복호화!! db긁는것 안해도되서 굉장히 효율적이다!!
jwt 관련해서도 독스가 있다!
JWT토큰을 엑세스 토큰으로 사용하겠다
엑세스 토큰중 JWT유형이 있는거지 엑세스토큰이 JWT인건아니다!
JWT토큰 유효기간 1시간 로그인정보를 탈취당하게되면 안되기때문..
그럼 1시간마다 로그인을 해야하나???
아니! refteshToken 이 있다!
이건 난이도 있다보니 추후에 배워보도록 하자!
어랏?? 조회해보니까 정보가 다 보이네...??비밀번호도 없눈뒙...?
JWT토큰은 누구든지 안의 내용을 다 열어볼 수 있답...
그래서 JWT안에는 중요한 정보는 저장하면 안됨!!!! 계좌번호라던지, 포인트를 적는다던지 하면안됨!!!
기껏해야 유저아이디 정도만!!!
뭐야 그러면 다보이는데 만료시간도 보이잖아? 그럼 만료시간만 조작하면 내가 마음대로 이정보 쓸 수 있잖아????
노우노우~~ 조작이 불가능함 ㅎㅎ 처음에 만들어졌을때 서명된내용이랑 비교를 하기 때문에 조작되었는지 확인됨~
하지뫈 볼수는 있으니까 중요한정보 노노!
DB에 비밀번호를 저장할때는 어떻게 저장될까??
그대로 저장되지는 않는다!
DB를 해킹하는 사람들도 있기 때문..ㅠㅠ
비밀번호 한번 들통나면 다른페이지에서 다 로그인해보는 나쁜넘들..
일단 디비저장할때는 암호화~
근데.. 복호화할수도 있는거자놤...
암호화에는 양방햔 암호화, 단반향 암호화가 있다!
지금같은 복호화할 수 있는 암호화가 양방향 암호화이다(JWT 토큰도 양방향)
단방향 암호화는 복호화 할 수 없는 암호화! 암호화만 가능..
비번은 단방향암호화 Hash방식을 통해서 저장한다!
비밀번호 찾기 했을때 비번을알려주는 사이트는 비번을 암호화하지 않았거나, 복호화되는 암호화를 사용한 곳임.... ㅠㅠ
올바른 사이트는 새로운 비밀번호를 다시입력해주세요 해야함!
해쉬한거 찾으려고 레인보우테이블을 들고다니는 해커들도 있돠...그래서 해쉬를 두번할수도 있돠..근데 또 그걸 뚫는돠... 으아아아앍
창과 방패의 싸움이돠 으얽
http headers에 {
"Authorization": "Bearer 토큰"
} 해서 보내주면됨
인증 : Authentication 로그인하고 토큰받아오는거
인가 : Authorization 이미받은 토큰을 가지고 인증기반에이피아이 사용할때 토큰이랑 리퀘스트 보내는거
인증은 한번만하고(1시간) 인가는 매번 해야하는것
Bearer 는 별건아뉨 그냥 문자열이라고 생각하좌 구냥 백에서 리플레이스할때 쓰는거윔 걍 국룰인거
loginAPI를 통해서 받아온 에이피아이를 state에 저장!(recoil)
다음페이지에서는 fetchUserLoggedIn 해서 이름을 받아옴~
