수학과의 좌충우돌 프로그래밍

[python] Type Hints, python에 타입을 지정한다?

ssung.k — Sun, 20 Jun 2021 20:32:51 +0900

정적언어 VS 동적언어

Type Hints 에 대해서 알아보기 전에 우선 정적언어와 동적언어에 대한 이해가 필요합니다.

정적언어

컴파일 시 변수의 타입이 결정
변수 선언 시 자료형 지정
C, Java 등의 언어가 해당

동적언어

런타임 시 변수의 타입이 결정
실행 도중 변수에 예상하지 못한 타입이 들어와 Type Error 발생할 수 있음
python, javascript 등의 언어가 해당

Type Hints란

python은 대표적인 동적언어입니다.

그렇기 때문에 변수를 선언할 때, 함수가 매개변수를 받을 때 모두 자료형을 지정하지 않습니다.

위에서 말한대로 런타임 시 결정되기 때문에 실행 도중에 예상하지 못한 타입이 들어와 Type Error 발생할 수 있죠.

Type Hints 는 이를 방지하고자 타입을 표시하는 역할을 합니다.

하지만 이름 그대로 힌트일 뿐이지 타입을 강제화 하지는 않습니다.

Type Hints 사용법

Type Hints 를 어떻게 사용하는지 간단한 예제를 통해 알아봅시다.

python 3.5에서는 함수의 파라미터와 반환값에 대한 Type Hints 가 추가되었습니다.

def greeting(name: str) -> str:
    return 'Hello ' + name

런타임 중, __annotation__ 을 통해 확인이 가능합니다.

print(greeting.__annotations__)
# {'name': <class 'str'>, 'return': <class 'str'>}

python 3.6에서는 변수에 대한 Type Hints 가 추가되었습니다.

greeting_message: str = "hello minsung"

단순히 str과 int 외에 Dict, List, Tuple도 가능합니다.

from typing import Dict, List, Tuple

animal_cnts: Dict[str, int] = {
    "dog": 2,
    "cat": 1
}

heights: List[int] = [181, 163, 179, 172]


friends: Tuple[str, int, float] = ("minsung", 26, 180.9)

마무리

python 공식문서에 보면 아래와 같은 문구가 있습니다.

Python will remain a dynamically typed language, and the authors have no desire to ever make type hints mandatory, even by convention.

해석하자면 파이썬은 계속 동적 언어로 남을거고, Type Hints는 필수가 되지 않을거라는 말이죠.

하지만 Type Hints는 유용하게 쓰일 곳이 많습니다.

Django의 경우, swagger로 API 문서를 자동화할 때도 요긴하게 쓰이고, 코드의 질을 높이기 위한 좋은 방법이 될 수 있습니다.

[WEB] google이 만든 RPC, gRPC란

ssung.k — Tue, 15 Jun 2021 01:28:04 +0900

gRPC란

gRPC는 구글에서 개발한 어디서나 실행할 수 있는 오픈소스 고성능 RPC 프레임워크입니다.

RPC는 Remote Procedure Call의 줄임말로 원격 프로시저 호출이라고 합니다. 이는 별도의 원격제어를 위한 코딩없이 다른 주소공간에서 함수나 프로시저를 실행할 수 있게 해주는 프로세스간 통신 기술입니다.

특히 MSA 구조에서 각각의 서버가 다른 언어와 프레임워크로 개발되었을 경우에도 RPC는 문제 없이 서버간의 통신이 가능해집니다.

또한 기존의 REST 방식의 경우에는, 표준이 없어 파라미터의 응답이 명시적이지 않았을 뿐 아니라 JSON 형태의 데이터를 Serialization하는 비용이 발생한다는 단점이 있었습니다.

RPC는 이러한 문제점까지 해결하며 사용이 많아지고 있습니다.

Stub

RPC의 핵심 개념은 Stub 입니다.

서버와 클라이언트는 다른 주소 공간을 사용하고 있습니다.

그렇기 때문에 함수호출에 사용되는 매개변수를 변환하는 작업이 필요합니다.

안그러면 메모리 매개변수에 대한 포인터가 다른 데이터를 가리키게 됩니다.

이 변환을 담당하는 것이 바로 Stub 입니다.

Marshalling과 Unmarshalling

Stub은 클라이언트와 서버 각각에 존재합니다.

client Stub은 함수 호출에 사용될 파라미터를 변환합니다. 이를 Marshalling이라고 합니다.

또한 서버에서 넘어온 결과를 변환합니다.

server Stub은 클라이언트가 전달한 매개변수를 역변환합니다. 이를 Unmarshalling 이라고 합니다.

또한 함수 실행 결과를 변환합니다.

RPC의 동작 방식

RPC 동작 방식

Client가 Client Stub 호출
Client Stub가 파라미터를 표준 포맷으로 변경
Client Stub가 transport layer로 Server Stub에게 메세지 전송
Server Stub은 프로시저 호출
프로시저가 완료되면 Server Stub으로 반환
Server Stub가 transport layer로 Client Stub에게 메세지 전송
Client Stub은 반환 값을 변환하여 Client에게 전달

gRPC의 특징

HTTP/2

gRPC 는 HTTP/2를 사용합니다.

이는 HTTP/1.1에 비해 여러 측면에서 장점을 가지고 있으며 이에 대한 자세한 내용은 아래 링크에서 참고할 수 있습니다.

https://ssungkang.tistory.com/entry/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-HTTP-11-VS-HTTP-20

[네트워크] HTTP 1.1 VS HTTP 2.0

들어가기 전에 웹 개발자에게 있어서 HTTP는 빼놓을 수 없죠. HTTP는 1996년 1.0 버전으로 처음 release 되고 1999년 1.1 버전이 등장하였습니다. 그리고 1.1 버전은 HTTP 2.0이 등장하기까지 무려 15년 동안

ssungkang.tistory.com

Protocol Buffer

프로토콜 버퍼는 JSON, XML과 마찬가지로 직렬화 데이터 구조입니다.

프로토콜 버퍼는 다른 구조에 비해 데이터의 크기가 작습니다.

아래 예시를 봅시다.

아래 데이터를 JSON으로 표현한 경우 82byte의 크기가 사용되었습니다.

{ 
  "userName":"Martin",
  "favouriteNumber":1337,
  "interests":["daydreaming","hacking"] 
}

하지만 이를 프로토콜 버퍼로 표현한다면 33byte로 표현 가능합니다.

protocol buffers

어떻게 프로토콜 버퍼가 데이터를 표현하는지 위 그림에 나와있습니다.

필드명을 굳이 전부 표시하지 않고 5bit로 field tag에 숫자로 표현합니다.

또한 뒤에 3bit를 통해 type을 명시하며, 그 다음 byte에서는 데이터의 길이를 나타냅니다.

위 처럼 저장되면 사람이 보고 이해할 수 없기 때문에 proto 확장자를 가진 파일로 데이터에 대한 설명을 명시합니다.

message Person { 
    required string user_name       = 1; 
    optional int64 favourite_number = 2; 
    repeated string interests       = 3; 
}

이를 통해 데이터의 크기를 최소화하고 통신을 더 빠르게 할 수 있습니다.

RPC의 단점

gRPC에 대해 알아보고 있지만 gRPC의 단점은 기존 RPC의 단점과 동일하여 이에 대해 알아보겠습니다.

인간이 읽기 부적합

위에서 말한 proto 파일이 없을 경우에는 사람이 데이터를 해독하기에 어렵습니다.

따라서 유저와 직접적으로 소통하는 클라이언트일 경우 RPC 사용하기에 부적절합니다.

그렇기 때문에 내부 서비스간에 많이 사용됩니다.

proto 문법

proto 파일을 작성하기 위한 문법을 숙지해야 합니다.

[WEB] REST API 란

ssung.k — Mon, 14 Jun 2021 18:40:24 +0900

REST란

REST는 Representational State Transfer의 약자로 자원을 정의하고 자원에 대한 주소를 지정하는 방법 중 하나입니다.

URI를 통해 자원을 명시하고 HTTP method를 통해서 동작을 정의합니다.

자세한 설계 방법은 아래에서 살펴봅시다.

REST의 특징

동일한 인터페이스
HTTP 표준만 따른다면, 언어와 플랫폼에 종속되지 않습니다. 안드로이드, IOS, 웹에 종속되지 않습니다.
Stateless
서버에서 상태정보를 따로 저장하고 관리하지 않습니다. 이로 인해 서버의 구현이 단순해집니다.
Cacheable
HTTP의 인프라를 그대로 사용할 수 있기 때문에 HTTP가 가진 캐시 기능을 사용할 수 있습니다.

Self-descriptiveness (자체 표현 구조)
REST API만 보고도 의도하는 바를 명확하게 이해할 수 있습니다.

Client-Server 구조
클라이언트와 서버의 역할을 확실히 구분하여 클라이언트와 서버간에 개발해야 할 내용이 명확해지고 의존성이 줄어듭니다.

REST의 단점

REST의 장점은 특징을 통해 알아봤습니다.

REST의 단점은 아래와 같습니다.

제한적인 HTTP method
POST, GET, DELETE, PUT 4개의 HTTP로 제한됩니다.
표준의 부재
REST API는 표준이 존재하지 않습니다. 그렇기 때문에 클라이언트와 서버 개발자는 API 문서를 통해 소통을 하고 표준을 잡아가게 됩니다.

호환성
인터넷 익스플로어같은 경우에는 호환이 되지 않아 지원이 안 될 가능성이 존재합니다.

REST API 설계 기본 규칙

표준은 존재하지 않지만 설계를 위한 기본 규칙은 존재합니다.

해당 규칙을 잘 지킨 API를 RESTful하다고 합니다.

슬래시 구분자를 통해 계층 관계를 나타냅니다.
마지막에는 슬래시 구분자를 포함하지 않습니다.
언더바 보다는 하이픈을 사용합니다.
URI는 소문자로 표기한다.
URI에 파일 확장자를 표기하지 않는다.

[WEB] GraphQL, REST API의 대체?

ssung.k — Mon, 31 May 2021 22:49:35 +0900

GraphQL이란

GraphQL 는 Graph Query Language로 facebook에서 개발한 쿼리 언어입니다.

GraphQL 은 기존의 REST API의 단점들을 보안하기 위해 나온 통신 규약으로 REST API와 많이 비교됩니다.

REST API의 어떠한 문제점들을 보안하는지 알아봅시다.

REST API의 한계

REST API는 간단한 서비스에는 문제가 없지만 서비스와 복잡해질수록 Over-Fetching 과 Under-Fetching 문제가 발생할 수 있습니다.

또한 여러 환경에 맞춰 API를 제공해야하는 것도 쉽지 않은 일입니다.

따라서 각 환경에 맞추다보니 비슷한 역할을 하지만 Endpoint가 다른 API가 많이 개발됩니다.

Over-Fetching

Over-Fetching은 클라이언트의 요구사항보다 더 많은 데이터를 반환하는 경우를 말합니다.

예를 들어 생각해봅시다.

서버 개발자는 User의 여러 정보를 반환하는 API를 만들었습니다.

클라이언트는 User의 name 필드만 필요해도 API를 호출해야하고 불필요한 데이터가 많이 넘어오게 됩니다.

Under-Fetching

Under-Fetching은 클라이언트에서 원하는 데이터들을 위해 여러 API를 호출하는 것을 말합니다.

GraphQL을 통한 해결

GraphQL은 이러한 단점들을 모두 해결하였습니다.

하나의 Endpoint를 생성하고 클라이언트에게 필요한 데이터를 직접 쿼리를 통해 호출하게끔 하는 방식입니다.

예를 들어 위 Over-Fetching 같은 문제는 아래와 같은 쿼리로 필요한 데이터만 조회할 수 있습니다.

query {
	user(user_id: 1) {
		username
	}
}

마찬가지로 Under-Fetching 도 하나의 query에 여러 데이터를 호출하여 해결할 수 있습니다.

GraphQL의 장단점

REST API의 문제점을 해결하기 위해 등장하였다고 해서 GraphQL이 REST API보다 좋다는 건 아닙니다.

실제로 아직까지 현업에서는 REST API를 더 많이 사용하고 있습니다.

GraphQL의 장단점을 알아봅시다.

장점

하나의 Endpoint

위에서도 언급했듯이 GraphQL은 하나의 Endpoint를 갖습니다.

클라이언트 입장에서도 한 군데로만 요청을 보내면 되고 여러 API를 신경쓰지 않아도 됩니다.

하나의 Endpoint을 가진 GraphQL

최적화된 데이터

마찬가지로 위에서 언급했던 내용으로서 Over-Fetching 와 Under-Fetching 등의 문제가 발생하지 않아 필요한 데이터만, 한 번의 요청으로 가져올 수 있습니다.

환경에 종속적이지 않은 API

IOS, Android 와 같은 다른 기종에 대해 별도의 API를 개발할 필요가 없습니다.

단점

캐싱

하나의 Endpoint를 사용하기 때문에 HTTP에 제공하는 캐싱 전략을 그대로 사용하는 것이 불가능합니다.

따라서 GraphQL만의 캐싱 방법이 필요합니다.

파일 업로드

GraphQL은 아직 파일 업로드에 대해서 구체적인 구현 방법이 정의되어 있지 않습니다.

따라서 개발자 스스로 해결해야합니다.

그렇기 때문에 업로드만을 위한 분리된 API를 개발하기도 합니다.

마무리

GraphQL 에 대해서 설명을 하다보니 자연스럽게 REST API와 비교하는 내용이 많았습니다.

비록 GraphQL 이 REST API의 문제점을 극복하기 위해 등장했다고는 하나 아직까지는 REST API가 더 많이 쓰이고 있습니다.

둘의 장단점이 명확하니 상황에 맞춰 적절한 통신 규약을 선택하는게 중요합니다.

[네트워크] HTTP 1.1 VS HTTP 2.0

ssung.k — Fri, 28 May 2021 01:38:40 +0900

들어가기 전에

웹 개발자에게 있어서 HTTP는 빼놓을 수 없죠.

HTTP는 1996년 1.0 버전으로 처음 release 되고 1999년 1.1 버전이 등장하였습니다.

그리고 1.1 버전은 HTTP 2.0이 등장하기까지 무려 15년 동안 지속되었습니다.

하지만 시간이 지남에 따라 웹에서 담아야 할 정보는 점점 늘어났고, 지금은 하나의 웹사이트에 수 많은 멀티미디어 리소스들과 비동기 요청들이 발생합니다.

이런 상황에서 더 이상 HTTP 1.1은 버티기 힘들었고 HTTP 2.0이 등장하게 되었습니다.

왜 HTTP 1.1이 버티기 힘들었으며, HTTP 2.0은 어떤 점이 좋은지 알아봅시다.

HTTP 1.1이 어떻길래

HTTP Pipelining

HTTP 1.0은 기본적으로 Connection 당 하나의 요청을 처리할 수 있습니다.

그렇기 때문에 동시전송은 불가능하고 하나의 요청에 대한 응답이 온 후 다음 요청을 처리하게 됩니다.

위에서도 말했듯이 수 많은 멀티미디어 리소스들이 있는 상황에서 이러한 특징은 Network Latency를 발생시킵니다.

이를 위해 HTTP 1.1에서 HTTP Pipelining 이 도입되었습니다.

이는 TCP 안에 두 개 이상의 HTTP 요청을 담아 Network Latency을 줄이는 방식입니다.

하지만 이는 정확히 구현하기 힘들 뿐 아니라 HOL Blocking이 발생합니다.

HOL Blocking

HOL은 Head of Line의 줄임말로서 앞선 요청에 의해 뒤에 요청이 지연되는 것을 의미합니다.

HTTP Pipelining 을 통해 한 번에 여러 개의 이미지를 요청하는 경우를 생각해봅시다.

가장 앞에 요청한 이미지가 응답이 지연되면 두, 세번째 이미지도 지연이 발생합니다.

TCP 안에 여러 개의 HTTP 요청이 왔으므로 완료된 응답부터 보내면 되지 않을까라고 생각할 수 있지만 서버는 TCP에서 요청을 받은 순서대로 응답을 해야합니다.

무거운 Header

클라이언트와 서버 간에 수 많은 http 요청이 발생할 것이고 header의 정보는 대부분 동일합니다.

하지만 HTTP 1.1에서는 이러한 헤더를 중복해서 계속 보낼 뿐 아니라 cookie 정보 역시 매 요청마다 헤더에 포함되어 전송됩니다.

즉 불필요한 데이터를 주고 받는데 네트워크 자원이 소비되는 문제가 발생합니다.

HTTP 2.0이 등장하기 이전에

HTTP 2.0이 등장하기 전, 개발자들이 마냥 손 놓고 있지만은 않았습니다.

HTTP 1.1 안에서 위에서 봤던 문제점을 극복하기 위해 노력했습니다.

Image Spriting

여러 이미지 파일들에 대해 각각 요청을 하기 보다 한 번에 요청으로 끝내기를 택했습니다.

여러 이미지를 모아 하나의 큰 이미지를 만든 후, CSS로 해당 이미지의 좌표값을 지정해서 사용합니다.

Domain Sharding

하나의 Domain에 대해 여러 개의 Connection을 생성하여 병렬로 요청을 보냅니다.

하지만 브라우저 별로 Domain당 Connection 개수의 제한이 존재하므로 근본적인 해결책이 될 수 없습니다.

CSS, Javascript 최소화

전송되는 데이터의 용량을 줄이기 위해 CSS, Javascript 파일을 최소화하여 통신합니다.

HTTP 2.0의 등장

HTTP 2.0은 HTTP를 아예 새롭게 개선하기 보다는 기존 HTTP 1.1을 개선하는 방향에서, 성능 쪽에 초점을 맞춘 프로토콜로서2015년 2월 표준으로 승인되었습니다.

HTTP 1.1의 여러 문제점으로 구글이 개발한 비표준 개방형 프로토콜 SPDY를 기반하였습니다.

Multiplexed Streams

HTTP 1.1의 HTTP Pipelining 의 개선안으로 하나의 Connection으로 동시에 여러 개의 메세지를 주고 받을 수 있습니다.

또한 응답은 요청 순서에 상관없이 Stream으로 받기 때문에 HOL Blocking 도 발생하지 않습니다.

Multiplexed Streams

Stream Prioritization

응답에 대한 우선순위를 정해 우선순위가 높을수록 응답을 빨리 합니다.

예를 들어 하나의 HTML 문서에 CSS 파일과 여러 IMG 파일이 있다고 가정해봅시다.

만일 여러 IMG 파일을 응답하느라 CSS 파일의 응답이 느려지면 클라이언트는 렌더링을 하지 못하고 기다리게 됩니다.

따라서 CSS 파일의 우선순위를 올려 렌더링을 진행하며 IMG 파일은 도착하는 대로 띄어준다면 더 효율적입니다.

Server Push

서버가 클라이언트의 요청없이 응답을 보내는 방법입니다.

위와 마찬가지로 하나의 HTML 문서에 CSS 파일과 여러 IMG 파일이 있다고 가정해봅시다.

기존에는 HTML 문서를 요청한 후 다시 각각의 CSS 파일과 여러 IMG 파일을 위한 요청을 보내야 했습니다.

하지만 Server Push 로 인해서 클라이언트의 요청을 최소화하고 서버가 리소스를 알아서 보내줍니다.

Header Compression

HTTP 1.1의 경우 이전 요청과 중복되는 Header도 똑같이 전송하느라 네트워크 자원을 불필요하게 낭비하였습니다.

HTTP 2.0의 경우, Header Table과 Huffman Encoding을 사용하는 HPACK 압축방식으로 이를 개선하였습니다.

클라이언트와 서버는 각각 Header Table을 관리하고 이전 요청과 동일한 필드는 table의 index만 보내고, 변경되는 값은 Huffman Encoding 후 보냄으로서 Header의 크기를 경령화 하였습니다.

Header Compression

레퍼런스

https://developers.google.com/web/fundamentals/performance/http2/?hl=ko

https://kinsta.com/learn/what-is-http2/

[네트워크] 서브도메인과 A Record, CNAME

ssung.k — Thu, 27 May 2021 19:29:20 +0900

서브 도메인이란

서브 도메인 이라는 단어는 처음 들어봤어도 우리는 이미 익숙하게 사용하고 있습니다.

네이버의 서비스들을 예로 들어봅시다.

네이버는 메일, 카페, 블로그 등등 많은 서비스를 하고 있죠.

이럴 경우 각각의 url은 아래와 같습니다.

mail.naver.com
cafe.naver.com
blog.naver.com

가비아, 후이즈, 고대디 등 웹 호스팅 업체에 서브 도메인을 등록할 때는 CNAME과 A레코드 정보를 함께 입력합니다.

둘은 각각 무엇이고 어떤 차이가 있는지 알아봅시다.

A Record

A Record 는 DNS에 저장할 때 도메인 주소와 IP 주소를 매핑시키는 방법입니다.

도메인에 대한 요청이 오면 대응되는 IP 주소를 반환합니다.

NAME	VALUE
mail.naver.com	125.209.230.135
cafe.naver.com	210.89.168.66
blog.naver.com	223.130.195.143

CNAME

CNAME 은 Canonical Name의 약자로 도메인 주소와 도메인 주소를 매핑시키는 방법입니다.

NAME	VALUE
bar.example.com	foo.example.com
foo.example.com	192.0.2.23

bar.example.com 에 대한 요청이 오면 foo.example.com 를 반환하고 클라이언트는 다시 foo.example.com 에 대한 요청을 보내 192.0.2.23 을 얻습니다.

A Record VS CNAME

둘의 장단점을 비교해보고 어느 상황에 사용해야 할 지 생각해봅시다.

A Record 는 한 번의 요청으로 IP 주소를 바로 얻을 수 있으니 효율적입니다.

하지만 IP 주소가 바뀐다면 바꿔야 할 칼럼이 여러 개가 될 수도 있습니다.

여러 개의 서브 도메인이 하나의 IP 주소에 A Record 방식으로 매핑되어 있다면 전부 바꿔줘야하죠.

그에 비해 CNAME 은 IP 주소를 얻기 위해 2번 이상의 요청이 필요하므로 비효율적입니다.

하지만 IP 주소가 바뀐다면 하나의 칼럼만 바꿔주면 됩니다.

따라서 IP 주소가 자주 바뀌어야 하는 환경이라면 CNAME 을,

아니라면 A Record 사용을 추천합니다.

[WEB] JWT를 어디에 보관해야할까

ssung.k — Sun, 23 May 2021 20:05:37 +0900

저번 포스팅에서는 JWT에 대해서 알아보았습니다.

https://ssungkang.tistory.com/entry/WEB-Authentication-2-JWT

[WEB] Authentication (2) JWT

저번 포스팅에 이어 이번엔 인증하는 두 번째 방법, JWT에 대해서 알아보겠습니다. [WEB] Authentication (1) 세션과 쿠키 [WEB] Authentication (1) 세션과 쿠키 Authentication 우선 Authentication 이 뭔지부터..

ssungkang.tistory.com

JWT를 결국 클라이언트가 보관해야하는데 그 보관을 어디서 할 것인가에 대해 알아봅시다.

이번 포스팅은 웹 어플리케이션을 기준으로 이야기 하겠습니다.

Web Storage

Web Storage 은 HTML5부터 지원되는 기술로 브라우저에 데이터를 저장할 수 있는 방법입니다.

Web Storage 는 session storage와 local storage로 구분됩니다.

sessionStorage

sessionStorage는 각 세션마다 데이터가 개별적으로 저장됩니다.

즉 여러 개의 탭을 실행 중이면 각 탭 별로 따로 데이터가 저장됩니다.

이 때 세션이 다르면 다른 세션의 sessionStorage에 접근할 수 없습니다.

sessionStorage에 데이터를 저장하고 가져오는 방법은 아래와 같습니다.

sessionStorage.setItem('myCat', 'Tom');
var myCat = sessionStorage.getItem('myCat');

localStorage

localStorage는 브라우저에 반영구적으로 저장됩니다.

브라우저를 종료해도 데이터가 유지되며 도메인 기준으로 저장을 합니다.

A.com에서 B.com에 저장한 데이터를 접근할 수 없습니다.

localStorage에 데이터를 저장하고 가져오는 방법은 아래와 같습니다.

localStorage.setItem('myCat', 'Tom');
var myCat = localStorage.getItem('myCat');

두 방법 모두 javascript를 통해 쉽게 sotrage에 접근이 가능합니다.

쉽게 접근할 수 있다는 것은 장점이나 단점입니다.

XSS 공격에 취약해지기 때문에 보안 상의 문제가 발생합니다.

용량은 5MB로 cookies에 비해 여유롭습니다.

Cookies

Cookies 는 예전부터 많이 사용하던 기술로 기본적인 개념은 아래 링크에서 확인할 수 있습니다.

https://ssungkang.tistory.com/entry/WEB-Authentication-1-%EC%84%B8%EC%85%98%EA%B3%BC-%EC%BF%A0%ED%82%A4

[WEB] Authentication (1) 세션과 쿠키

Authentication 우선 Authentication 이 뭔지부터 알아봅시다. 여러분이 어떤 서비스를 이용할 때, 아이디와 비밀번호를 입력하고 로그인을 한 경험이 있으실 겁니다. 이것이 바로 여러분이 서버로 부터

ssungkang.tistory.com

Cookies 는 용량이 4KB로 Web Storage 에 비해 매우 작습니다.

하지만 Cookies 는 HttpOnly 옵션이 있습니다.

해당 옵션을 통해 자바스크립트를 통한 Cookies 접근을 막아 XSS 공격을 방지 할 수 있습니다.

또한 Secure 옵션을 통해 HTTPS로만 쿠키가 통신되도록 하여 보안을 더 높여 줄 수 있습니다.

하지만 CSRF 공격에는 취약합니다.

결론

두 가지 방법 모두 장단점이 있지만 결국 인증을 위한 JWT를 저장하는데 있어서 가장 중요한 부분은 보안입니다.

Cookies 에 저장하고 위에서 설명한 여러 옵션을 적용하여 보안을 강화할 수 있습니다.

비록 CSRF 공격에는 취약하지만 이 역시 CSRF TOKEN을 사용하여 보안을 강화할 수 있으므로 Cookies 에 저장하는 방법이 더 좋다고 생각합니다.

[WEB] Authentication (2) JWT

ssung.k — Tue, 18 May 2021 00:23:35 +0900

저번 포스팅에 이어 이번엔 인증하는 두 번째 방법, JWT에 대해서 알아보겠습니다.

[WEB] Authentication (1) 세션과 쿠키

ssungkang.tistory.com

JWT 란

JWT란 Json Web Token의 줄임말로 json 형태의 token입니다.

JWT을 만들기 위해서는 header, payload, verify signature 총 3가지가 필요합니다.

그리고 3개를 . 으로 조합하여 아래와 같은 형태로 만들어집니다.

header.payload.verify_signature

header

header는 일반적으로 token의 타입과 signature 알고리즘이 포함됩니다.

{
  "alg": "HS256",
  "typ": "JWT"
}

그 후 JSON은 Base64Url로 인코딩 됩니다.

Signature vs Encryption

Signature : 비밀 키를 가진 소수만 데이터에 서명할 수 있습니다. 그리고 공개 키를 가진 아무나 서명을 검증할 수 있습니다.

Encryption : 공개 키를 가진 아무나 데이터를 암호화 할 수 있습니다. 그리고 비밀 키를 가진 소수만 데이터를 복호화하여 확인할 수 있습니다.

payload

payload는 추가적인 데이터를 넣을 수 있습니다.

{
  "name": "minsung"
}

이 외에도 자주 쓰이는 항목들은 등록된 클레임으로 사전에 지정되어 있습니다.

iss: 토큰 발급자 (issuer)
sub: 토큰 제목 (subject)
aud: 토큰 대상자 (audience)
exp: 토큰의 만료시간 (expiraton), 시간은 NumericDate 형식으로 되어있어야 하며 (예: 1480849147370) 언제나 현재 시간보다 이후로 설정되어있어야합니다.
nbf : Not Before 를 의미하며, 토큰의 활성 날짜와 비슷한 개념입니다. 여기에도 NumericDate 형식으로 날짜를 지정하며, 이 날짜가 지나기 전까지는 토큰이 처리되지 않습니다.
iat : 토큰이 발급된 시간 (issued at), 이 값을 사용하여 토큰의 age 가 얼마나 되었는지 판단 할 수 있습니다.
jti : JWT의 고유 식별자로서, 주로 중복적인 처리를 방지하기 위하여 사용됩니다. 일회용 토큰에 사용하면 유용합니다.

그 후 JSON은 Base64Url로 인코딩 됩니다.

signing된 JWT는 변조로부터 보호되지만 누구나 읽을 수 있습니다.

따라서 별도의 암호화가 없다면 payload에 보안 상 중요한 값은 넣지 않습니다.

verify signature

verify signature을 생성하기 위해 인코딩된 header, 인코딩된 payload, secret이 필요합니다.

예를 들어 signing 알고리즘이 HS256 인 경우에는 아래와 같이 생성됩니다.

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)

HS256 은 대칭키 알고리즘으로서 하나의 키가 비밀 키와 공개 키 역할을 모두 수행합니다.

일반적으로 서버와 클라이언트의 통신 시, JWT를 사용한다면 서명을 하는 주체와 서명을 검증하는 주체가 모두 서버입니다. 따라서 대칭키 알고리즘을 사용해도 문제가 없을 뿐 아니라 비대칭키 알고리즘에 비해 연산이 간단하여 CPU 사용량도 적습니다.

verify signature은 메세지가 변조되지 않았음을 확인하는데 사용됩니다.

아래 사이트에서 직접 JWT를 만들어 볼 수 있습니다.

https://jwt.io/#debugger-io

JWT.IO

JSON Web Tokens are an open, industry standard RFC 7519 method for representing claims securely between two parties.

jwt.io

JWT를 이용한 인증

클라이언트에서 인증서버로 권한을 요청합니다. 다양한 방법이 있겠지만 일반적으로 올바른 아이디와 패스워드를 입력하여 인증을 받을 수 있습니다.
인증서버에서 JWT를 생성하여 클라이언트에게 반환합니다.
클라이언트는 JWT를 사용하여 보호된 리소스들에 접근할 수 있습니다.

JWT의 장단점

장점

인증에 필요한 모든 정보를 토큰 자체가 포함하기 때문에 별도의 인증 저장소가 필요 없습니다.
다른 token들에 비해 크기가 작아 트래픽에 대한 부담이 낮습니다.
expired 기능을 내장하고 있습니다.
수평 스케일링에 용이합니다.
micro service 환경에서 중앙집중식 인증서버에서 벗어나 개별 micro service에서 해결할 수 있습니다.

단점

JWT를 클라이언트에 저장하여 사용하기 때문에 DB에서 값이 바뀌더라도 JWT에 바로 적용할 수 없습니다.

payload에 데이터가 많아지면 JWT의 크기가 커집니다.
JWT는 거의 모든 요청에 전송되므로 트래픽 크기에 영향을 미칠 수 있습니다.
한 번 발급한 JWT는 값을 수정하거나 폐기가 불가능합니다.
기본적으로 암호화하지 않기 때문에 정보가 노출 될 수 있습니다.

Refresh Token

Refresh Token 은 JWT의 단점들을 극복하기 위해 나온 개념입니다.

JWT 값을 수정과 폐기가 불가능하기 때문에 중간에 탈취당할 경우 보안적인 이슈가 생길 뿐더러 DB 값이 바뀌더라도 갱신할 수 없었습니다.

따라서 access token과 refresh token , 두 개의 JWT를 사용합니다.

access token은 만료기간을 굉장히 짧게 가져가고, refresh token은 비교적 길게 가져갑니다.

이를 이용하여 인증하는 방법을 알아봅시다.

두 token을 발급받는 과정은 다음과 같습니다.

일반적인 경우에는 위에서 봤던 JWT를 이용한 인증 과 동일합니다.

이 때 access token이 만료된 경우에는 어떨까요?

만료된 access token으로 요청을 보낸 후 과정은 아래와 같습니다.

[MAC] 개발자를 확인할 수 없기 때문에 열 수 없습니다. 문제 해결

ssung.k — Sun, 9 May 2021 00:30:43 +0900

MacOS에서 인터넷에서 다운 받은 파일이 실행되지 않는 경우가 있습니다.

이 경우, 아래와 같은 창이 뜨게 됩니다.

안내 팝업 창

애플의 보안정책으로 바이러스를 포함한 App일 수 있기 때문에 위와 같은 설정을 해두었습니다.

따라서 인터넷에서 다운받은 파일은 새로운 속성이 추가되어 있습니다.

파일의 속성을 확인하기 위해서는 xattr 명령어를 사용합니다.

xattr {파일 이름}

위 명령어로 다운 받은 파일의 속성을 확인하면 아래와 같습니다.

xattr chromedriver\ 2

com.apple.macl
com.apple.quarantine

해당 파일을 실행 못하는 이유는 quarantine (애플의 격리속성) 때문입니다.

따라서 해당 속성을 삭제해야 합니다.

파일의 속성을 제거하는 명령어도 역시 xattr 입니다.

xattr -d com.apple.quarantine chromedriver\ 2

이제 정상적으로 파일이 열리는 것을 확인할 수 있습니다.

[JAVA] 08. 유용한 클래스

ssung.k — Fri, 15 Jan 2021 21:18:18 +0900

java.util 패키지에는 수 많은 클래스가 있지만 그 중에서 많이 쓰는 몇 가지를 알아봅시다.

java.util.Objects 클래스

Object 클래스의 보조 클래스로 모든 메서드가 static입니다.

객체의 비교나 널 체크에 유용합니다.

isNull(), nonNull()

isNull()은 해당 객체가 null인지 판단하여 널이면 true를 아니면 false를 반환합니다.

nonNull()은 정반대로 동작합니다.

static boolean isNull(Object obj)
static boolean nonNull(Object obj)

requiredNonNull()

해당 객체가 널이 아니어야 하는 경우에 사용합니다.

만일 객체가 null이면 NullPointException을 발생시킵니다.

두 번째 매개변수로 지정하는 문자열은 예외의 메시지가 됩니다.

static <T> T requiredNonNull(T obj)
static <T> T requiredNonNull(T obj, String message)
static <T> T requiredNonNull(T obj, Supplier<String> messageSupplier)

아래 예제를 보며 requiredNonNull의 편리함을 살펴봅시다.

// requiredNonNull이 없는 경우
void setName(String name){
    if(name == null)
        throw new NullPointException("name must not be null");
    this.name = name;
}

// requiredNonNull이 있는 경우
void setName(String name){
    this.name = Objects.requireNonNull(name, "name must not be null");
}

compare()

Object클래스에는 두 객체의 등가비교를 위한 equals()만 있고 대소 비교를 위한 메서드가 없습니다.

따라서 Objects 클래스에 추가되었습니다.

두 비교 대상이 같으면 0, 크면 양수, 작으면 음수를 반환합니다.

static int compare(Object a, Object b, Comparator c)

equals(), deepEquals()

Object 클래스에도 equals()가 있지만 Objects 클래스의 equals()는 null 검사를 해야합니다.

// Object 클래스의 equals()
if (a!=null && a.equals(b)){
  
}

// Objects 클래스의 equals()
if (Objects.equals(a, b)){
  
}

단 내부적으로 아래와 같이 구현되어 있기 때문에 객체가 둘 다 null일 경우에도 null을 반환합니다.

public static boolean equals(Object a, Object b){
    return (a==b) || (a!=null && a.equals(b)); 
}

deepEquals()는 객체를 재귀적으로 비교하기 때문에 다차원 배열의 비교도 가능합니다.

String[][] str2D = new String [][] {{"a", "b"}, {"c", "d"}};
String[][] str2D2 = new String [][] {{"a", "b"}, {"c", "d"}};


System.out.println(Objects.equals(str2D, str2D2));
//false
System.out.println(Objects.deepEquals(str2D, str2D2));
// true

toString()

Object 클래스의 toString()과 동일하지만 내부적으로 null 검사를 합니다.

null일 경우, 두 번째 인자로 사용할 값을 지정할 수 있습니다.

static String toString(Object o)
static String toString(Object o, String nullDefault)

java.util.Random 클래스

난수를 얻기 위해서 Math 클래스와 Random 클래스를 사용할 수 있습니다.

Math.random()은 내부적으로 Random 클래스의 인스턴스를 생성해서 사용하는 것이므로 둘 중에서 편리한 것을 사용하면 됩니다.

double randNum = Math.random();
double randNum = new Random().nextDouble();