2021 10 11
2021-10-10¶
refresh token¶
- 참고: https://pomo0703.tistory.com/208
- SSR의 필요성 - 느린 최초 페이지 진입 시간 (서버에서 그려서 주면 더 빨라) - 검색 로봇이 페이지 크롤링 못함 - 구글의 경우 CSR의 JS 해석해 검색 엔진 봇 넣어줌 - 네이버/다음엔 그런거 없음 => SSR 필요함!
- Refresh Token 도입 - SSR 서버가 최초 메인 페이지 렌더링 - 로그인 상황이라면 로그인 된 페이지를 그려야하고, - 로그아웃 상황이라면 로그인 필요 페이지를 그려야함 - Refresh Token의 저장소 - 만료기간이 길다. 탈취 가능성 적은곳에 넣자 - 일반적으로 쿠키에 저장 - 쿠키를 활용하는 SSR 로그인 과정 1. POST /login 2. 백엔드에서 cookie: refresh_token, body: { access_token : ~~~ } - redis에 [refresh_token : browserIP] 형식 저장 3. 프론트에서 변수에 access_token 저장, 쿠키에 refresh_token 저장 4. 이제 access_token을 ssr 서버에 넘겨줌 5. ssr 서버에서 로그인 html 그림 6. 프론트에서 로그인 html 렌더링 - 로그인 상태에서 새로고침? 1. 쿠키의 refresh_token을 ssr 서버에 넘겨줌 2. ssr 서버에서 백엔드 서버로 refresh_token과 browserIP 전달 3. 백엔드 서버에서 refresh_token과 access_token 재발급 - 만약 redis에 저장된 [refresh_token : browserIP] 가 다르다면 해당 엔트리 삭제 4. ssr 서버에서 access_token 발급 받은걸로 로그인 html 그림 5. 프론트에서 넘겨 받아 access_token 변수에 저장
Index 생성, 보기¶
- 참고: http://tcpschool.com/mysql/mysql_index_create
- 왜 필요한가? - 테이블에서 원하는 데이터 빠르게 찾기 위함 - 자주 사용되는 필드 값으로 만들어진 원본 테이블의 사본 - 사용자가 직접 접근은 X, 검색과 질의에 대한 처리에서만 사용됨 - 수정보단 검색이 자주 사용되는 테이블에서 사용하는 것이 좋음
- 인덱스 생성
- 그냥 인덱스 생성
- UNIQUE 인덱스 생성 (중복을 허용하지 않는 인덱스
- 인덱스 보기