제가 공부한 내용을 정리하는 블로그입니다. 아직 많이 부족하고 배울게 너무나도 많습니다. 틀린내용이 있으면 언제나 가감없이 말씀해주시면 감사하겠습니다😁
해당 포스팅은 Github Action 사용법 정리입니다.
서론
GitHub Actions는 소프트웨어 워크플로우를 자동화하는 도구입니다. 이를 통해 코드를 빌드하고, 테스트하고, 배포하는 과정을 간소화할 수 있습니다. 특히 GitHub Actions는 YAML 파일을 기반으로 정의되며, 다양한 이벤트(예: push, pull request, cron 등)에 따라 실행됩니다.
이번 포스팅에서는 GitHub Actions의 기본 개념과 함께, API를 기능별로 자동화하거나 Python 프로젝트에서 유용하게 사용할 수 있는 예제를 소개합니다.
Github Actions 기본개념
GitHub Actions를 이해하기 위해 알아야 할 주요 개념은 다음과 같습니다
Workflow
자동화된 프로세스의 가장 상위 개념으로, 여러 Job으로 구성됩니다.
YAML 파일로 정의되며, .github/workflows 폴더에 저장됩니다.
Event
Workflow를 실행하는 특정 조건이나 규칙입니다. 예: 브랜치로의 push, pull_request, schedule(cron) 등.
Job
특정 작업 단위를 정의하며, 여러 Step으로 구성됩니다.
독립적으로 실행되거나 다른 Job과 병렬 실행이 가능합니다.
Step
각 작업(Job)을 구성하는 단위로, 커맨드 실행 또는 액션 사용이 가능합니다.
Action
Workflow의 재사용 가능한 가장 작은 구성 요소입니다. 예: actions/checkout@v2를 사용하여 리포지토리를 체크아웃.
Workflow 정의 방법
GitHub Actions의 Workflow는 .github/workflows 디렉토리에 .yml 파일로 작성됩니다. 아래는 간단한 Workflow 예제입니다.
pull_request: 특정 브랜치로 PR(Pull Request)이 생성되거나 업데이트될 때 실행.
schedule: 특정 시간에 반복적으로 실행(Cron 표현식 사용).
여러 이벤트를 정의할 수 있으며, 배열로 작성 가능합니다.
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Run a one-line script
run: echo Hello, world!
- name: Run a multi-line script
run: |
echo Add other actions to build,
echo test, and deploy your project.
jobs Workflow는 여러 Job으로 구성되며, 각 Job은 독립적으로 실행됩니다.
병렬 실행: 기본적으로 여러 Job은 병렬로 실행됩니다.
build라는 job을 생성하고, 그 아래에 2개의 step이 존재하는 구조
runs-on은 어떤 OS에서 실행될지 지정
name: Job의 이름을 지정.
runs-on: Job이 실행될 운영 체제(OS) 환경을 지정
env: 환경변수 등록Job의 주요 요소:
steps의 uses는 어떤 액션을 사용할지 지정함. 이미 만들어진 액션을 사용할 때 지정
기본 Workflow 예제
name: CI workflow
on:
push:
branches:
- dev
pull_request:
branches:
- dev
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout Code
uses: actions/checkout@v3
- name: Set up JDK 17
uses: actions/setup-java@v3
with:
distribution: 'temurin'
java-version: '17'
- name: Grant execute permission for gradlew
run: chmod +x ./gradlew
- name: Build with Gradle
run: ./gradlew clean build --info
- name: Upload Artifact
uses: actions/upload-artifact@v3
with:
name: spring-app
path: build/libs/*.jar
deploy:
needs: build
runs-on: ubuntu-latest
steps:
- name: Download Artifact
uses: actions/download-artifact@v3
with:
name: spring-app
- name: Deploy JAR to AWS
uses: appleboy/scp-action@v0.1.4
with:
host: ${{ secrets.AWS_SERVER_IP }}
username: ${{ secrets.AWS_USERNAME }}
key: ${{ secrets.SSH_PRIVATE_KEY }}
source: "*.jar"
target: "~/proj"
- name: Restart Application on AWS
uses: appleboy/ssh-action@v0.1.10
with:
host: ${{ secrets.AWS_SERVER_IP }}
username: ${{ secrets.AWS_USERNAME }}
key: ${{ secrets.SSH_PRIVATE_KEY }}
script: |
# Define variables
DEPLOY_DIR=~/proj
JAR_FILE=server-0.0.1-SNAPSHOT.jar
# Kill process on port 8080
echo "Stopping existing server..."
PID=$(sudo lsof -t -i:8080)
if [ -n "$PID" ]; then
sudo kill -9 $PID
fi
# Navigate to deployment directory
cd $DEPLOY_DIR || exit
# Start the new server
echo "Starting new server..."
nohup java -jar $JAR_FILE > app.log 2>&1 &
echo "Server restarted. Logs can be found in $DEPLOY_DIR/app.log"
YAML 파일 설명
해당 yaml은 dev 브랜치에 이벤트가 발생할 때마다 AWS 서버에 실행 중인 서버를 껏다가 업데이트 된 것으로 실행하는 workflow입니다.
build Job:
GitHub Actions에서 코드 체크아웃, JDK 설치, 빌드, 그리고 생성된 JAR 파일을 아티팩트로 업로드합니다.
deploy Job:
빌드된 JAR 파일을 다운로드하여 AWS 서버로 전송한 후, 애플리케이션을 재시작합니다.
기존 서버 프로세스를 종료하고 새 JAR 파일로 서버를 실행합니다.
분석
이벤트 트리거
on:
push 또는 pull_request 이벤트가 dev 브랜치에서 발생하면 Workflow가 실행됩니다.
제가 공부한 내용을 정리하는 블로그입니다. 아직 많이 부족하고 배울게 너무나도 많습니다. 틀린내용이 있으면 언제나 가감없이 말씀해주시면 감사하겠습니다😁
스프링 정리를 위한 포스팅입니다. 해당 포스팅은 @Slf4j 정리입니다.
로그가 뭐야?
로그(Log)는 애플리케이션이 실행되면서 발생하는 이벤트, 오류, 상태 정보 등을 기록하는 중요한 데이터입니다. 프로그램의 실행 흐름을 추적하고, 문제 발생 시 원인을 분석하는 데 필수적인 요소입니다.
로그가 중요한 이유
디버깅 & 문제 해결
애플리케이션에서 오류가 발생했을 때, 로그를 통해 원인을 분석하고 해결할 수 있습니다.
예를 들어, 사용자가 API 요청을 보냈을 때 응답이 늦거나 실패하는 경우 로그를 확인하면 어느 단계에서 문제가 발생했는지 파악할 수 있습니다.
운영 모니터링 & 시스템 분석
운영 중인 서비스의 성능을 추적하고, 장애 발생 가능성을 미리 감지할 수 있습니다.
로그 데이터는 시스템의 상태를 분석하고 최적화하는 데 중요한 역할을 합니다.
보안 & 감사(Audit Logging)
사용자 활동 기록(로그인, 결제, 데이터 변경 등)을 남겨 보안 감사(Audit) 및 문제 발생 시 추적할 수 있습니다.
보안 로그는 악의적인 접근을 감지하고, 사이버 공격을 방어하는 데 사용됩니다.
로그를 남기는 방법
Java에서는 System.out.println()을 사용하여 로그를 출력할 수 있지만, 이는 성능 저하 및 유지보수 어려움 등의 단점이 있습니다.
대신, Slf4j와 같은 로깅 프레임워크를 활용하면 효율적이고 확장성 있는 로깅 시스템을 구축할 수 있습니다.
Slf4j란?
Slf4j(Simple Logging Facade for Java)는 Java 애플리케이션에서 로깅을 위한 추상화 인터페이스입니다. 쉽게 말해, 특정 로깅 프레임워크(Logback, Log4j 등)에 종속되지 않고 Slf4j를 통해 원하는 로깅 시스템을 선택하여 사용할 수 있도록 도와주는 역할을 합니다.
💡 Slf4j는 로깅을 위한 "추상화 인터페이스"이며, 실제 로깅은 Logback, Log4j와 같은 구현체가 수행합니다.
Slf4j와 Logback 관계
Slf4j
로깅 추상화 인터페이스 (로깅 방식만 제공, 직접 로그 출력 X)
Logback
Slf4j의 기본 로깅 구현체 (Spring Boot 기본 제공)
Log4j
별도의 로깅 프레임워크 (Slf4j와 함께 사용할 수 있음)
Slf4j를 사용하는 이유
특정 로깅 프레임워크에 종속되지 않음
Slf4j를 사용하면 코드 수정 없이 Logback, Log4j 등 원하는 로깅 프레임워크를 쉽게 교체할 수 있습니다
System.out.println()보다 성능 우수
System.out.println()은 단순한 콘솔 출력이지만, Slf4j는 다양한 출력 대상(파일, DB, 원격 서버 등)에 기록할 수 있습니다
System.out.println()은 실행 속도가 느리지만, Slf4j는 비동기 로깅 및 레벨 제어가 가능하여 성능 최적화에 유리합니다.
로그레벨 지원
Slf4j는 로그의 중요도에 따라 TRACE, DEBUG, INFO, WARN, ERROR 등의 로그 레벨을 제공하여 필요한 정보만 기록할 수 있도록 합니다.
로그 레벨설명
로그 레벨
설명
TRACE
가장 상세한 디버깅 로그
DEBUG
개발 시 필요한 디버깅 정보
INFO
운영 시 중요한 정보 로그
WARN
경고 로그 (문제 가능성 존재)
ERROR
심각한 오류 발생 로그
Slf4j 사용법
Lombok에서는 @Slf4j를 지원하여 간편하게 사용할 수 있습니다. @Slf4j는 AOP(Aspect-Oriented Programming) 기능을 활용하여 자동으로 Logger 객체를 생성해줍니다.
claims.get("role").toString().split(",") → JWT에 저장된 사용자 권한(role)을 가져와서 리스트로 변환.
new UsernamePasswordAuthenticationToken(claims.getSubject(), token, authorities); → JWT에서 가져온 사용자 정보를 기반으로 Authentication 객체 생성. -> UsernamePasswordAuthenticationToken은 Authentication 객체의 구현체
제가 공부한 내용을 정리하는 블로그입니다. 아직 많이 부족하고 배울게 너무나도 많습니다. 틀린내용이 있으면 언제나 가감없이 말씀해주시면 감사하겠습니다😁
스프링부트와 리액트를 활용해 로그인을 구현 프로젝트를 진행합니다. 순서는 1. 프로젝트 초기화 2. 쿠키를 이용한 로그인 구현 3. 세션을 이용한 로그인 구현 4. JWT 토큰을 활용한 로그인 구현 입니다.
네번째는 Security 이론입니다.
Spring Security란
스프링 보안은 강력하고 고도로 사용자 지정 가능한 인증 및 액세스 제어 프레임워크입니다. 스프링 기반 애플리케이션을 보호하기 위한 사실상의 표준입니다.
Spring Security는 Java 애플리케이션에 인증과 권한 부여를 모두 제공하는 데 중점을 둔 프레임워크입니다. 모든 Spring 프로젝트와 마찬가지로 Spring Security의 진정한 힘은 사용자 지정 요구 사항을 충족하기 위해 얼마나 쉽게 확장할 수 있는지에서 찾을 수 있습니다 - Spring Security 공식 docs
Spring Security는 Spring 기반 애플리케이션의 인증, 권한관리 그리고 데이터 보호기능을 포함하는 프레임워크입니다. 인증(Authentication), 권한 부여(Authorization), 데이터 보호 등의 기능을 제공하여 애플리케이션의 보안 요구 사항을 쉽게 해결할 수 있도록 돕습니다. 특히 웹 애플리케이션의 다양한 보안 위협(CSRF, XSS 등)을 방어하고, 사용자가 인증된 상태에서 적절한 리소스 접근 권한을 갖도록 제어합니다.
Spring Security의 핵심 역할은 다음과 같습니다:
사용자가 누구인지 확인(인증)
사용자가 무엇을 할 수 있는지 결정(권한 부여)
웹 애플리케이션의 데이터를 안전하게 보호
Spring Security를 사용하는 이유
보안 위협 방어
Spring Security는 CSRF(Cross-Site Request Forgery), XSS(Cross-Site Scripting), 세션 고정 공격(Session Fixation) 등 다양한 보안 위협에 대한 기본 방어 기능을 제공합니다.
인증과 권한 관리의 편의성
기본적으로 제공되는 인증 및 권한 부여 로직을 활용하거나, 커스터마이징하여 복잡한 보안 요구 사항을 구현할 수 있습니다.
손쉬운 통합
Spring Security는 Spring Framework 및 Spring Boot와 자연스럽게 통합되며, 설정과 구성이 간단합니다.
확장성과 커스터마이징
사용자 정의 인증, 권한 정책, 필터 등을 구현하여 프로젝트 요구 사항에 맞는 보안 구조를 설계할 수 있습니다.
IoC/DI 패턴과 같은 확장 패턴을 염두하여 개발이 가능하였습니다.
업계 표준 준수
OAuth2, JWT, OpenID Connect 등 표준 보안 프로토콜을 지원하여 최신 보안 트렌드에 맞는 애플리케이션을 개발할 수 있습니다.
Spring Security 주요 개념
Authentication (인증) 인증은 사용자가 본인이 맞는지를 확인하는 과정입니다. 사용자가 올바른 자격 증명(예: 아이디와 비밀번호)을 제공했는지 확인합니다.
AuthenticationManager: 인증 처리를 담당하는 인터페이스.
UserDetailsService: 사용자 정보를 로드하는 서비스.
PasswordEncoder: 비밀번호 암호화 및 검증 처리.
인증방식
credential 방식: username, password를 이용하는 방식 principal -> 아이디(username), credential -> 비밀번호(password)
이중 인증(twofactor 인증): 사용자가 입력한 개인정보를 인증 후, 다른 인증 체계를 이용하여 두가지의 조합으로 인증하는 방식
하드웨어 인증: 자동차 키와 같은 방식
Authorization (인가) 권한 부여는 사용자가 특정 리소스나 작업을 수행할 권한이 있는지 확인하는 과정입니다.
GrantedAuthority: 사용자의 권한 정보.
AccessDecisionManager: 권한 부여 판단을 담당.
Security Context SecurityContextHolder를 통해 애플리케이션 전반에서 현재 사용자의 인증 및 권한 정보를 관리합니다.
Filter Chain Spring Security는 HTTP 요청을 처리하기 위해 여러 필터를 체인 형태로 연결합니다. 주요 필터:
UsernamePasswordAuthenticationFilter: 사용자 인증 처리.
BasicAuthenticationFilter: HTTP Basic 인증 처리.
CsrfFilter: CSRF 보호.
Spring Security 동작 원리
아키텍처
스프링 시큐리티 아키텍처
클라이언트가 서버에 요청을 보냅니다.
AuthenticationFilter가 요청을 인터셉트하고 이를 AuthenticationManager에 전달합니다.
AuthenticationManager는 등록된 AuthenticationProvider를 탐색하여 인증 처리를 위임합니다.
AuthenticationProvider는 사용자 데이터를 확인하고, 인증된 UserDetails 객체를 반환합니다.
인증 결과는 SecurityContextHolder에 저장되며, 저장된 사용자 정보는 Spring Controller에서 활용할 수 있습니다.
제가 공부한 내용을 정리하는 블로그입니다. 아직 많이 부족하고 배울게 너무나도 많습니다. 틀린내용이 있으면 언제나 가감없이 말씀해주시면 감사하겠습니다😁
해당 포스팅은 Bash Shell 정리입니다.
서론
Bash는 유닉스 및 리눅스 환경에서 사용되는 가장 널리 알려진 셸로, 강력한 스크립팅 기능을 제공하여 시스템 관리와 반복 작업 자동화에 매우 유용합니다. Bash Shell 스크립팅은 단순한 명령어 실행을 넘어 변수, 조건문, 반복문, 함수 등을 활용하여 복잡한 작업을 효율적으로 처리할 수 있습니다. 이번 포스팅에서는 Bash Shell 프로그래밍을 초보자도 쉽게 이해하고 활용할 수 문법 정리를 하겠습니다!
본론
1. Bash 스크립트 기본 구조
쉘 스크립트는 첫줄에 어떤 쉘로 스크립트를 실행할지 정의하는 부분이 존재합니다.
Bash 스크립트는 #!/bin/bash라는 셰뱅(Shebang)으로 시작하며, 실행 권한을 부여한 후 실행됩니다.
#!/bin/bash echo"Hello, World!"
쉘 종류
sh: 초기 유닉스 쉘
bash: sh와 대부분 호환되는 Bash Shell
ksh: 콘 쉘이라고도 불리며 sh를 확장하여 만든 쉘
csh: C언어 기반의 쉘
스크립트 실행
chmod +x script.sh
./script.sh
실행권한을 주어야 스크립트를 실행할 수 있습니다.
2. 변수와 데이터
변수는 프로그래밍 언어들과 같은 제약조건이 존재하며 값을 사용할 때에는 $로 시작하고 변수를 생성할 때에는 대입문자 앞뒤로 공백이 없어야 합니다.
변수 선언
variable="값"
변수호출
echo$variable# {}가 있으나 없으나 $만으로 변수의 값을 넣어줄 수 있으나, 문자열을 붙여서 쓸려면 ${} 를 사용해야 한다.echo"this product's price is ${variable}"
읽기 전용 변수
readonly variable
사용자 입력 받기
read -p "Enter your name: " name
echo"Hello, $name!"
환경변수
쉘 스크립트에서 변수명 앞에 export를 붙여주면 환경변수로 설정되어 스크립트에서 사용 가능합니다.
#!/bin/bashecho"첫 번째 매개변수: $1"echo"두 번째 매개변수: $2"echo"모든 매개변수: $@"echo"매개변수 개수: $#"# 실행
./script.sh Hello World
# 출력
첫 번째 매개변수: Hello
두 번째 매개변수: World
모든 매개변수: Hello World
매개변수 개수: 2
특수 변수
설명
$0
실행된 스크립트의 이름
$#
매개변수의 갯수
$@
모든 매개변수
$*
모든 매개변수(하나의 문자열로)
$$
현재 스크립트의 PID
$?
이전 명령어의 종료 상태(0: 성공)
$!
마지막으로 실행된 백그라운드 명령어의 PID
6. 파일 처리
파일 존재 여부 확인
if [ -e filename ]; thenecho"파일이 존재합니다."fi
파일 읽기 예제
whileread line; doecho$linedone < filename.txt
7. 기타 유용한 문법
명령어 실행 결과 저장
result=$(ls -l)
echo"$result"
에러 처리
command || echo"명령어 실패!"
결론
Bash Shell 프로그래밍은 간단한 문법으로 시스템을 제어하고 반복 작업을 자동화하는 데 강력한 도구가 됩니다. 이번 포스팅에서는 변수, 조건문, 반복문, 함수 등 핵심 문법을 정리했으며, 이를 기반으로 더 복잡한 스크립트를 작성할 수 있습니다. 꾸준한 연습과 다양한 예제 실습을 통해 Bash 스크립팅 실력을 쌓아 보세요😁
Spring Boot에서는 별도의 설정 없이도 swagger-ui와 OpenAPI 문서를 사용할 수 있습니다. SpringDoc 라이브러리를 추가하면 /swagger-ui.html 또는 /swagger-ui/index.html 경로에서 Swagger UI에 접근할 수 있습니다.
SwaggerConfig 설정
SwaggerConfig 클래스는 OpenAPI 문서의 기본적인 설정을 커스터마이징할 수 있도록 작성됩니다. Spring Boot와 SpringDoc을 사용하면 Swagger UI와 OpenAPI 문서를 별도의 설정 없이 기본적으로 사용할 수 있지만, 프로젝트 이름, API 설명, 버전 정보 등을 명확히 하기 위해 SwaggerConfig 클래스에서 OpenAPI 객체를 설정할 수 있습니다.
SecurityScheme 설정 SecurityScheme 객체를 통해 Swagger 문서에 JWT 인증 방식을 정의합니다.
type: 인증 방식의 타입을 설정합니다. 여기서는 HTTP 방식을 사용합니다.
scheme: bearer로 설정하여 JWT 인증임을 명시합니다.
bearerFormat: 토큰의 형식을 "JWT"로 지정합니다.
in: 인증 정보가 포함되는 위치를 지정합니다. JWT 토큰은 보통 HTTP 헤더의 Authorization 필드에 포함됩니다.
name: 헤더의 이름을 Authorization으로 설정합니다.
SecurityRequirement 설정 SecurityRequirement 객체는 Swagger 문서에서 JWT 인증이 필요한 엔드포인트에 보안 요구사항을 추가합니다.
addList("bearerAuth"): 위에서 정의한 SecurityScheme을 엔드포인트에 적용합니다.
Components 설정 OpenAPI의 구성 요소에 SecurityScheme을 추가합니다.
addSecuritySchemes("bearerAuth", securityScheme): bearerAuth라는 이름으로 JWT 인증 스키마를 등록합니다.
security 설정
OpenAPI 문서의 기본 보안 요구사항을 정의합니다. 모든 엔드포인트에 기본적으로 JWT 인증이 필요하도록 설정됩니다.
info() 메서드 API 문서의 제목, 설명, 버전 정보 등을 설정합니다.
API를 기능별로 나누고 싶다면
@ConfigurationpublicclassSwaggerConfig{
@Beanpublic GroupedOpenApi userApi(){
return GroupedOpenApi.builder()
.group("user-api") // 사용자 관련 API 그룹
.pathsToMatch("/users/**", "/profile/**")
.build();
}
@Beanpublic GroupedOpenApi adminApi(){
return GroupedOpenApi.builder()
.group("admin-api") // 관리자 관련 API 그룹
.pathsToMatch("/admin/**", "/management/**")
.build();
}
@Beanpublic GroupedOpenApi publicApi(){
return GroupedOpenApi.builder()
.group("public-api") // 공개 API 그룹
.pathsToMatch("/public/**", "/auth/**")
.build();
}
/*
* ...
*/
}
GroupedOpenApi 정의:
group: Swagger UI에서 보여질 그룹 이름입니다.
pathsToMatch: 해당 그룹에 포함될 엔드포인트 경로를 지정합니다. /**와 같은 경로 패턴을 사용할 수 있습니다.
그룹 나누기:
user-api: /users/**, /profile/**로 시작하는 엔드포인트를 포함합니다.
admin-api: /admin/**, /management/**로 시작하는 엔드포인트를 포함합니다.
public-api: /public/**, /auth/**로 시작하는 엔드포인트를 포함합니다.
컨트롤러에 Swagger 어노테이션 추가
컨트롤러에 @Tag, @Operation, @ApiResponse 등 OpenAPI 3 스펙 기반의 애노테이션을 추가하여 API 엔드포인트를 문서화할 수 있습니다.
@RestController@RequestMapping("/api/users")@Tag(name = "User API", description = "Operations for managing users")publicclassUserController{
@Operation(summary = "Get all users", description = "Retrieve a list of all users.")@GetMappingpublic List<User> getAllUsers(){
return List.of(new User(1L, "John", "john@example.com"));
}
@Operation(summary = "Create a user", description = "Add a new user to the system.")@ApiResponse(responseCode = "201", description = "User created successfully.")@PostMappingpublic User createUser(@RequestBody User user){
return user; // For demonstration purposes
}
}
@Tag @Tag는 OpenAPI 스펙에서 API의 그룹화를 위한 어노테이션입니다. 주로 컨트롤러 레벨에서 사용되며, Swagger UI에서 API를 그룹별로 정리해서 보여줍니다.
주요속성
name: 태그의 이름. Swagger UI에서 그룹명으로 표시됩니다.
description: 태그에 대한 설명을 작성합니다.
@Operation @Operation은 API 엔드포인트(메서드) 수준에서 사용됩니다. 해당 메서드에 대한 요약, 설명, 요청/응답에 대한 정보 등을 문서화합니다.
주요속성
summary: API 엔드포인트에 대한 간단한 설명 (Swagger UI에서 메서드 옆에 표시).
description: API 엔드포인트에 대한 상세 설명.
tags: 이 엔드포인트에 추가적으로 적용할 태그 목록. 컨트롤러에 정의된 @Tag와는 별개로 추가 가능.
parameters: 요청에 필요한 매개변수 정의 (필요시 사용).
responses: 응답에 대한 설명을 추가 (일반적으로 @ApiResponse와 함께 사용).
@ApiResponse @ApiResponse는 특정 API 엔드포인트의 응답 정보를 문서화하는 데 사용됩니다. 응답 상태 코드와 메시지, 반환되는 데이터에 대한 설명을 추가할 수 있습니다.
주요속성
responseCode: HTTP 응답 상태 코드 (예: "200", "404", "500").
제가 공부한 내용을 정리하는 블로그입니다. 아직 많이 부족하고 배울게 너무나도 많습니다. 틀린내용이 있으면 언제나 가감없이 말씀해주시면 감사하겠습니다😁
스프링부트와 리액트를 활용해 로그인을 구현 프로젝트를 진행합니다. 순서는 1. 프로젝트 초기화 2. 쿠키를 이용한 로그인 구현 3. 세션을 이용한 로그인 구현 4. JWT 토큰을 활용한 로그인 구현 입니다.
세번째는 세션을 이용한 로그인 구현입니다.
서론
이전 쿠키 포스팅에서 STATELESS한 HTTP 프로토콜에서 STATEFUL한 서비스를 위한 장치로 헤더에 쿠키를 저장하는 로직으로 설계하였습니다.
하지만 해당 방법은 개인 정보들을 브라우저 단에 저장하여 위변조 및 도용이 쉽다는 문제가 있습니다. 보안적인 부분은 클라이언트가 아닌 서버에서 관리하여 외부로 해당 개인정보를 숨겨 보안성을 높여야합니다. 따라서 클라이언트는 키만 가지고 있으며 해당 정보는 서버에서 관리하고 있는 방법을 세션이라고 합니다.
저는 이 포스팅에서 세션을 두가지 방법으로 구현합니다. 첫번째는 쿠키를 이용한 세션과 속성 기반으로 세션을 구현할 예정입니다.
세션
정의
세션(Session)은 서버가 클라이언트의 상태를 유지하기 위해 일정 기간 동안 저장하는 정보를 의미합니다. 클라이언트의 요청마다 동일한 사용자임을 식별할 수 있도록 하는 상태 관리 방식입니다. 보통 서버는 클라이언트가 전달한 세션 ID를 기반으로 특정 사용자와 연결된 정보를 조회합니다.
역할
사용자 식별: 세션 ID를 통해 동일 클라이언트의 요청임을 서버가 식별합니다.
상태 유지: 로그인 상태, 장바구니 정보 등 사용자의 상태 정보를 서버에서 저장 및 관리합니다.
보안 강화: 민감한 정보는 서버에 저장하고, 클라이언트는 세션 ID만 전달하므로 정보 위변조 위험을 줄입니다.
구조
세션 구조
클라이언트 측
브라우저는 서버로부터 세션 ID를 받아 저장(주로 쿠키에 저장)하고, 이후 요청마다 세션 ID를 포함하여 서버에 전달합니다.
서버 측
서버는 세션 저장소(메모리, 데이터베이스 등)에 세션 ID와 상태 정보를 저장하고, 세션 ID를 키로 사용하여 클라이언트 데이터를 관리합니다.
장점
보안성
민감한 데이터가 서버에 저장되므로 클라이언트에서 정보가 노출될 위험이 줄어듭니다.
유연성
상태 정보는 서버에 저장되므로 클라이언트가 브라우저를 닫더라도 세션이 만료되지 않으면 상태를 유지할 수 있습니다.
확장성
서버의 세션 저장소를 확장하여 대량의 사용자 상태를 관리할 수 있습니다.
단점
서버 부담
세션 데이터를 서버에서 관리하므로 사용자 수가 많아질수록 서버 메모리나 저장소 사용량이 증가합니다.
스케일링 문제
서버가 분산 환경일 경우, 세션 데이터를 공유하기 위한 추가 작업(예: 세션 클러스터링)이 필요합니다.
만료 관리
세션 만료 시간 설정이 필요하며, 만료되지 않은 오래된 세션 데이터가 서버의 리소스를 점유할 수 있습니다.
Session-login(쿠키 기반)
Frontend
localhost:3000/login-session에 접근하기 위해 routepath를 지정합니다.