고정 헤더 영역
상세 컨텐츠
본문
개념부터
selenium = 웹 브라우저를 이용하여 웹 사이트에서 자동적으로 제어할 수 있게 함.
Beautifulsoup = html과 xml 문서를 parsing하기 위한 패키지로 html에서 데이터를 추출하는데 유용한 구문 분석트리를 생성함
차이를 찾아보면
selenium의 경우 동적인 페이지를 불러올 때 유용함. 자바스크립트가 실행되어서 페이지를 채우는 경우 동적페이지라고 함. -> 실제 브라우저 엔진을 활용하기 떄문에 동적으로 실행되는 모든 페이지를 받아올 수 있음.
페이지가 모두 로딩될 때 까지 기다렸다가 html을 받아오기 때문에 bs4보다 느리긴 함.
bs4의 경우 동적페이지를 읽어오지 못하고 정적페이지만 받아올 수 있다.
그래서 selenium으로 html을 받아오고 bs4로 parsing하는게 속도향상 방법인 것 같다.
하지만 우리 프로젝트가 크롤링하고 싶었던 yes24같은 경우 bs4로도 전체페이지의 html받아오는게 가능했기 때문에 무리없이 bs4로 크롤링이 실행됐다.
이번엔 사용자 정보 관리할 때 보통 쓰이는 session과 token방식을 비교해볼까한다.
session과 token 방식은 사용자에게 입장권? 비슷한 느낌으로 사이트를 이용할 수 있도록 권한을 주는 기능을 하는 건 공통적이다.
하지만 차이점으로는 session은 사용자에게 입장권을 주고 session store에 1번 사용자 a입장권 / 2번 사용자 b입장권 --- 이런식으로 저장을 해놓고 1번 사용자가 로그인을 시도하면 session store에서 1번 사용자가 입장권이 있나? 쭉 찾아서 어 있다! 하면 입장을 시켜주는 느낌이고, 입장권에도 별 내용 없이 그냥 발급번호? 정도만 쓰여있다.
jwt방식도 사용자에게 입장권을 주지만 그 입장권에 적힌 내용이 많다. 뭐 이메일, 닉네임, 유효기간 등등 그래서 서버가 사용자를 검사할 때 입장권만 보고 유효기간이 안지났네? 통과~ 이렇게 진행한다.
그러면 jwt방식은 stateless하다. 사용자가 많을 수록 부화가 적다. 이유는 위에서 나와있는 것처럼 session은 사용자가 로그인을 할 때마다 session store에서 이 사용자가 있나~없나~ 다 검사해봐야하지만, jwt는 로그인을 시도한 사용자의 token만 보고 유효?안유효? 판단할 수 있다.
jwt을 통해 편하게 구현은 가능하지만 그냥 기본으로 쓰면 보안상의 허점이 많이보임.
허점 1. jwt는 디코딩이 매우 쉬움. 디코딩해주는 사이트도 존재할 정도.
2. 그리고 jwt에는 secret키가 존재하는데 이거 대충적어놓으면 brute force공격에 취약하다.
추가적으로 session 과 cookie의 관계
세션이 입장권같이 session storage에 사용자 - 사용자 식별 session ID 를 저장하고 로그인 할 때마다 이 session storage를 탐색함.
세션과 쿠키의 관계를 알아보기 전에 http의 특징은
사용자 --request-->> 서버
<<-- response with(쿠키)--
--request with-->>
<<--response--
HTTP 프로토콜의 특성이자 약점을 보완하기 위해 쿠키 OR 세션을 사용합니다.
기본적으로 HTTP 프로토콜 환경은 "connectionless, stateless" 한 특성을 가지기 때문에 서버는 클라이언트가 누구인지 확인해야한다. 이러한 특성들을 보완하기 위해 쿠키 와 세션을 사용함.
connectionless => 클라이언트가 요청을 한 후 응답을 받으면 그 연결을 끊어 버리는 특징.
HTTP는 먼저 클라이언트가 request를 서버에 보내면, 서버는 클라이언트에게 요청에 맞는 response를 보내고 접속을 끊는 특성이 있다.
헤더에 keep-alive라는 값을 줘서 커넥션을 재활용하는데 HTTP1.1에서는 이게 default인데, HTTP가 tcp위에 구현되어 있기 때문에 네트워크 관점에서 keep-alive라는 옵션으로 connectionless의 연결비용을 줄이는 것을 장점으로 비연결지향이라 함.
stateless => 통신이 끝나면 상태를 유지하지 않는 특징.
연결을 끊는 순간 클라이언트와 서버의 통신이 끝나며 상태 정보는 유지하지 않는 특성이 있음.
예를 들어, 쿠키와 세션을 사용하지 않으면 쇼핑몰에서 옷을 구매하려고 로그인을 했음에도, 페이지를 이동할 때 마다 계속 로그인을 해야 함. --> 쿠키와 세션을 사용했을 경우, 한 번 로그인을 하면 인증을 유지하게 된다.
세션을 쓰면되는데 굳이굳이 쿠키를 또 써야하는 이유?
세션이 쿠키에 비해 보안도 높은편이나 쿠키를 사용하는 이유는 세션은 서버에 저장되는데, 서버자원을 사용하기 때문에 사용자가 많아지면 소모되는 자원이 있음.
이러한 자원관리 차원에서 쿠키와 세션을 적절한 요소 및 기능에 병행 사용해서, 서버 자원의 낭비를 방지하며 웹사이트의 속도를 높힘.
쿠키(Cookie)란?
일단 구성요소
이름 = 쿠키를 구별하는데 사용되는 이름
값 = 그냥 값
유효시간 = 쿠키의 유지시간
도메인 = 쿠키를 전송할 도메인
경로 = 요청 경로
개념
쿠키는 클라이언트 로컬에 저장되는 키와 값이 들어있는 작은 데이터 파일.
토큰처럼 유효 시간이 정해졌을 때, 유효시간 동안 브라우저가 종료되도 인증이 유지됨.
쿠키는 클라이언트의 상태 정보를 로컬에 저장했다가 참조함.
클라이언트에 300개 까지 쿠키를 저장할 수 있고, 하나의 도메인 당 20개의 값만 가질 수 있고, 하나의 쿠키값은 4KB.
Response Header에 Set-Cookie 속성을 사용하면 클라이언트에 쿠키를 만들 수 있음.
쿠키는 사용자가 따로 요청하지 않아도 브라우저가 Request시에 Request Header를 넣어 자동으로 서버에 전송함.
쿠키 동작 방식
- 클라이언트가 페이지를 요청
- 서버에서 쿠키를 생성
- HTTP 헤더에 쿠키를 포함 시켜 응답
- 브라우저가 종료되어도 쿠키 만료 기간이 있다면 클라이언트에서 보관하고 있음
- 같은 요청을 할 경우 HTTP 헤더에 쿠키를 함께 보냄
- 서버에서 쿠키를 읽어 이전 상태 정보를 변경 할 필요가 있을 때 쿠키를 업데이트 하여 변경된 쿠키를 HTTP 헤더에 포함시켜 응답
쿠키 예시는
방문 사이트할 때, 아이디와 비밀번호를 저장하시겠습니까? 해서 다음에 로그인 할 때 그 정보를 유지시키는 기능
쇼핑몰의 장바구니 기능
