210605 cookie, session, JWT(JSON Web Token)

Session & Cookie

cookie와 session이 필요한 이유

cookie와 session이 필요한 이유를 이해하기 위해서는 HTTP 프로토콜의 connectionless, stateless한 특성에 대한 이해가 필요하다.
connectionless는 클라이언트에서 요청을 한 뒤에 서버로부터 응답을 받으면 해당 연결을 끊어버리는 HTTP 프로토콜의 특징이다. HTTP가 TCP를 기반으로 구현되었기 때문에 네트워크 관점에서 keep-alive는 옵션으로, 연결비용을 줄이는 것을 장점으로 비연결지향이라고 한다.

stateless는 클라이언트와 서버의 통신이 끝나면 상태를 유지하지 않는 HTTP 프로토콜의 특징이다. 연결이 끊기는 순간 클라이언트와 서버간의 통신이 끝나고, 상태 정보는 유지하지 않는 것이 특징이다.

cookie와 session은 앞서 설명한 HTTP 프로토콜의 두 가지 특징(connectionless, stateless)이 가지는 단점을 해결하기 위해 사용된다.
우리가 특정 웹 페이지를 이용할때 한 번의 로그인을 한 뒤에 로그인한 사용자에 대한 인증을 유지하는 것이 바로 쿠키와 세션을 사용했기 때문이다. 쿠키와 세션을 사용하지 않는다면, 새로운 페이지로 이동할때마다 다시 로그인을 해야한다.

cookie와 session의 차이점에 있어, 정보가 저장되는 위치와 보안에 대한 부분도 있지만 이보다 더 중요한 것은 lifecycle에 대해 이해하는 것이 중요하다. cookie와 session 모두 만료시간이 있지만, cookie의 경우에는 클라이언트의 로컬에 파일로 저장되기 때문에 브라우저가 종료되어도 계속 정보가 남아있지만, 세션의 경우에는 만료시간과 상관없이 브라우저가 종료되면 삭제된다는 특징을 가지고 있다.

Read more

210605 CORS 문제해결

CORS

CORS(Cross-Origin Resource Sharing) ?

브라우저상에서 정보를 받는 곳과 보내는 곳이 신뢰할 수 있는 곳인지 확인하는 절차가 필요하다.
발신자와 수신자를 신뢰할 때 정보의 신뢰성과 보안이 보장될 수 있기 때문이다.

CORS issue는 브라우저와 서버 간의 요청에서만 발생되며, 서버와 서버간에는 발생하지 않는다.
요청을 보내는 쪽과 받는 쪽의 도메인이 서로 다른 경우, browser가 해당 요청을 차단한다.

동일 출처 정책(same origin policy)

하나의 근원지로부터 문서 또는 스크립트를 로드함으로써 다른 근원지로부터 오는 잠재적인 악성 문서를 격리하는 정책이다.

CORS 해결방법

직접적으로 사용자들의 browser를 변조해서 CORS 문제를 해결할 수 없기 때문에 아래의 두 가지 방법으로 CORS 문제를 해결할 수 있다.

  • 해결방법1: Proxy 방식

    예를들어 브라우저에서 다른 도메인인 백엔드 서버로 요청을 보내는 것은 문제가 되기 때문에 브라우저와 같은 도메인인 프론트엔드 서버를 거쳐서 백엔드 서버로의 요청과 응답을 처리하는 방법이다.

  • 해결방법2: Access-Control-Allow-Origin header 허용

    header의 Access-Control-Allow-Origin의 통해 요청이 오는 특정 도메인을 허용할 수 있다.

    예를들어 Express server에서 router의 callback 함수에서 response를 통해 header의 Access-Control-Allow-Origin 속성을 통해 특정 도메인을 허용해주거나, cors middleware를 사용해서 해결할 수 있다.

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    res.setHeader('Access-Control-Allow-Origin', '*');

    // cors middleware
    app.use(
    cors({
    // 요청을 보낸 도메인이 자동으로 허용된다.
    origin: true,
    credentials: false
    })
    );

210605 프론트엔드 - 백엔드 - 데이터 베이스 전체 흐름도

프론트/백엔드 서버와 DB 전체 흐름도

프론트/백엔드 서버와 DB 전체 흐름도

이번에 프로젝트를 새로 시작하면서 프론트/백엔드 서버와 DB의 전체적인 흐름에 대해서 다시 되새겨보았다.

이미지를 머릿속으로 그려가며 직접 손으로 노트에 그려보았다. (아래에 노트 첨부)

프론트/백엔드 서버와 DB 전체 흐름도 노트

210217 Development environment setting(pyenv, virtualenv, autoenv, pip, poetry 사용법)

이번 포스팅에서는 파이썬 가상개발환경을 구성하는데 사용되는 pyenv, virtualenv, autoenv, pip, poetry의 사용법에 대해서 정리를 해보겠다.

우선 가상개발환경을 구축해서 개발환경을 분리하는 이유에 대해서 알아보자.

왜 개발환경을 가상개발환경으로써 분리해서 관리해야 하는가?

파이썬에는 다양한 버전이 존재하고, 각 각의 파이썬 어플리케이션에서 사용되는 파이썬의 버전 또한 다양하기 때문에 가상개발환경을 구축해서 베이스가 되는 파이썬의 버전을 다르게 설정해서 관리해야 한다.
그리고 파이썬은 많은 패키지들이 배포되고 있기 때문에 이러한 패키지들을 한 대의 컴퓨터에서 돌릴경우 Python runtime의 version과 Python libray가 서로 충돌을 하는 문제가 발생한다.
이러한 문제는 기본적으로 한 대의 컴퓨터에 런타임 및 라이브러리가 전역적으로 설치가 되어 사용이 되기때문에 발생한다.

그럼 해결책은?

Read more