우직하게

Mermaid ERD 문법

greatwhite — Mon, 2 Dec 2024 21:04:57 +0900

엔티티와 관계

<엔티티1> [<관계> <엔티티2> : <관계 이름>] 으로 구성됨.

엔티티1 : 엔티티 명이며 영문자나 _로 시작해야 하며, 숫자와 - 를 포함할 수 있다.
관계 : 두 엔티티 간의 상호 관계를 나타낸다.
엔티티2 : 다른 엔티티명.
관계 이름 : 엔티티1의 관점에서의 관계를 나타낸다.

HOUSE ||--|{ ROOM : contains 를 살펴보자.

위 예제는 “집은 하나 이상의 방을 포함할 수 있고, 방은 반드시 하나의 집에만 포함될 수 있다”로 해석된다. 위의 관계명은 엔티티1의 관점인 것을 확인할 수 있다. 엔티티2의 관점에서 봤을 때 동등 라벨은(?)은 추론하기 매우 쉽다.

위 문법의 <엔티티1> 부분만 필수이다. 이를 통해 관계가 없는 엔티티를 보여줄 수 있는데 다이어그램을 반복적으로 생성할 때 유용하다. 만약 뒷 부분 중 아무 부분이라도 넣게 된다면 모든 부분을 작성해야 한다.

관계 문법

각 문장의 관계 부분은 크게 3개로 나뉠 수 있다.

엔티티2의 관점에서 엔티티1의 cardinality
관계가 ‘자식’ 엔티티에 대해 신원을 부여하는지 여부
엔티티1의 관점에서 엔티티2의 cardinality

cardinality는 다른 엔티티의 요소가 해당 엔티티와 얼마나 연관될 수 있는지를 설명하는 속성이다. 위에서 다룬 예시에서는 집이 하나 이상의 방과 연관될 수 있었던 반면에 방은 하나의 집에만 연관될 수 있었다.

각 cardinality 표시자는 두가지 문자로 구성된다. 엔티티와 가까운 쪽이 최대 수를 나타내며, 다른한 쪽은 최소 수를 나타낸다.

엔티티1 기준	엔티티2 기준	의미
\|o	o\|	없거나 최대 하나
\|\|	\|\|	반드시 하나
`}o`	`o{`	없거나 하나 이상
}\|	\|{	하나 이상

Mermaid ERD에서는 多쪽에 limit을 제공하지 않는다.

식별 관계

부모 테이블의 키를 자식 테이블이 기본 키로 사용하는가? ⇒ 식별(O) VS 비식별(X)

관계는 식별 또는 비식별 관계로 분류될 수 있고 이는 실선과 점선으로 표시된다. 이는 해당 엔티티가 다른 엔티티 없이는 존재할 수 없는 종속적일 경우에 해당된다.

예를 들어, 사람들이 자동차를 운전할 때 보험에 가입하는 회사에서는 NAMED-DRIVER 에 대한 데이터를 저장해야할 수 있다. 모델링 단계에서는 먼저 하나의 자동차를 많은 사람들이 탈 수 있고 사람이 많은 자동차를 운전할 수 있다는 것을 관찰하는 것에서부터 시작할 수 있다. 두 개체는 서로 없이 존재 할 수 있으므로 이는 비식별관계이고 Mermaid에서는 아래와 같이 표현할 수 있다.

PERSON }|..|{ CAR : "driver"

위 표현식에서 .. 은 두 엔티티간의 관계를 표현할 때 점선으로 나타난다. 하지만 이 다대다 관계가 두 개의 일대다 관계로 나누면 NAMED-DRIVER는 사람과 차 둘 다 없이는 존재하지 못하는 식별관계인 것을 알 수 있다. 그렇기 때문에 --을 이용해 실선으로 표시하게 된다.

erDiagram
    CAR ||--o{ NAMED-DRIVER : allows
    PERSON ||--o{ NAMED-DRIVER : is

속성

속성은 {} 안에 여러 [자료형] [이름] 쌍으로 구성될 수 있다. 속성은 엔티티의 범위 안에 표시된다.

erDiagram
    CAR ||--o{ NAMED-DRIVER : allows
    CAR {
        string registrationNumber
        string make
        string model
    }
    PERSON ||--o{ NAMED-DRIVER : is
    PERSON {
        string firstName
        string lastName
        int age
    }

자료형은 반드시 영문자로 시작해야 하며 숫자, -, _ ,(), [] 을 포함할 수 있다.

이름은 자료형과 비슷하나 기본 키임을 표시하기 위해 *로 시작할 수 있다. 그 외에는 아무런 제한이 없으며, 유효한 데이터 유형의 암묵적인 집합도 존재하지 않는다.

엔티티 명 약칭(v10.5.0+)

[]을 이용해 약칭을 추가할 수 있다. 만약 아래와 같이 약칭을 추가하면 약칭이 엔티티명으로 표시된다. 띄어쓰기를 사용해야 한다면 " "를 활용할 수 있다.

erDiagram
p[Person] {
    string firstName
    string lastName
}

a["Customer Account"] {
    string email
}
p ||--o| a : has

속성 키와 비고

속성은 키 또는 비고가 있을 수 있다. 키는 주요 키, 외래 키, 고유키가 있고 각각 PK, FK, UK 로 표시한다. 하나의 컬럼에 대해 여러 키 제약을 명시하고 싶다면 쉼표(,) 로 이어 적는다.

비고는 큰따옴표(")를 사용해 처음과 끝을 감싼다. 비고는 내부에 큰따옴표를 포함할 수 없다.

erDiagram
    CAR ||--o{ NAMED-DRIVER : allows
    CAR {
        string registrationNumber PK
        string make
        string model
        string[] parts
    }
    PERSON ||--o{ NAMED-DRIVER : is
    PERSON {
        string driversLicense PK "The license #"
        string(99) firstName "Only 99 characters are allowed"
        string lastName
        string phone UK
        int age
    }
    NAMED-DRIVER {
        string carRegistrationNumber PK, FK
        string driverLicence PK, FK
    }
    MANUFACTURER only one to zero or more CAR : makes

추가

관계 이름에 두 단어 이상 사용하고 싶다면 큰따옴표(”)로 감쌀 수 있다.

관계 이름을 사용하고 싶지 않다면 ""와 같이 큰따옴표로 감싸진 빈 문자를 사용하면 된다.

14284 : 간선 이어가기 2 - Python

greatwhite — Tue, 12 Nov 2024 11:59:34 +0900

14284 : 간선 이어가기 2

접근

처음엔 단순하게 간선과 가중치가 나오길래 최소 신장 트리를 생각했었다. 하지만, 모든 정점을 연결하는 것이 아닌 특정 정점 두 개만 연결시켜야 했고 최소신장트리로는 풀 수 없음을 느꼈다.

그 다음으로 생각한 것은 유니온 파인드인데, 이것도 두 정점을 연결했을 때 최소 비용임을 보장할 수 없다.

마지막으로 생각한 것은 다익스트라였다. 모든 정점을 다 고려해도 두 정점 간의 최소 비용으로 연결을 보장한다.

간선 연결 과정에서 최악의 형태는 1자형태로 쭉 뻗은 그래프 형태가 되는데, 그렇게 되면 간선이 N - 1개가 된다. 그렇다면 최대 100,000개의 간선에는 중복이 있을 수 밖에 없다. 따라서, 그래프 저장시 가중치가 더 낮은 간선 취하면 될 듯 싶었다.

풀이

풀 때는 중복되는 간선이 많을 수 있어 배열방식으로 최솟값 갱신하는 방식이 더 빠를 것이라고 생각했는데, 의외로 리스트에 모든 간선 다 저장하는 방식이 더 빨랐다.

아마 추측해보면, 배열 방식을 사용했을 때는 각 정점마다 N - 1개의 간선을 모두 확인하고 넘어가기 때문인 것 같다.

전체 코드

배열 방식

import sys
from heapq import heappop, heappush

# print = sys.stdout.write
input = sys.stdin.readline

# 반드시 아래 두 라인 주석 처리 후 제출
f = open("input.txt", "rt")
input = f.readline
# 반드시 위 두 라인 주석 처리 후 제출
INF = float("inf")

N, M = map(int, input().split())
graph = [[INF] * (N + 1) for _ in range(N + 1)]
for i in range(1, N + 1):
    graph[i][i] = 0

for _ in range(M):
    a, b, c = map(int, input().split())
    graph[a][b] = min(graph[a][b], c)
    graph[b][a] = min(graph[b][a], c)

S, T = map(int, input().split())

def main():
    print(dijkstra())

def dijkstra():
    dist = [INF] * (N + 1)
    dist[S] = 0

    pq = [(0, S)]
    while pq:
        cost, to = heappop(pq)
        if to == T:
            return dist[T]

        for next in range(1, N + 1):
            if next == to or graph[to][next] == INF:
                continue

            next_cost = cost + graph[to][next]
            if next_cost >= dist[next]:
                continue
            dist[next] = next_cost
            heappush(pq, (next_cost, next))

if __name__ == "__main__":
    main()

리스트 방식

import sys
from heapq import heappop, heappush

# print = sys.stdout.write
input = sys.stdin.readline

# 반드시 아래 두 라인 주석 처리 후 제출
f = open("input.txt", "rt")
input = f.readline
# 반드시 위 두 라인 주석 처리 후 제출
INF = float("inf")

N, M = map(int, input().split())
graph = [[] for _ in range(N + 1)]

for _ in range(M):
    a, b, c = map(int, input().split())
    graph[a].append((b, c))
    graph[b].append((a, c))

S, T = map(int, input().split())

def main():
    print(dijkstra())

def dijkstra():
    dist = [INF] * (N + 1)
    dist[S] = 0

    pq = [(0, S)]
    while pq:
        current_cost, current = heappop(pq)
        if current == T:
            return dist[T]

        for next, next_cost in graph[current]:
            total = current_cost + next_cost
            if total >= dist[next]:
                continue

            dist[next] = total
            heappush(pq, (total, next))

if __name__ == "__main__":
    main()

2011 : 암호코드 - Python

greatwhite — Mon, 11 Nov 2024 15:00:48 +0900

접근

예전에 도전했다가 실패했었던 문제.

1	2	3	4	5
B	BE, Y	BEA, YA	BEAA, YAA, BEK, YK	BEAAD, YAAD, BEKD, YKD, BEAN, YAN

만약 1≤ code[i - 1] * 10 + code[i] ≤ 26라면, dp[i] = dp[i - 2] + d[i - 1]

아니라면 dp[i] = dp[i - 1]

풀이

다른 분들 풀이를 참고하니 좀 더 간단한 방법도 있었다. 특정 조건을 만족할 때만, 값을 더해주는 방식이다.

만약 현재 자리가 0이 아니라면 일단 문자로 만들 수 있다. 따라서, 바로 직전에 만든 문자열에 문자 하나를 추가하면 된다.

이를 식으로 나타내면 아래와 같다.

for idx in range(1, len(code)):
    if code[idx] > 0:
            dp[idx] += dp[idx - 1]

또한, 두 글자를 합쳤을 때 10과 26의 사이에 있다면 문자를 만들 수 있다. 따라서, 두 글자 전에 만든 문자열에 문자를 하나 추가하면 된다.

for idx in range(1, len(code)):
    if 10 <= code[idx - 1] * 10 + code[idx] <= 26:
            dp[idx] += dp[idx - 2]

위에서 나올 수 있는 경우의 수는 총 4가지이다.

현재 자리수가 0이 아니고, 직전 자리수와 합쳐서 문자를 만들 수 있는 경우
- 이 때, dp[idx] = dp[idx - 2] + dp[idx - 1] 이 된다.
현재 자리수가 0이고, 직전 자리수와 합치면 문자를 만들 수 있는 경우
- 이 때, dp[idx] = dp[idx - 2]가 된다.
현재 자리수가 0이 아니지만 직전 자리수와 합쳐도 문자를 만들 수 없는 경우
- 이 때는, dp[idx] = dp[idx - 1] 이 된다.
현재 자리수가 0이고, 직전 자리수와 합쳐도 문자를 만들 수 없는 경우
- 이 경우 dp[idx]는 0에서 갱신되지 않는다.

따라서, 1000과 같이 해독할 수 없는 코드에는 아래와 같은 dp테이블이 생성된다.

0	1	2	3	4
1	1	1	0	0

전체 코드

1차 풀이

import sys

# print = sys.stdout.write
input = sys.stdin.readline

# 반드시 아래 두 라인 주석 처리 후 제출
f = open("input.txt", "rt")
input = f.readline
# 반드시 위 두 라인 주석 처리 후 제출
MOD = 1_000_000
code = "0" + input().rstrip()
dp = [0] * (len(code) + 1)
# 점화식 처리하기 위한 장치
dp[0] = 1

def main():
    # 순서상 문자열의 두 번째
    # dp의 첫 번째
    # dp[1] = 1

    for idx in range(1, len(code)):
        prev, current = int(code[idx - 1]), int(code[idx])
        if current == 0:
            # 두 부분을 합쳐도 문자 성립이 안되면
            if prev * 10 + current > 26 or prev * 10 + current == 0:
                print(0)
                return
            # 두 부분을 합치면 문자 생성은 가능
            dp[idx] = dp[idx - 2] % MOD
            continue

        # 현재 숫자만 문자로 변환 가능
        if prev * 10 + current > 26 or prev * 10 + current < 10:
            dp[idx] = dp[idx - 1] % MOD
            continue

        # 모두 가능
        dp[idx] = (dp[idx - 2] + dp[idx - 1]) % MOD

    print(dp[len(code)] % MOD)

if __name__ == "__main__":
    main()

풀이 참조 후 개선

import sys

# print = sys.stdout.write
input = sys.stdin.readline

# 반드시 아래 두 라인 주석 처리 후 제출
f = open("input.txt", "rt")
input = f.readline
# 반드시 위 두 라인 주석 처리 후 제출
MOD = 1_000_000
code = [0] + list(map(int, input().rstrip()))
dp = [0] * (len(code) + 1)
# 점화식 처리하기 위한 장치
dp[0] = 1

def main():
    if code[1] == 0:
        print(0)
        return

    for idx in range(1, len(code)):
        # 길이를 늘려줬으므로 첫 번째 자리부터 시작가능
        if code[idx] > 0:
            dp[idx] += dp[idx - 1]

        temp = code[idx - 1] * 10 + code[idx]
        if 10 <= temp <= 26:
            dp[idx] += dp[idx - 2]
        dp[idx] %= MOD

    # 강제로 한 글자 늘렸으니 -1 해줘야함
    print(dp[len(code) - 1] % MOD)

if __name__ == "__main__":
    main()

Python 코딩 테스트 준비[update - 24.11.08]

greatwhite — Fri, 8 Nov 2024 14:33:28 +0900

빠른 입출력

[파이썬, Python] 빠른 입출력

import sys

# 빠른 입력
input = sys.stdin.readline
data = input().rstrip()

# 빠른 출력
print = sys.stdout.write

문자열 포매팅

[Python] 문자열 포맷팅하는 3가지 방법

# 문자열 포매팅
s = f"문자열 {값}"

정렬

[Python] f-string 포맷팅2 (2,8,16 진수, 1000단위 쉼표, 정렬, 문자채우기)

print(f"{bin(b)[2:]:>04s}") # 오른쪽 정렬 4칸 0 채우기

삼항 연산자

[python] 파이썬 삼항 연산자 (if ~ else ~)

[True] 일때 값 if condition else [False]일 때 값

람다식

파이썬 코딩 도장: 32.1 람다 표현식으로 함수 만들기

lambda x : x + 10 # 매개변수 O
lambda: 0 # 매개변수 X

다중 조건 정렬

[python] List(2) list sorting : 다중 조건 정렬 & 백준 1181번[단어 정렬]

lectures.sort(key = lambda lecture : (lecture[0], lecture[1])

힙

[Python] 힙 자료구조 / 힙큐(heapq) / 파이썬에서 heapq 모듈 사용하기

[Python] heapq 모듈

기본적으로 최소힙의 형태로 정렬되어있다.

힙 함수

heapq.heappush(heap, item) : item을 heap에 저장
heapq.heappop(heap) : 가장 작은 원소를 pop & 리턴. 비어있는 경우 IndexError 호출
heapq.heapify(x) : 리스트 x를 heap으로 변환

import heapq

pq = []
heapq.heappush(heap, 50)
heapq.heappush(heap, 10)
heapq.heappush(heap, 20)

heap2 = [50, 10, 20]
heap.heapify(heap2)

# 최솟값 확인
print(pq[0])

# 응용 최대 힙
maxHeap = []
heapq.heappush(heap, (-item, item))

pass, continue, break

[Python] pass, continue, break 차이점 알아보기

문자열 반복

COS Pro 2급 파이썬: 7.3 문자열을 연결하고 반복하기

# 문자열 반복
'str' * 3

유니코드 ↔ 문자 변환

Python string을 char로 바꾸는 법 feat. 대소문자 변환

s = "123123"
for s in str:
    # 문자을 아스키 코드로 변환
    print(ord(s))

# 아스키 값을 문자로 변환
chr(65)

defaultdict

[파이썬 기초] 유사 딕셔너리 defaultdict() 활용법

from collections import defaultdict

# dict와 달리 키 값이 없으면 defaultdict의 callable 매개변수가 동작하여 해당 값으로 초기화
int_dict = defaultdict(int)
print(int_dict['a']) # 0

max_dict = defaultdict(lambda: sys.maxsize)
print(max_dict['a']) # 9223372036854775808

list_dict = defaultdict(list)
print(list_dict['a']) # []

비트연산자

[ 파이썬 python ] 비트 연산을 위해 알아야 할 것들

num = 13
# bin()으로 감싸면 이진수 형태의 문자열이 된다.
print(bin(num)) # 이진수로 출력

# bitcount
print(bin(num).count('1'))

비트 마스킹

에라토스테네스의 체 Bitmask로 구현하기

반올림

Python의 round는 사사오입? 오사오입?

파이썬 round 함수의 오류 (2.5가 2가되는 마법 - 사사오입과 오사오입)

은행가의 반올림 (Banker's rounding) - ThinkCUBES

[Python] round 함수 : 반올림 (3) - 사사오입 반올림을 사용하는 방법

우리가 일반적으로 쓰는 반올림은 5이상에서 올리고, 5미만에서 버리는 사사오입이다. 하지만, 파이썬의 round함수는 5미만에서 버리고, 5초과에서 올리는 오사오입이다. 5의 경우 앞자리가 홀수인 경우에 올림을 하고 짝수인 경우에 버림을 하여 짝수로 만들어준다.

오사오입을 왜 써?

쉽게 말해서 10개의 숫자 중 6개의 숫자를 올리고 4개의 숫자를 버리는 것은 공평하지 않다는 것이다. 숫자가 중요한 금융권, 공학, 자연과학 계열에서 많이 사용한다.

파이썬에서 오사오입을 사용하려면 사용자 지정 round함수를 구현해서 사용해야 한다.

구현에는 3가지 방법이 있다.

1. decimal 모듈 사용

이 때 주의할 점은 round 함수에 매개변수를 하나만 넣으면 decimal 모듈을 써서 반올림 모드를 변경해도 사사오입이 적용되지 않는다는 점이다.

import decimal

# 산술 연산을 위한 환경 불러옴
context = decimal.getcontext()
# 반올림 방식을 사사오입으로 변경
# 오사오입은 decimal.ROUND_HALF_EVEN
context.rounding = decimal.ROUND_HALF_UP

# 양의 정수
round(decimal.Decimal('50'), -2)
# 음의 정수
round(decimal.Decimal('-5'), -1)
# 양의 소수
round(decimal.Decimal('0.5'), 0)
# 음의 소수
round(decimal.Decimal('-0.5'), 0)

2. 미세한 값을 더해주고 round() 사용

가장 편해서 자주 사용한다.

반올림해야하는 값이 0.xxx5라고 할 때 0.00001과 같이 해당 값에 영향을 줄 수 있는 가장 큰 값을 선택해서 더해주면 되는 것 같다.

a = 0.5
round(a + 0.0000001)

3. 직접 구현

def round_up(num, digits=0):
        return round(val+10**(-len(str(num))-1, digits)

파일 입력받기

[백준] Python-input.txt로 입력 받기! -공룡 루디

f = open("a.txt", "rt") # 텍스트를 읽기

input = f.readline

N, M = map(int, input().rstrip())

for-else와 while-else

2.5 for-else와 while-else

N = int(input())

for i in range(100):
        if i == N:
                break
else: # 모든 loop 다 돌면 출력
    print("done")

실행시간 측정

[Python] Python 코드 실행시간 측정 4가지 방법 (feat. Jupyter Notebook)

import time
import datetime # 시간 예쁘게 출력

start = time.time()
do_something()
end = time.time()

# 출력 -> 00:00:0x.xxxx sec
print(f"{str(datetime.timedelta(seconds = end - start)) sec}")

시간 조작

https://ctkim.tistory.com/entry/파이썬-datetime-라이브러리-가장-많이-사용하는-함수

any(), all() 함수

https://otugi.tistory.com/206

temp = [0, 2, 4, 8, 16]

if any(t > 0 for t in temp):
    print("a", end=" ")

if all(t % 2 == 0 for t in temp):
    print("b")

# 실행 결과 : a b

리스트(+셋, 딕셔너리) 컴프리헨션

https://bio-info.tistory.com/28

# 리스트 컴프리헨션
numbers = [i for i in range(1, 10)]
# 실행결과 : [1, 2, 3, 4, 5, 6, 7, 8, 9]

# if 조건문 사용
even_numbers = [i for i in range(1, 10) if i % 2 == 0]
# 실행결과 : [2, 4, 6, 8]

# if - else 조건문 사용
is_odd_number = [True if i % 2 == 1 else False for i in range(10)]
# 실행 결과 : [False, True, False, True, False, True, False, True, False, True]

# 셋 컴프리헨션
odd_numbers = {i for i in range(10) if i % 2 == 1}
# 실행 결과 : {1, 3, 5, 7, 9}

# 딕셔너리 컴프리헨션
chars_dict = {chr(i): i for i in range(65, 91)}
"""
실행결과 : 
{'A': 65, 'B': 66, 'C': 67, 'D': 68, 'E': 69, 'F': 70, 'G': 71, 'H': 72, 'I': 73, 'J': 74, 'K': 75, 'L': 76, 'M': 77, 'N': 78, 'O': 79, 'P': 80, 'Q': 81, 'R': 82, 'S': 83, 'T': 84, 'U': 85, 'V': 86, 'W': 87, 'X': 88, 'Y': 89, 'Z': 90}
"""

1245 : 농장 관리 Python

greatwhite — Mon, 26 Aug 2024 11:33:18 +0900

접근

평범한 BFS 문제라고 생각했는데 조금 다른 부분이 있었다.

기존에 많이 풀어봤던 땅 문제들과 다르게 단순히 땅의 개수가 아닌 가장 높은 높이를 기준으로 땅을 세는 방식이다. 초반에 산봉우리와 인접한 격자는 모두 산봉우리의 높이보다 작아야 한다 이 부분을 잘못봐서 조금 헤멨다. 결국 생각해보니 특정 지점이 가장 높다면 산봉우리로 볼 수 있다는 것으로 해석이 가능하다.

그러려면 순차 탐색으로는 찾기 어려울 수 있다. 왜? 산봉우리라고 생각했던 지점이 실은 인접한 격자일 수 있기 때문이다. 그렇다면 '차라리 값을 기준으로 최대힙으로 저장해놓고, 이를 꺼내서 사용하는 방법은 어떨까?'하는 생각이 들었고 이 방향으로 진행했다.

여기서 "인접하다"의 정의는 X좌표 차이와 Y좌표 차이 모두 1 이하일 경우로 정의된다. 이부분도 잘못 이해했었다. 처음에는 두 좌표의 차이의 합 즉, 상하좌우만 가능하다고 생각했었는데 대각선도 가능이였다.

풀이

_map = []
for i in range(N):
    row = list(map(int, input().split()))
    for j in range(M):
        if not row[j]:
            continue
        heappush(heapq, (-row[j], i, j))
    _map.append(row)

핵심은 이 부분인 것 같다. 처음 값을 받을 때 높이가 0인 경우에는 산 봉우리가 될 수 없으므로 을 제외하고 높이를 최대힙에 저장한다. 이렇게 함으로써 최대힙에서 산봉우리 먼저 뺼 수 있다.

ans = 0
while heapq:
    val, r, c = heappop(heapq)
    if v[r][c]:
        continue
    BFS(r, c, -val)
    ans += 1

위에서 저장한 최대힙에서 산봉우리 후보를 뽑고, 이를 BFS를 돌려 산봉우리와 인접 격자를 모두 방문시킨다. 이후 산봉우리에 포함되지 않은 후보에 대해서만 BFS를 다시 수행한다.

전체 코드

import sys
from collections import deque
from heapq import heappush, heappop

# print = sys.stdout.write
input = sys.stdin.readline
# 반드시 아래 두 라인 주석 처리 후 제출
f = open("input.txt", "rt")
input = f.readline
# 반드시 위 두 라인 주석 처리 후 제출
DIRECTIONS = ((-1, -1), (-1, 0), (-1, 1), (0, 1), (1, 1), (1, 0), (1, -1), (0, -1))

heapq = []
N, M = map(int, input().split())
_map = []
for i in range(N):
    row = list(map(int, input().split()))
    for j in range(M):
        if not row[j]:
            continue
        heappush(heapq, (-row[j], i, j))
    _map.append(row)

v = [[False] * M for _ in range(N)]

def BFS(r, c, val):
    q = deque([(r, c, val)])
    v[r][c] = True
    while q:
        y, x, value = q.popleft()

        for dy, dx in DIRECTIONS:
            ny, nx = dy + y, dx + x
            if (
                ny >= N
                or nx >= M
                or ny < 0
                or nx < 0
                or v[ny][nx]
                or not _map[ny][nx]
                or _map[ny][nx] > value
            ):
                continue

            q.append((ny, nx, _map[ny][nx]))
            v[ny][nx] = True

def main():
    ans = 0
    while heapq:
        val, r, c = heappop(heapq)
        if v[r][c]:
            continue
        BFS(r, c, -val)
        ans += 1
    print(ans)

if __name__ == "__main__":
    main()

CSRF 토큰 확인 불가 문제 해결

greatwhite — Sat, 29 Jun 2024 14:43:40 +0900

java.lang.NullPointerException: Cannot invoke "org.example.springsecuritystudy.repository.JpaTokenRepository.findTokenByIdentifier(String)" because "this.jpaTokenRepository" is null

왜인지 모르겠다..

생성 시 CustomCsrfTokenRepository를 잘 연결한다.

처음에는 @Autowired 문제인 줄 알았는데 POST로 접속하게 되면 정상적으로 로그가 다 찍힌다. 그래서 뭐가 문제인지 찾아보았다.

이 글 마지막에 있는 Spring Security 6 변화점을 통해 힌트를 얻었다. 공식 문서에서 해당 문구를 찾은 결과 아래와 같이 바뀐점을 찾아 볼 수 있었다.

Cross Site Request Forgery (CSRF) :: Spring Security

스프링 시큐리티 6부터는 CsrfToken 의 조회가 필요할 때까지 연기된다. 이는 스프링 시큐리티가 기본적으로 HttpSession 에도 CsrfToken을 저장하기 때문이다. 지연된 CSRF 토큰은 매 요청마다 세션에 요청하지 않음으로써 성능을 향상시킬 수 있다.

만약 지연된 토큰을 먼저 조회하고 싶고 모든 요청에 CsrfToken을 로드하려는 경우 아래와 같이 설정할 수 있다.

    @Bean
    SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        XorCsrfTokenRequestAttributeHandler requestAttributeHandler = new XorCsrfTokenRequestAttributeHandler();
        requestAttributeHandler.setCsrfRequestAttributeName(null);
        http
                .csrf(c -> c
                        .csrfTokenRequestHandler(requestAttributeHandler)
                        .csrfTokenRepository(new CustomCsrfTokenRepository(jpaTokenRepository))
                        .ignoringRequestMatchers("/ciao")
                )
                .authorizeHttpRequests(
                        request -> request.anyRequest()
                                .permitAll()
                );

        return http.build();
    }

csrfRequestAttributeName을 null로 설정하면 CsrfToken이 어떤 속성 이름을 사용할지 결정하기 위해서 처음에 반드시 로딩되어야 한다. 이는 CsrfToken이 매 요청마다 로딩되도록 한다.

이제 정상적으로 생성되는 것은 확인했다. 하지만 여전히 POST 토큰 값을 함께 보냈을 때 403 Forbidden이 발생했다.

Solving the "Invalid CSRF token found" Error in Spring Security 6.x

좀 더 찾아보니 공식문서에서 사용한 XorCsrfTokenRequestAttributeHandler 대신 CsrfTokenRequestAttributeHandler 를 사용하는 예제를 찾을 수 있었다.

결론적으로 CsrfTokenRequestAttributeHandler 를 사용하니 정상적으로 POST 요청으로 /hello에 접근할 수 있었다.

XorCsrfTokenRequestAttributeHandler는 BREACH 보호를 위해 CsrfTokenRequestAttributeHandler의 하위 클래스다.

Cross Site Request Forgery (CSRF) :: Spring Security

공식 문서에 따르면 매 요청마다 CSRF 토큰 값에 무작위 인코딩을 추가해 변경된 토큰 값을 반환하여 침해를 방지해주는 클래스였다.

성공적으로 POST Hello! 메시지를 받았다!

필터에 @Component 등록 시 자동 등록

greatwhite — Fri, 28 Jun 2024 15:28:21 +0900

스프링 시큐리티 인 액션 9장 공부 이후 필터에 @Component어노테이션을 걸고 Config 클래스에서 기본 인증 필터 위치에 등록했었다.

@Component // 여기가 문제
public class StaticKeyAuthenticationFilter implements Filter {
    private String authorizationKey;

    public StaticKeyAuthenticationFilter(@Value("${authorization.key}") String authorizationKey) {
        this.authorizationKey = authorizationKey;
    }

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain filterChain)
            throws IOException, ServletException {
        var httpRequest = (HttpServletRequest) request;
        var httpResponse = (HttpServletResponse) response;

        String authentication = httpRequest.getHeader("Authorization");

        if (authentication == null || !authentication.equals(authorizationKey)) {
            httpResponse.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
            return;
        }
        filterChain.doFilter(request, response);
    }
}

@Configuration
public class ProjectConfig {
    private static final Logger log = LoggerFactory.getLogger(ProjectConfig.class);
    private AuthenticationProviderService authenticationProvider;

    @Autowired
    public ProjectConfig(@Lazy AuthenticationProviderService authenticationProvider,
                                               StaticKeyAuthenticationFilter staticKeyAuthenticationFilter) {
                this.staticKeyAuthenticationFilter = staticKeyAuthenticationFilter;
        this.authenticationProvider = authenticationProvider;
    }

    @Bean
    public PasswordEncoder passwordEncoder() {
        Map<String, PasswordEncoder> encoderMap = new HashMap<>();
        encoderMap.put("bcrypt", new BCryptPasswordEncoder());
        encoderMap.put("scrypt", SCryptPasswordEncoder.defaultsForSpringSecurity_v5_8());
        return new DelegatingPasswordEncoder("bcrypt", encoderMap);
    }

    @Bean
    SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        http
            **.addFilterAt(staticKeyAuthenticationFilter, BasicAuthenticationFilter.class)**
            .authorizeHttpRequests(
                    request -> request.anyRequest()
                            .permitAll()
            )
            .csrf(Customizer.withDefaults());

        return http.build();
    }
}

10장을 공부하면서 다른 필터를 추가하게 되었고 이 과정에서 Config 클래스에서 addFilterAt() 메서드와 필드에서 StaticKeyAuthenticationFilter를 제거해줬다. 그 뒤 다른 필터를 테스트하였다.

책에서는 멀쩡하게 통신이 되었지만, 내 코드에서 추가한 필터는 동작하지만 HTTP 401 Unauthorized를 반환했다. 어디가 문제인지 하나씩 제거하다보니 @Component가 문제인 것을 알게되었고 검색해보니 아래와 같은 내용이 있었다.

스프링 부트에 필터를 '조심해서' 사용하는 두 가지 방법

읽고 로깅해봤는데 아마 11단계에서 StaticKeyAuthenticationFilter가 호출되는 과정에서 Authorization헤더가 없어 문제가 발생한 줄 알았다.

curl -v -H "Authorzation:auth_123" http://localhost:8080/hello

...
< HTTP/1.1 401
...

위와 같이 Authorization 헤더와 키값을 넣어줬는데도 401이 발생했다. 혹시나 해서 아래와 같이 이전에 사용했던 Request-Id 헤더도 추가해줬더니 정상적으로 응답이 온다.

curl -v -H "Authorization:auth_123" -H "Request-Id:12345" http://localhost:8080/hello

...
< HTTP/1.1 200
...
GET Hello!

하지만 작성된 Config 클래스에는 위의 두 필터를 등록하는 코드가 없다. 그럼에도 불구하고 영향을 미치고 있다.

@Configuration
public class ProjectConfig {
    private static final Logger log = LoggerFactory.getLogger(ProjectConfig.class);
    private AuthenticationProviderService authenticationProvider;
    @Autowired
    public ProjectConfig(@Lazy AuthenticationProviderService authenticationProvider) {

        this.authenticationProvider = authenticationProvider;
    }

    @Bean
    public PasswordEncoder passwordEncoder() {
        Map<String, PasswordEncoder> encoderMap = new HashMap<>();
        encoderMap.put("bcrypt", new BCryptPasswordEncoder());
        encoderMap.put("scrypt", SCryptPasswordEncoder.defaultsForSpringSecurity_v5_8());
        return new DelegatingPasswordEncoder("bcrypt", encoderMap);
    }

    @Bean
    SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        http
//                .authenticationProvider(authenticationProvider)
//                .formLogin(
//                        customizer -> customizer
//                                .defaultSuccessUrl("/hello", true))
//                .httpBasic(Customizer.withDefaults())
                .addFilterAfter(new CsrfTokenLogger(), CsrfFilter.class)
                .authorizeHttpRequests(
                        request -> request.anyRequest()
                                .permitAll()
                )
                .csrf(Customizer.withDefaults());

        return http.build();
    }
}

정확히 어떻게 돌아가는지는 잘 모르겠지만 @Component 어노테이션이 붙은 StaticKeyAuthenticationFilter가 빈으로 등록되면서 RequestValidationFilter 역시 영향을 받아 함께 등록된 것 같다.

@Component 어노테이션을 제거하면 정상적으로 응답에 GET Hello!가 잘 도착한다.

curl -v http://localhost:8080/hello

...
< HTTP/1.1 200
...
GET Hello!

필터 클래스에 @Component를 붙이는 것은 주의해야 할 것 같고, 필요없는 필터 클래스 역시 생성하지 않는 것이 좋을 것 같다.

스프링 시큐리티 인 액션] 5장_인증

greatwhite — Fri, 28 Jun 2024 14:51:41 +0900

인증 논리를 담당하는 부분은 AuthenticationProvider 이다. AuthenticationManager는 HTTP 요청을 수신하고 AuthenticationProvider에게 인증 책임을 위임한다. 이 단원에서는 인증 결과가 두 가지인 인증 프로세스를 살펴본다.

요청하는 엔티티가 인증되지 않는다

애플리케이션이 사용자를 인식하지 못해 권한 부여 프로세스에 위임하지 않고 요청을 거부한다. 일반적으로 이 경우 클라이언트에 HTTP 401 Unauthorized 응답이 반환된다.

요청하는 엔티티가 인증된다

요청자의 UserDetails 가 SecurityContext에 저장되어 애플리케이션이 이를 권한 부여에 이용할 수 있다.

AuthenticationProvider의 이해

어떠한 시나리오가 주어지더라도 구현할 수 있게 해주는 것이 프레임워크의 목적이다. 엔터프라이즈 애플리케이션에서는 사용자의 이름과 암호 기반의 기본 인증 구현이 적합하지 않을 수 있다. 또한 인증과 관련해서 여러 시나리오를 구현해야 할 수 있다.

스프링 시큐리티에서는 AuthenticationProvider 계약으로 모든 맞춤형 인증 논리를 정의할 수 있다.

인증 프로세스 중 요청 나타내기

AuthenticationProvider를 구현하기 위해서는 인증 이벤트 자체를 나타내는 방법을 이해해야 한다. Authentication 은 인증 프로세스의 필수 인터페이스이다. 이 인터페이스는 인증 요청의 이벤트를 나타내며 애플리케이션에 접근을 요청한 엔티티의 세부 정보를 담는다. 인증 요청 이벤트와 관한 정보는 인증 프로세스 도중 그리고 이후에 사용할 수 있다. 애플리케이션에 접근을 요청하는 사용자를 주체(Principal)이라고 한다. 스프링 시큐리티의 Authentication 인터페이스는 자바 시큐리티 API의 Principal인터페이스를 확장한다.

스프링 시큐리티의 Authentication 계약은 주체만 나타내는 것이 아니라 인증 프로세스 완료 여부, 권한의 컬렉션 같은 정보를 추가로 가진다. 이 계약은 자바 시큐리티의 Principal 계약을 extends 하여 설계되었다. 따라서, 다른 프레임워크나 애플리케이션 구현에서 호환성이 높다.

현재 이 계약에서 알아야 할 메서드는 다음과 같다.

isAuthenticated() - 인증 프로세스가 끝났으면 true를 아직 진행 중이면 false를 반환한다.
getCredentials() - 인증 프로세스에 이용된 암호나 비밀번호를 반환한다.
getAuthorities() - 인증된 요청에 허가된 권환의 컬렉션을 반환한다.

Custom AuthenticationProvider 구현

AuthenticationProvider의 기본 구현은 UserDetailsService에서 사용자를 찾고 PasswordEncoder에서 사용자의 암호를 검증한다.

AuthenticationProvider 책임은 Authentication과 강하게 결합되어 있다. 인증 로직을 정의하려면 authenticate 메서드를 구현해야 하는데 구현 방법을 아래 세 항목으로 간단하게 요약할 수 있다.

인증에 실패하면 AuthenticationException을 발생시킨다.
현재 AuthenticationProvider 구현에서 지원하지 않는 증명 방식이면 null을 반환한다. HTTP 필터 수준에서 분리된 여러 Authentication 형식을 사용할 가능성이 생긴다.
인증이 완료되었다면 authenticate 메서드의 결과물로 Authentication 인스턴스를 반환해야 한다. 이 인스턴스에 대해 isAuthenticated 메서드는 true를 반환해야 한다. 또한 인증이 완료되었으므로 비밀빈호와 같은 민감 정보는 제거하는 것이 좋다.

AuthenticationProvider의 두 번째 메서드는 supports(Class<?> authentication)다. 이 메서드는 현재 요청이 지원하는 인증 형식이면 true를 반환한다. 하지만 이 메서드에서 true를 반환했다고 하더라도 authenticate 메서드에서 null을 반환할 수 있는데 이는 인증 세부 정보를 기준으로 요청을 거부했기 때문이다.

AuthenticationManager 는 사용가능한 인증 공급자 중 하나에 인증을 위임한다. AuthenticationProvider는 주어진 인증 유형을 지원하지 않거나 객체 유형은 지원하지만 해당 특정 객체를 인증하는 방법을 모를 수 있다. 인증을 평가한 후 요청이 올바른지 판단할 수 있는 AuthenticationProvider가 AuthenticationManager에 응답한다.

@Component
public class CustomAuthenticationProvider implements AuthenticationProvider {

        // 생략된 코드

    @Override
    public boolean supports(Class<?> authenticationType) {
        return authenticationType.equals(UsernamePasswordAuthenticationToken.class);
    }
}

어떤 종류의 Authentication을 지원할지 정의해야 한다. 이는 authentication 메서드의 매개 변수에 어떤 형식이 전달되는지에 따라 달라진다. AuthenticationFilter에서 별다른 구성을 하지 않았다면 UsernamePasswordAuthenticationToken 클래스가 형식을 정의한다.

어떤 형식을 지원할지 결정했으므로 authenticate 메서드를 구현할 수 있다.

@Component
public class CustomAuthenticationProvider implements AuthenticationProvider {

    @Autowired
    private UserDetailsService userDetailsService;

    @Autowired
    private PasswordEncoder passwordEncoder;

    @Override
    public Authentication authenticate(Authentication authentication) throws AuthenticationException {
        String username = authentication.getName();
        String password = authentication.getCredentials().toString();

        UserDetails u = userDetailsService.loadUserByUsername(username);

        if (passwordEncoder.matches(password, u.getPassword())) {
            return new UsernamePasswordAuthenticationToken(
                    username,
                    password,
                    u.getAuthorities()
            );
        }
        throw new BadCredentialsException("Something went wrong!");
    }

    @Override
    public boolean supports(Class<?> authenticationType) {
        return authenticationType.equals(UsernamePasswordAuthenticationToken.class);
    }
}

UserDetails를 가져오기 위해 UserDetailsService 구현을 사용한다. 이 때 사용자를 찾지 못하거나 PasswordEncoder로 검증했을 때 비밀번호가 일치하지 않는다면 AuthenticationException을 발생시킨다. 그러면 인증 프로세스는 중단되고 인증 필터가 응답 상태를 401 Unauthorized를 설정한다. 인증이 성공된 경우 요청의 세부정보를 포함하는 Authentication을 인증됨으로 표시하고 반환한다.

이를 그림으로 나타내면 위와 같다.

이제 구현한 AuthenticationProvider를 연결하려면 프로젝트의 구성 클래스에서 추가해줘야 한다. 책에서는 deprecated된 WebSecurityConfigAdapter를 사용해 예시를 조금 수정했다.

@Configuration
public class ProjectConfig{
    @Bean
    public UserDetailsService userDetailsService(DataSource dataSource) {
        String usersByUsernameQuery =
                "select username, password, enabled from users where username = ?";
        String authByUserQuery =
                "select username, authority from authorities where username = ?";

        var userDetailsManager = new JdbcUserDetailsManager(dataSource);
        userDetailsManager.setUsersByUsernameQuery(usersByUsernameQuery);
        userDetailsManager.setAuthoritiesByUsernameQuery(authByUserQuery);
        return userDetailsManager;
    }

    @Bean
    public PasswordEncoder passwordEncoder() {
        return NoOpPasswordEncoder.getInstance();
    }

    @Bean
    public AuthenticationManager authenticationManager(AuthenticationProvider authenticationProvider) {
        return new ProviderManager(authenticationProvider);
    }
}

ProviderManager는 AuthenticationManager의 대표 구현체이다. AuthenticationProvider 리스트나 가변 인자를 전달하면 전달된 여러 AuthenticationProvider 를 가지는 ProviderManager가 생성된다.

앞에서 @Component어노테이션을 CustomAuthenticationProvider에 추가해줬기 때문에 스프링 컨텍스트가 이를 사용한다.

SecurityContext 이용

인증 프로세스가 끝난 이후에도 엔티티 세부정보가 필요하다. 사용자가 어떤 권한을 가지는지에 따라 할 수 있는 작업이 다르기 때문이다. 이 때문에 인증이 끝나도 요청이 유지되는 동안 Authentication 객체를 SecurityContext에 저장한다.

SecurityContext계약의 핵심 책임은 Authentication 을 저장하는 것이다. 그리고 스프링 시큐리티는 SecurityContextHolder 라는 관리자 역할 객체로 세 가지 전략을 통해 SpringSecurityContext를 관리한다.

MODE_THREADLOCAL

각 스레드가 SecurityContext에 각자의 세부정보를 저장할 수 있게 해준다. 요청 당 스레드 방식의 웹 애플리케이션에서는 각 요청이 개별 스레드를 가지므로 일반적인 접근이다.

MODE_INHERITABLETHREADLOCAL

MODE_THREADLOCAL과 비슷하지만 비동기 메서드의 경우 SecurityContext를 다음 스레드로 복사하도록 스프링 시큐리티에 지시한다. 이 방식으로 @Async 메서드를 실행하는 새 스레드가 보안 컨텍스트를 상속하게 할 수 있다.

MODE_GLOBAL

애플리케이션의 모든 스레드가 같은 SecurityContext인스턴스를 보게 한다.

위 세 가지 전략 외에 개발자가 스프링에 알려지지 않은 새 스레드를 정의하면 명시적으로 SecurityContext의 세부 정보를 새 스레드로 복사해야 한다. 스프링 시큐리티는 스프링 컨텍스트에 있지 않은 객체를 자동으로 관리할 수 없지만, 이를 위해 유용한 유틸리티 클래스를 제공한다.

SecurityContext 기본 전략 사용

MODE_THREADLOCAL은 스프링 시큐리티가 SecurityContext를 관리하는 기본 전략이다. ThreadLocal은 JDK에 있는 구현이며 이 구현은 각 스레드가 컬렉션에 저장된 데이터만 볼 수 있도록 보장한다. 각 요청은 자신의 SecurityContext에 접근하며, 다른 스레드의 ThreadLocal에 접근할 수 없다. 아래와 같이 T1’에 새 스레드가 생길 경우 기존 SecurityContext A의 세부 내용이 복사되지 않는다.

SecurityContext를 관리하는 기본 전략이므로 명시적으로 구성할 필요가 없다. 인증 프로세스가 끝난 이후 필요할 때마다 SecurityContextHolder.getContext() 메서드를 통해 SecurityContext를 요청만 하면 된다. 이후 SecurityContext에서 getAuthentication 메서드로 Authentication 을 얻올 수 있다.

기본 전략을 고수하는 것이 더 쉬우며 대부분은 이 전략으로 충분하다. MODE_THREADLOCAL은 각 스레드의 SecurityContext를 격리할 수 있게 해주고 SecurityContext를 더 자연스럽고 이해하기 쉽게 만들어준다.

비동기 호출을 위한 전략 이용

하지만 요청당 여러 스레드가 사용될 때는 상황이 복잡하다. 엔드포인트가 비동기가 되면 요청을 처리하는 스레드와 메서드를 실행하는 스레드가 다른 스레드가 된다.

@GetMapping("/bye")
@Async
public void goodbye() {
    SecurityContext context = SecurityContextHolder.getContext();
    String name = context.getAuthentication().getName();

    // 사용자 이름으로 작업
}

@Async 기능을 활성화하기 위해 @EnableAsync 어노테이션을 Config 클래스에 추가해줘야 한다.

@Configuration
@EnableAsync
public class ProjectConfig {
}

String username = context.getAuthentication.getName();

현재 상태로 코드를 실행해보면 인증에서 이름을 얻는 다음 행에서 NullPointerException이 발생한다.

이는 SecurityContext를 상속하지 않는 다른 스레드에서 실행되기 때문이다. 이를 MODE_INHERITABLETHREADLOCAL 전략으로 해결할 수 있다.

SecurityContextHolder클래스를 살펴보면 strategyname 필드가 있다. 이 필드는 spring.security.strategy 에서 값을 가져오는 것을 볼 수 있다.

또는 setStrategyName메서드로 설정해줄 수 있다.

이 전략을 사용하면 프레임워크는 요청의 원래 스레드에 있는 세부 정보를 비동기 메서드의 새로 생성된 스레드로 복사한다.

@Bean
public InitializingBean initializingBean() {
    return () -> SecurityContextHolder.setStrategyName(
            SecurityContextHolder.MODE_INHERITABLETHREADLOCAL);
}

ProjectConfig 클래스에 위 메서드를 추가하면 /bye 엔드포인트에 접근했을 때 Authentication 이 제대로 복사된다.

위 빈을 등록하지 않으면 아래와 같은 오류가 발생한다.

java.lang.NullPointerException: Cannot invoke "org.springframework.security.core.Authentication.getName()" because the return value of "org.springframework.security.core.context.SecurityContext.getAuthentication()" is null

빈을 등록하면 정상 출력된다.

위와 같이 시작 시 옵션을 줘서 실행할 수도 있다.

독립형 애플리케이션을 위한 전략 사용

SecurityContext가 애플리케이션의 모든 스레드에 공유되는 전략을 원한다면 MODE_GLOBAL을 이용하면 된다. 이 전략은 일반적인 웹 애플리케이션과 맞지 않기 때문에 웹 서버에서는 사용되지 않는다. 독립형 애플리케이션에는 공유하는 것이 좋은 전략일 수 있다.

@Bean
public InitializingBean initializingBean() {
        return () -> SecurityContextHolder.setStrategyName(
                SecurityContextHolder.MODE_GLOBAL);
}

하지만 이 전략에서는 애플리케이션의 모든 스레드가 SecurityContext 객체에 접근할 수 있으므로 개발자가 동시 접근을 해결해야 한다.

DelegatingSecurityContextRunnable로 SecurityContext 전달

새로 생성된 스레드의 경우 스프링 컨텍스트가 알고 있는 경우에는 MODE_INHERITABLETHREADLOCAL 전략을 통해 SecurityContext를 복사할 수 있었다. 그러나 프레임워크가 모르는 방법으로 코드가 새 스레드를 시작하면 여전히 빈틈이 생긴다. 이러한 스레드는 프레임워크가 관리해주지 않아 개발자가 관리해야 하므로 자체 관리 스레드라고 한다.

자체 관리 스레드는 개발자가 SecurityContext를 전파해야 한다. 한 가지 해결책은 별도의 스레드에서 실행하고 싶은 작업을 DelegatingSecurityContextRunnable 또는 DelegatingSecurityContextCallable<T>을 사용하는 것이다. 반환 값이 없다면 Runnable을, 있다면 Callable<T> 를 사용하면 된다.

두 클래스 모두 다른 Runnable 또는 Callable과 마찬가지로 비동기적으로 실행되는 작업을 나타내며, 작업을 실행하는 스레드를 위해 현재 SecurityContext를 복사시켜 준다.

@GetMapping("/ciao")
public String ciao() throws Exception {
    Callable<String> task = () -> { // Callable 작업 선언
        SecurityContext context = SecurityContextHolder.getContext();
        return context.getAuthentication().getName(); // 현재 Authentication 이름 반환
    };
    ExecutorService e = Executors.newCachedThreadPool();
    try {
        return "Ciao, " + e.submit(task).get() + "!";
    } finally {
        e.shutdown();
    }
}

위 상태로 실행하면 SecurityContext를 복사해주지 않았기 때문에 NPE가 발생한다. 따라서, DelegatingSecurityContextCallable로 감싸줘야 한다.

@GetMapping("/ciao")
public String ciao() throws Exception {
    Callable<String> task = () -> {
        SecurityContext context = SecurityContextHolder.getContext();
        return context.getAuthentication().getName();
    };
    ExecutorService e = Executors.newCachedThreadPool();
    try {
        var contextTask = new DelegatingSecurityContextCallable<>(task);
        return "Ciao, " + e.submit(contextTask).get() + "!";
    } finally {
        e.shutdown();
    }
}

위와 같이 바꿔주면 제대로 출력된다.

DelegatingSecurityContextExecutorService로 SecurityContext 전달

프레임워크에 알리지 않고 코드에서 시작한 스레드를 다룰 때는 SecurityContext 에서 다음 스레드로의 전파를 관리해야 한다. 위에서 살펴보았던 두 클래스는 모두 작업 단위에서 SecurityContext를 복사했다. 이번에는 스레드 풀에서 전파를 관리하는 법을 살펴보자.

작업을 데코레이트하는 대신 특정 유형의 Executor를 사용할 수 있다. 이번에는 DelegatingSecurityContextExecutorService가 ExecutorService를 감싼다.

@GetMapping("/hola")
public String hola() throws Exception {
    Callable<String> task = () -> {
        SecurityContext context = SecurityContextHolder.getContext();
        return context.getAuthentication().getName();
    };

    ExecutorService e = Executors.newCachedThreadPool();
    e = new DelegatingSecurityContextExecutorService(e);

    try{
        return "Hola, " + e.submit(task).get() + "!";
    } finally {
        e.shutdown();
    }
}

클래스	설명
DelegatingSecurityContextExecutor	Executor 인터페이스를 구현하며 Executor 객체를 장식하면 SecurityContext를 해당 풀에 의해 생성된 스레드로 전달하는 기능을 제공한다.
DelegatingSecurityContextExecutorService	ExecutorService 인터페이스를 구현하며 ExecutorService 객체를 장식하면 SecurityContext 를 해당 풀에 의해 생성된 스레드로 전달하는 기능을 제공한다.
DelegatingSecurityContextScheduledExecutorService	ScheduledExecutorService 인터페이스를 구현하며 ScheduledExecutorService 객체를 장식하면 SecurityContext를 해당 풀에 의해 생성된 스레드로 전달하는 기능을 제공한다.
DelegatingSecurityContextRunnable	Runnable 인터페이스를 구현하고 다른 스레드에 의해 실행되며 응답을 반환하지 않는 작업을 나타낸다. Runnable 기능에 더해 새 스레드에서 사용하기 위한 SecurityContext 를 복사한다.
DelegatingSecurityContextcallable	Callable인터페이스를 구현하고 다른 스레드에 의해 실행되며 최종적으로 응답을 반환하는 작업을 나타낸다. Callable 기능에 더해 새 스레드에서 사용하기 위한 SecurityContext 를 복사한다.

HTTP Basic 인증과 form 기반 로그인 인증 이해하기

지금까지는 인증 방식으로 HTTP Basic을 이용했다. 이는 실제 애플리케이션에는 적합하지 않을 수 있다.

HTTP Basic 이용 및 구성

이론적인 시나리오에서는 HTTP Basic으로 충분하지만 더 복잡한 애플리케이션에서는 추가 구성이 필요할 수 있다.

HTTP Basic의 명시적인 설정은 아래와 같이 할 수 있다.

@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
    http.httpBasic(Customizer.withDefaults());
    return http.build();
}

Customizer<T> 의 함수형 인터페이스를 통해 반환값을 지정하고 HttpSecurity 의 httpBasic() 메서드를 호출할 수도 있다. 아래와 같이 영역(realm)을 특정 인증 방식을 이용하는 보호 공간으로 생각할 수 있다.

@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
    http.authorizeHttpRequests((authz) -> authz
                    .anyRequest().authenticated()
            )
            .httpBasic(c -> c.realmName("OTHER"));
    return http.build();
}

여기서 이용된 람다식은 Customizer<HttpBasicConfigurer<HttpSecurity>> 형식의 객체인데, HttpBasicConfigurer<HttpSecurity> 형식의 매개 변수로 realmName()을 호출해 영역 이름을 변경할 수 있게 해준다. cURL에 -v 플래그를 지정하면 반환된 자세한 HTTP 응답을 볼 수 있는데 영역 이름이 OTHER로 변경된 걸 확인할 수 있다. 하지만 WWW-Authenticate 헤더는 응답에서 HTTP 401일 때만 있다.

또한 Customizer로 인증이 실패했을 때의 응답을 맞춤 구성할 수 있다. 인증이 실패했을 때 클라이언트가 응답에서 특정한 항목을 기대하는 경우 이를 위해 하나 이상의 헤더를 추가하거나 제거해야할 수 있다. 또는 애플리케이션이 민감한 데이터를 클라이언트에 노출하지 않도록 응답 본문을 필터링하는 로직을 작성할 수 있다.

인증이 실패했을 때 응답을 맞춤 구성하려면 AuthenticationEntryPoint를 구현하면 된다.

AuthenticatioEntryPoint의 commence 메서드는 HttpServletRequest, HttpServletResponse, 그리고 인증 실패를 일으킨 AuthenticationException을 받는다.

AuthenticationEntryPoint 인터페이스는 스프링 시큐리티 아키텍처에서 ExceptionTranslationManager 라는 구성 요소에서 직접 사용되며 이 구성 요소는 필터 체인으로 던져진 모든 AccessDeniedException 및 AuthenticationException 을 처리한다.

public class CustomEntryPoint implements AuthenticationEntryPoint {
    @Override
    public void commence(HttpServletRequest request, HttpServletResponse response,
                         AuthenticationException authException) throws IOException, ServletException {
        response.addHeader("message", "something went wrong!");
        response.sendError(HttpStatus.UNAUTHORIZED.value());
    }
}

이제 설정 클래스에서 HTTP Basic 인증을 위해 직접 만든 CustomEntryPoint를 등록할 수 있다.

@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
    http.authorizeHttpRequests((authz) -> authz
                    .anyRequest().authenticated()
            )
            .httpBasic(c -> {
                c.realmName("OTHER");
                **c.authenticationEntryPoint(new CustomEntryPoint());**
            });
    return http.build();
}

양식 기반 로그인으로 인증 구현

작은 웹 기반 애플리케이션에서는 스프링 시큐리티가 제공하는 양식 기반 인증 방식을 사용할 수 있다.

@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
    http.authorizeHttpRequests((authz) -> authz
                    .anyRequest().authenticated()
            )
            .formLogin(Customizer.withDefaults());
    return http.build();
}

이를 위해서는 HttpBasic 대신 formLogin을 추가하면 된다. 위와 같이 구현하면 아직 다른 정의된 페이지가 없으므로 로그인한 후에는 기본 오류 페이지로 리다이렉션된다.

기존 방식과의 차이는 JSON 형식이 아닌 HTML을 반환하는 엔드포인트를 원한다는 점이다. 이를 위해 resources/static 경로에 home.html을 생성하고 아래와 같이 Controller를 하나 더 정의해줬다.

@Controller
Public class HomeController {

        @GetMapping("/home")
        public String home() {
                return "home.html";
        }
}

로그인하지 않고 아무 경로에 접근하려고 하면 로그인 페이지로 리다이렉션되고 이 때 로그인을 하면 원래 가려던 페이지로 리다이렉션된다. formLogin() 메서드는 FormLoginConfigurer<HttpSecurity> 형식의 객체를 반환하며 이를 이용해 맞춤 구성을 할 수 있다.

@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
    http
            .formLogin(configurer -> configurer.defaultSuccessUrl("/home", true))
            .authorizeHttpRequests((authz) -> authz
                    .anyRequest().authenticated()
            );
    return http.build();
}

defaultSuccessUrl() 메서드로 로그인이 성공하면 보낼 기본 페이지를 설정할 수 있다.

더 세부적인 맞춤 구성이 필요하면 AuthenticationSuccessHandler및 AuthenticationFailureHandler 객체를 이용할 수 있다. 이러한 인터페이스를 이용하면 인증을 위해 실행되는 논리를 적용할 객체를 구현할 수 있다.

AuthentciationSuccessHandler의 onAuthenticationSuccess() 메서드는 매개변수로 서블릿 요청과 응답 그리고 Authentication 객체를 받는다. 아래와 같이 권한에 따라 다른 리다이렉션을 수행하도록 할 수 있다.

@Component
public class CustomAuthenticationSuccessHandler implements AuthenticationSuccessHandler {
    @Override
    public void onAuthenticationSuccess(HttpServletRequest request, HttpServletResponse response,
                                        Authentication authentication) throws IOException, ServletException {
        var authorities = authentication.getAuthorities();
        var auth = authorities.stream()
                .filter(a -> a.getAuthority().equals("read"))
                .findFirst(); // read 권한이 없으면 빈 Optional 객체 반환

        if (auth.isPresent()) {
            response.sendRedirect("/home");
            return;
        }
        response.sendRedirect("/error");
    }
}

실제 시나리오에서는 인증에 실패하면 클라이언트에 특정 형식의 응답이 필요한 상황이 있다. 인증에 실패했을 때 실행할 로직을 맞춤 구성하려면 AuthenticationFailureHandler 를 구현하면 된다. 이 클래스 역시 서블릿 요청과 응답을 갖지만 AuthenticationException객체를 받는다.

@Component
public class CustomAuthenticationFailureHandler implements AuthenticationFailureHandler {

    @Override
    public void onAuthenticationFailure(HttpServletRequest request, HttpServletResponse response,
                                        AuthenticationException exception) throws IOException, ServletException {
        response.setHeader("failed", LocalDateTime.now().toString());
    }
}

이 후 두 객체를 사용하려면 successHandler()와 failureHandler()로 지정해줘야 한다.

@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
    http
            .formLogin(configurer -> {
                configurer.defaultSuccessUrl("/home", true);
                configurer.successHandler(authenticationSuccessHandler);
                configurer.failureHandler(authenticationFailureHandler);
            })
            .authorizeHttpRequests((authz) -> authz
                    .anyRequest().authenticated()
            );
    return http.build();
}

이제 올바른 사용자 이름과 암호를 이용해서 HTTP Basic 방식으로 /home에 접근하려고 해도 HTTP 302를 반환한다. 여기에 HTTP Basic을 추가하면 양식 기반과 HTTP Basic 기반 모두 정상 작동하게 할 수 있다.

@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
    http
            .formLogin(configurer -> {
                configurer.defaultSuccessUrl("/home", true);
                configurer.successHandler(authenticationSuccessHandler);
                configurer.failureHandler(authenticationFailureHandler);
            })
            .authorizeHttpRequests((authz) -> authz
                    .anyRequest().authenticated()
            ).httpBasic(Customizer.withDefault());
    return http.build();
}

스프링 시큐리티 인 액션] 4장_암호처리

greatwhite — Fri, 21 Jun 2024 14:43:59 +0900

PasswordEncoder 인터페이스 이해

일반적으로 시스템은 암호를 그대로 저장하지 않고 해시를 사용해 저장한다. PasswordEncoder는 암호를 인코딩하고 인증 프로세스에서 암호가 유효한지 확인한다.

upgradeEncoding 메서드는 false를 반환하도록 기본 구현이 되어 있는데 이를 true 를 반환하도록 재정의하면 인코딩된 암호를 보안 향상을 위해 다시 인코딩한다. 상황에 따라 재정의해서 사용할 수 있다.

encode 와 matches 메서드는 기능적으로 밀접한 관계가 있어 이 둘을 재정의하려면 기능 면에서 항상 일치해야 한다. PasswordEncoder 로 인코딩된 암호가 주어진 암호와 같은지 PasswordEncoder로 확인할 수 있어야 한다.

제공된 구현 선택

스프링 시큐리티에서 이미 몇 가지 유용한 구현을 제공한다.

Pbkdf2PasswordEncoder - PBKDF2를 사용한다.
BcryptPasswordEncoder - bcrypt 강력 해싱 함수로 인코딩한다.
ScryptPasswordEncoder - scrypt 해싱 함수로 인코딩한다.

PasswordEncoder p = new Pbkdf2PasswordEncoder();
PasswordEncoder p = new Pbkdf2PasswordEncoder("secret");
PasswordEncoder p = new Pbkdf2PasswordEncoder("secret", 185000, 256);

PBKDF2는 반복 횟수만큼 HMAC을 돌리는 아주 단순하고 느린 해싱 함수이다. 마지막 호출의 세 매개 변수는 각각 인코딩 프로세스에 이용되는 키 값, 암호 인코딩의 반복 횟수, 해시의 크기이다. 해시의 크기가 늘어날 수록 암호가 강력해지지만 리소스 역시 함께 늘어나므로 절충해야 한다.

또 다른 훌륭한 옵션은 bcrypt 강력 해싱 함수로 암호를 인코딩하는 BcryptPasswordEncoder가 있다. 매개변수가 없는 생성자로 BcryptPasswordEncoder를 생성해도 되지만 인코딩 프로세스에 이용되는 로그 라운드를 나타내는 강도 계수를 지정할 수도 있다. 또한, 인코딩에 이용되는 SecureRandom 인스턴스를 변경할 수도 있다.

PasswordEncoder p = new BcryptPasswordEncoder();
PasswordEncoder p = new BcryptPasswordEncoder(4);

SecureRandom s = SecureRandom.getInstanceString();
PasswordEncoder p = new BcryptPasswordEncoder(4, s);

지정하는 로그 라운드 값은 해싱 작업에 이용하는 반복 횟수에 영향을 준다. 반복 횟수는 2로그 라운드로 계산된다. 반복 횟수를 계산하기 위한 로그 라운드 값은 4 ~ 31 사이여야 한다.

DelegatingPasswordEncoder를 이용한 여러 인코딩 전략

인증 흐름에 암호 일치를 위해 다양한 구현을 적용해야 할 때가 있다. DelegatingPasswordEncoder는 자체 구현은 없고 PasswordEncoder 인터페이스를 구현하는 다른 객체에 위임한다. 운영 단계에서 특정 애플리케이션 버전부터 인코딩 알고리즘이 변경된 경우에 DelegatingPasswordEncoder 객체를 사용할 수 있다.

DelegatingPasswordEncoder를 사용해 해싱하면 해시에 해싱 알고리즘이 {사용된 알고리즘}형태로 접두사가 추가된다. matches 메서드를 호출하면 이 접두사를 기준으로 적절한 해싱 알고리즘을 선택해 주어진 비밀번호와 일치하는지 확인한다.

이를 직접 구현하면 아래와 같다.

@Bean
public PasswordEncoder passwordEncoder() {
        Map<String, PasswordEncoder> encoders = new HashMap<>();

        encoders.put("noop", NoOpPasswordEncoder.getInstance());
        encoders.put("bcrypt", new BCryptPasswordEncoder());
        encoders.put("scrypt", new SCryptPasswordEncoder());

        return new DelegatingPasswordEncoder("bcrypt", encoders());
}

접두사가 없으면 기본 인코더를 이용하고 DelegatingPasswordEncoder를 생성할 때 첫 번째 매개변수로 지정한다. 위 DelegatingPasswordEncoder는 기본적으로 BcryptPasswordEncoder구현에 위임한다.

또는 이미 구현된 PasswordEncoderFactories.creatDelegatingPasswordEncoder를 호출할 수도 있다.

설명	설명
UserDetails	스프링 시큐리티가 관리하는 사용자를 나타낸다.
GrantedAuthority	애플리케이션의 목적 내에서 사용자에게 허용되는 작업을 정의한다(예: 읽기, 쓰기, 삭제 등).
UserDetailsService	사용자의 이름으로 사용자 세부 정보를 검색하는 객체를 나타낸다.
UserDetailsManager	UserDetailsService를 확장한 인터페이스이다. 사용자 컬렉션이나 특정 사용자를 변경할 수 있다.
PasswordEncoder	암호를 암호화 또는 해시하는 방법과 주어진 인코딩된 문자열을 일반 텍스트 암호와 비교하는 방법을 지정한다.

스프링 시큐리티 암호화 모듈에 관한 추가 정보

이전까지 SSCM(Spring Security Crypto Module)을 살펴봤다. 암호화 및 복호화 함수와 키 생성 기능은 자바 언어에서 기본 제공하지 않기 때문에 이러한 기능에 보다 쉽게 접근하기 위한 종속성을 추가할 때 제약이 있다. PasswordEncoder도 SSCM의 일부이다.

SSCM의 두 가지 필수 기능

KeyGenerator - 해싱 및 암호화 알고리즘을 위한 키를 생성하는 객체
Encryptor - 데이터를 암호화 및 복호화하는 객체

Key Generator 이용

KeyGenerator는 특정한 종류의 키를 생성하는 객체로서 일반적으로 암호화나 해싱 알고리즘에 필요하다. 스프링 시큐리티의 KeyGenerator 구현은 아주 훌륭한 유틸리티 툴이다.

BytesKeyGenerator 와 StringKeyGenerator는 KeyGenerator의 두 가지 주요 유형을 나타내는 인터페이스이며 팩토리 클래스 KeyGenerators로 직접 만들 수 있다.

public interface StringKeyGenerator {
        String generateKey();
}

StringKeyGenerator 를 통해 문자열 키를 얻을 수 있고 이 키는 해싱 또는 암호화 알고리즘의 솔트 값으로 이용된다.

StringKeyGenerator keyGenerator = KeyGenerators.string();
String salt = keyGenerator.generateKey();

위 코드에서 KeyGenerators.string() 메서드는 8바이트 키를 생성하고 keyGenerator.generateKey() 메서드는 생성된 키를 16진수 문자열로 인코딩하여 문자열로 반환한다.

BytesKeyGenerator

public interface BytesKeyGenerator {
        int getKeyLength();
        byte[] generateKey();
}

해당 인터페이스에는 키 길이를 바이트 수로 반환하는 getKeyLength() 메서드가 있다.

BytesKeyGenerator keyGenerator = KeyGenerators.secureRandom();
byte[] key = keyGenerator.generateKey();
int keyLength = keyGenerator.getKeyLength();

KeyGenerators.secureRandom()은 내부적으로 SecureRandomBytesKeyGenerator 인스턴스를 생성하는데 8바이트 길이의 키를 생성한다. 여기에 16바이트 키를 생성하고 싶다면 인자로 16을 넣어주면 된다.

이렇게 생성한 BytesKeyGenerator는 generateKey() 메서드가 호출될 때마다 고유한 키를 생성한다. 같은 KeyGenerator를 호출했을 때 같은 키값을 반환하는 구현이 필요하다면 KeyGenerators.shared(int length) 메서드로 BytesKeyGenerator를 생성할 수 있다.

// given
BytesKeyGenerator shared = KeyGenerators.shared(8);

//when
byte[] generatedKey1 = shared.generateKey();
byte[] generatedKey2 = shared.generateKey();

// then
assertEquals(generatedKey1, generatedKey2); // true

Encryptor 는 암호화 알고리즘을 구현하는 객체다. 암호화와 복호화는 보안을 위한 공통적인 기능이므로 애플리케이션에 이러한 기능이 필요할 가능성이 크다.

시스템의 구성 요소 간에 데이터를 전송하거나 데이터를 저장할 때 암호화가 필요할 때가 많다. Encryptor는 암호화와 복호화 작업을 지원하며 SSCM에는 이를 위해 BytesEncryptor와 TextEncryptor라는 두 유형의 암호기가 정의돼 있다.

두 Encryptor 는 다른 형식으로 데이터를 처리하며 BytesEncryptor가 더 범용적이다.

BytesEncryptor

Encryptor를 사용하는 옵션에 관해 알아보자. 팩토리 클래스 Encryptors는 여러 가능성을 제공하며, BytesEncryptor의 경우 다음과 같이 Encryptors.standard() 또는 Encryptors.stronger() 메서드를 이용할 수 있다.

String salt = KeyGenerators.string().generateKey();
String password = "secret";
String valueToEncrypt = "HELLO";

BytesEncryptor e = Encryptors.standard(password, salt);
byte[] encrypted = e.encrypt(valueToEncrypt.getBytes());
byte[] decrypted = e.decrypt(encrypted);

내부적으로 256바이트 AES암호화를 이용해 입력을 암호화한다. 더 강력한 바이트 암호화 Ecryptor 인스턴스는 Encryptors.stronger() 메서드를 호출하면 된다. 차이는 AES 암호화의 작업 모드로 GCM(갈루아/카운터 모드)을 이용한다. 표준 모드는 이보다 약한 방식인 CBC(암호 블록 체인)을 이용한다.

TextEncryptor

세 가지 주요 형식이 있고 Encryptors.text(), Encryptors.delux(), ~~Encryptors.queryableText()~~ 메서드를 호출해 이러한 형식을 생성할 수 있다.

값을 암호화하지 않는 더미 TextEncryptor를 반환하는 메서드도 있다. Encryptors.noOpText() 메서드를 통해 애플리케이션 성능만을 테스트하거나 데모 예제에서 사용할 수 있다.

String valueToEncrypt = "HELLO";
TextEncryptor e = Encryptors.noOpText();
// valueToEncrypt == encrypted
String encrypted = e.encrypt(valueToEncrypt);

위에서 볼 수 있듯이 Encryptors.delux() 는 Encryptors.stronger()를, Encryptors.text()는 Encryptors.standard()를 사용한다.

delux와 text 모두 같은 입력으로 encrypt 메서드를 반복 호출해도 다른 출력이 반환된다. 암호화 프로세스에 임의의 초기화 벡터가 생성되기 때문이다.

스프링 시큐리티 인 액션] 3장_사용자 관리

greatwhite — Wed, 19 Jun 2024 16:39:49 +0900

먼저 요청이 들어오면 필터가 요청을 가로채고 인증 책임이 AuthenticationManager로 위임된다. 인증 논리 구현하는 AuthenticationProvider를 이용하는데 이 때 UserDetailsService에서 사용자를 찾고 PasswordEncoder 로 암호를 검증한다. 모든 인증이 끝나면 SecurityContext에 UserDetails가 저장된다.

사용자 관리는 UserDetailsManager와 UserDetailsService를 사용한다. UserDetailsService 는 사용자 이름으로 사용자를 찾는 역할만 하고 UserDetailsManager 는 사용자의 삭제, 추가, 수정 작업을 수행한다.

사용자는 애플리케이션 내에서 수행할 수 있는 작업을 나타내는 이용 권리의 집합을 가진다. 이를 권한이라고 한다.

사용자 정의하기

사용자를 나타내는 것은 인증 구현의 첫 번째 단계이다. 스프링 시큐리티에서 사용자 정의는 UserDetails 계약을 준수해야 한다.

UserDetails의 메서드는 두 부분으로 나뉜다. 인증과정에서 사용되는 PgtaPssword(), getUsername() 과 리소스에 접근할 수 있도록 권한을 부여하는 나머지 다섯 메서드로 나눌 수 있다.

권한 정의

사용자가 수행할 수 있는 작업을 권한이라고 한다. 애플리케이션 마다 사용자가 가진 권한이 다를 수 있다. 스프링 시큐리티에서는 GrantedAuthority 인터페이스로 권한을 나타낸다. 사용자는 여러 권한을 가질 수 있고 일반적으로 하나 이상의 권한을 가진다.

권한을 구현하기 위해서는 람다식을 사용하거나 SimpleGrantedAuthority 클래스를 이용해 인스턴스를 만드는 것도 가능하다. 구현 시에는 이름을 반환하게만 구현하면 된다.

사용자 책임 분리

애플리케이션에서 사용자는 여러 책임을 가질 수 있다. 데이터베이스에 저장되는 유저 엔티티 책임과 인증에 사용되는 UserDetails 책임을 가질 수 있다. 그러나 모든 책임을 한 클래스에 넣는 것은 바람직하지 않다.

두 가지 책임을 분리해서 User 클래스는 JPA 엔티티 책임만을 가지고 이를 래핑해 인증 관련 책임을 처리하는 클래스를 만들 수 있다.

@Entity
public class User {
        @Id
        private Long id;
        private String username;
        private String password;
        private String authority;

        // getters & setters
}

public class SecurityUser implements UserDetails {
        private final User user;

        public SecurityUser(User user) {
                this.user = user;
        }

        @Override
        public String getUsername() {
                return user.getUsername();
        }

        @Override
        public String getPassword() {
                return user.getPassword();
        }

        @Override
        public Collection<? extends GrantedAuthority> getAuthorities() {
                 return List.of(() -> user.getAuthority());
        }

        ....
}

스프링 시큐리티 사용자 관리

이제 앞서 만든 사용자를 UserDetailsService를 구현해 관리하는 방법을 지정해줘야 한다. 여기에 더 많은 기능을 사용하려면 UserDetailsManager를 구현하면 된다.

UserDetailsService는 loadUserByUsername() 한 개의 메서드만을 가진다.

인증 구현은 loadUserByUsername() 메서드를 호출해 주어진 이름과 일치하는 UserDetails를 얻는다. 이 때 주어진 이름이 없으면 UsernameNotFoundException이 발생한다.

UserDetailsService 구현

스프링 시큐리티에서 필요한 것은 어떤 방식으로든 사용자 이름으로 사용자를 조회하는 기능이다.

public class InMemoryUserDetailsService implements UserDetailsService {
    private final List<UserDetails> users;

    public InMemoryUserDetailsService(List<UserDetails> users) {
        this.users = users;
    }

    @Override
    public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException {
        return users.stream()
                .filter(
                        u -> u.getUsername().equals(username)
                ).findFirst()
                .orElseThrow(() -> new UsernameNotFoundException("User not found"));
    }
}

메모리 상으로 찾을 때는 위와 같이 구현할 수 있다.

UserDetailsManager 구현

스프링 시큐리티에서 제공하는 serDetailsManager 인터페이스는 UserDetailsService 인터페이스를 extends한다.

구현체로 InMemoryUserDetailsManager와 JdbcUserDetailsManager 를 제공한다. JdbcUserDetailsManager는 SQL 데이터베이스에 저장된 사용자를 관리하며 JDBC를 통해 데이터베이스에 직접 연결한다.

위에서 살펴봤던 그림과 조금 달라졌다. UserDetails 얻는 과정에서 JdbcUserDetailsManager 가 데이터베이스에서 사용자 이름으로 조회하는 부분이 추가되었다.

직접 Jdbc를 설정해줘야 하므로 의존성을 추가해줘야 한다.

dependencies {
    runtimeOnly 'com.h2database:h2'
    implementation 'org.springframework.boot:spring-boot-starter-jdbc'
    ...
}

사용할 데이터베이스에 따라 다른 드라이버를 설치해주면 되는데 h2가 더 간편하기 때문에 h2Driver를 추가해줬다.

그리고 이제는 application.yml에 dataSource를 설정해줘야 한다.

spring:
    datasource:
        driver-class-name: org.h2.Driver
        url: '<사용할 url>'
        username: 'sa'
        password: 
    sql:
        init:
            mode: always

여기서 spring.datasource.initialization-mode 를 always로 두려고 했는데 deprecated되었다고 한다. 대신 spring.sql.init.mode 로 바뀌었다.

또한 프로젝트에 사용될 UserDetailsService를 빈으로 등록해줘야 한다.

@Configuration
public class ProjectConfig {
        @Bean
        public UserDetailsService userDetailsService(DataSource dataSource) {
                return new JdbcUserDetailsManager(dataSource);
        }

        @Bean
        public PasswordEncoder passwordEncoder() { 
                return NoOpsPasswordEncoder.getInstance();
        }
}

또는 JdbcUserDetailsService에 이용되는 쿼리도 구성할 수 있다.

@Bean
public UserDetailsService userDetailsService() {
        String usersByUsernameQuery =
            "select username, password, enabled from users where username = ?";
    String authByUserQuery =
            "select username, authority from authority where username = ?";

    var userDetailsManager = new JdbcUserDetailsManager(dataSource);
    userDetailsManager.setUsersByUsernameQuery(usersByUsernameQuery);
    userDetailsManager.setAuthoritiesByUsernameQuery(authByUserQuery);
    return userDetailsManager;
}