리눅스 파이썬 오류
: 폴더를 한글 이름으로 만들어서 그랬음
Git
git 초기 세팅
0. git 시작
git init1. 원격 저장소 확인
git remote -v2. 원격 저장소 추가
만약 원격 저장소가 설정되어 있지 않다면, 원격 저장소를 추가
git remote add origin https://github.com/닉네임/리포지터리이름.git3. 원격 저장소 URL 설정 (Personal Access Token 사용)
그 후 Personal Access Token을 사용하여 원격 저장소 URL을 설정
git remote set-url origin https://<토큰>@github.com/닉네임/리포지터리이름.gitgit 삭제
rm -r .gitgit 버전 확인
git loggit 버전 되돌리고 강제 반영
git push -f origin master다른 branch pull하기
git pull origin [다른브랜치]git 병합하는법
출처 : https://codingapple.com/unit/git-rebase-squash/
1. 3-way merge
브랜치에 각각 신규 commit이 1회 이상 있는 경우
merge 명령을 내리면 두 브랜치의 코드를 합쳐서 새로운 commit을 자동으로 생성
2. fast-forward merge
딱히 합칠게 없어서 그냥 신규브랜치 보고
"지금부터 니 이름은 main 브랜치여" 하는 것
3. rebase and merge
rebase는 브랜치의 시작점을 다른 commit으로 옮겨주는 행위
rebase and merge 하고 싶으면
1. 새로운 브랜치로 먼저 이동해서
2. git rebase main 하면 됩니다.
3. 그럼 브랜치가 main 브랜치 끝으로 이동하는데 그걸 fast-forward merge
4. squash and merge
새 브랜치에 있던 코드변경사항들이 main 브랜치로 텔레포트
conflict 해결
<<<<<<<<<<<<<< HEAD
[현재 브랜치의 변경 사항]
================== [구분선]
[머지 대상 브랜치의 변경 사항]
>>>>>>>>>>>>>> [대상 브랜치명]충돌을 해결하기 위해서 <<<<<<<<와 =========와 >>>>>>>>>을 모두 제거한 후 선택해야 되는 변경사항을 반영해 깨끗하게 만들면 됨
세션, 쿠키, JWT
세션(Session)
서버 측 저장: 세션 데이터는 서버에 저장되며, 클라이언트에는 세션 ID만 전달됩니다.
보안: 중요한 데이터를 서버에 저장하기 때문에 보안성이 높습니다.
유효 시간: 세션은 유효 시간이 있으며, 일정 시간이 지나면 자동으로 만료됩니다.
확장성: 서버 메모리나 데이터베이스에 저장되므로, 서버 간 세션 데이터를 공유해야 할 경우 복잡해질 수 있습니다.
세션 사용 사례
전통적인 웹 애플리케이션: 세션은 전통적인 서버 렌더링 웹 애플리케이션에서 많이 사용됩니다.
보안이 중요한 경우: 중요한 데이터를 서버에 저장하고, 세션 ID만 클라이언트에 전달하여 보안성을 유지할 수 있습니다.
쿠키(Cookie)
클라이언트 측 저장: 쿠키 데이터는 클라이언트(브라우저)에 저장되며, 서버와의 요청 시마다 전송됩니다.
데이터 크기 제한: 쿠키는 데이터 크기가 제한적이며, 중요한 데이터를 저장하기에는 적합하지 않습니다.
보안: 쿠키는 클라이언트 측에 저장되므로, 민감한 정보는 저장하지 않는 것이 좋습니다. HTTPS를 사용하여 전송 보안을 강화할 수 있습니다.
편의성: 클라이언트 측에 데이터를 저장하므로, 서버 측 부하를 줄일 수 있습니다.
쿠키 사용 사례
기본적인 상태 유지: 사용자가 사이트를 재방문할 때 특정 설정이나 상태를 유지하기 위한 용도로 사용됩니다.
간단한 인증: 간단한 로그인 상태 유지와 같은 경우에 사용할 수 있습니다.
JWT (JSON Web Token)
토큰 기반 인증: JWT는 클라이언트와 서버 간의 인증 및 정보를 안전하게 전송하기 위한 토큰 기반 인증 방식입니다.
클라이언트 측 저장: JWT는 클라이언트 측(보통 로컬 스토리지 또는 세션 스토리지)에 저장됩니다.
무상태성: 서버가 세션 상태를 저장할 필요가 없으며, 클라이언트가 토큰을 포함한 요청을 보낼 때마다 서버가 토큰을 검증하여 인증합니다.
확장성: 서버 간 상태를 공유할 필요가 없으므로, 확장성이 뛰어납니다.
보안: 토큰은 서명되어 있어 변조를 방지할 수 있지만, 클라이언트 측에 저장된 토큰이 탈취될 경우 문제가 발생할 수 있습니다.
JWT 사용 사례
SPA (Single Page Application): JWT는 클라이언트 측에서 대부분의 로직이 실행되는 SPA에서 많이 사용됩니다.
모바일 애플리케이션: 모바일 애플리케이션에서도 토큰 기반 인증으로 JWT를 많이 사용합니다.
마이크로서비스 아키텍처: 무상태성 인증 방식이므로, 마이크로서비스 간에 상태를 공유할 필요 없이 인증을 처리할 수 있습니다.
쿠키와 세션을 함께 사용하는 이유
보안성 향상: 민감한 데이터를 클라이언트에 직접 저장하는 것은 보안 위험이 있습니다. 세션을 사용하면 중요한 데이터를 서버 측에 저장하고, 클라이언트에는 세션 ID만 저장하여 이러한 위험을 줄일 수 있습니다.
상태 유지: 쿠키는 클라이언트가 서버에 여러 요청을 보낼 때 동일한 사용자인지 식별하는 데 유용합니다. 세션 ID를 쿠키에 저장하면 서버는 이 세션 ID를 통해 사용자의 상태를 유지할 수 있습니다.
데이터 크기 제한: 쿠키는 데이터 크기에 제한이 있습니다(약 4KB). 반면, 세션은 서버 측에 저장되므로 더 많은 데이터를 저장할 수 있습니다.
효율성: 세션 ID만 쿠키에 저장하면, 클라이언트와 서버 간의 데이터 전송량을 최소화할 수 있습니다. 세션 데이터는 서버에만 저장되므로 네트워크 부담이 줄어듭니다.
쿠키, JWT 보안 비교
-
XSS 공격
쿠키: HTTPOnly 속성을 사용하면 자바스크립트에서 쿠키에 접근할 수 없어, XSS 공격에 강합니다.
JWT: 로컬 스토리지나 세션 스토리지에 저장하면 XSS 공격에 취약할 수 있습니다. 이를 방지하기 위해 쿠키에 저장하고 HTTPOnly 속성을 사용하는 방법도 있습니다. -
CSRF 공격
쿠키: CSRF 공격에 취약할 수 있습니다. 이를 방지하기 위해 CSRF 토큰을 사용해야 합니다.
JWT: 로컬 스토리지나 세션 스토리지에 저장하면 CSRF 공격에 덜 취약합니다. 그러나 JWT를 쿠키에 저장하면 동일한 CSRF 위험이 있습니다. -
데이터 보호
쿠키: 중요한 데이터는 서버 측에 저장되고, 클라이언트에는 세션 ID만 저장되어 데이터 보호가 용이합니다.
JWT: JWT는 자체적으로 정보를 포함하므로, 서명 및 암호화를 통해 데이터를 보호할 수 있습니다. 그러나 클라이언트 측에 저장되므로 탈취될 위험이 있습니다. -
사용 환경
쿠키: 전통적인 웹 애플리케이션에서 많이 사용되며, 서버 측 세션과 함께 사용되어 보안성이 높습니다.
JWT: SPA, 모바일 앱, 마이크로서비스 아키텍처 등 무상태성 인증이 필요한 환경에서 많이 사용됩니다.
세션
출처 :https://patrick-f.tistory.com/13
세션으로 로그인하는 과정
- 사용자가 서버에 로그인 요청을 날림
- 서버는 요청을 회원 DB와 대조
- 회원 DB에 있으면 서버에서 세션을 생성
- 생성한 세션 정보를 세션 DB(pymongo)에 보낸다
세션 저장소 종류
- 톰캣 세션
- 데이터베이스(ex.MySQL)
- 메모리 DB(Redis, Memcached)
pymongo
SECRET_KEY
SECRET_KEY는 플라스크가 어떤 값을 암호화할 때 사용하는 중요한 환경 변수다. 예를 들어 로그인 비밀번호 등은 이 SECRET_KEY를 사용해 암호화된다.
app = Flask(__name__)
app.config['SECRET_KEY'] = os.urandom(24)소스 코드 유출 시 문제점
secret_key가 소스 코드와 함께 유출되면, 공격자가 세션 데이터를 해독하거나 위조할 수 있습니다. 따라서, secret_key는 소스 코드와 분리하여 안전하게 저장해야 합니다.
환경 변수나 비밀 관리 시스템(예: AWS Secrets Manager, HashiCorp Vault)을 사용하여 관리합니다.
.env 파일에 저장하고, 이 파일을 버전 관리 시스템에서 제외합니다.
flask jwt 구현
https://blog.oseonsik.com/19
