다른 프레임워크에도 다른 이름으로 같은 기능을 하는 것들이 많다.

프레임워크 | 이름 | 역할 Django | Middleware | 인증, CSRF, 세션 처리 등 Express (Node.js) | Middleware (app.use()) | 요청 로그, CORS 처리 등 Spring (Java) | Filter / Interceptor | 인증, 권한 검사, 로깅 Laravel (PHP) | Middleware | 사용자 인증, 라우팅 제한 FastAPI | Middleware | CORS, 로그, 에러 처리 등 Ruby on Rails | Rack Middleware | 요청 전후 처리

장고에서 실제 쓰는 미들웨어를 보면

MIDDLEWARE = [ 'corsheaders.middleware.CorsMiddleware', 'django.middleware.security.SecurityMiddleware', 'django.contrib.sessions.middleware.SessionMiddleware', 'django.middleware.common.CommonMiddleware', 'django.middleware.csrf.CsrfViewMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware', 'django.contrib.messages.middleware.MessageMiddleware', 'django.middleware.clickjacking.XFrameOptionsMiddleware', 'allauth.account.middleware.AccountMiddleware', ]

cors, https, session기반 로그인/로그아웃, csrf, clickjacking 방지 등등

생각보다 많은 기능을 한다.

간단히 표현하면 클라이언트와 view 사이에서 요청을 잠시 hook하여 요청에 다양한 효과를 부과한다음 전달하는 기능이라고 이해하면 될듯하다.

레퍼런스 카운팅이라고 하는데 객체를 참조하면 1이 증가하고, 참조가 없어지면 다시 0이되는 방식으로 메모리를 처리하고

세대별 가비지컬렉션으로 순환참조도 처리하여 메모리 누수를 막는다.

duck typing은

오리처럼 울고, 오리처럼 걸으면 오리다.

이런 옛말이라고 하는데 파이썬에서 타입이 정해지지 않아도 그 타입처럼 작동한다면 그 타입으로 본다는것이다.

파이썬은 동적언어라서 코드의 타입을 정하지 않아도, 동작만으로 타입을 판단할 수 있고 그래서 깔끔한 코드 구현이 가능하다.

이 둘은 c언어를 기반으로 돌아가는 라이브러리기 때문이다.

이건 컴파일언어와 인터프리터 언어의 차이를 알고 가야한다.

python은 인터프리터 언어로 한줄한줄 해석하며, 타입, 객체 등을 정하며 해석하기 때문에 느리지만

c언어는 컴파일언어로 적으면 바로 기계어 바이너리 기계식 언어로 해석한걸 읽기 때문에

10~100배정도 차이가 난다.

java는 컴파일, 인터프리터 언어가 복합되어 구성되어있다.

그래서 두개의 라이브러리는 c언어 기반으로 계산을 하기때문에 계산 속도가 파이썬과 비교가 안된다.

나중에 소셜로그인을 하게된다면 이 정리를 보고 다시 할 수 있을 정도로 정리해보자.

우선 구글로그인 하나만 해도 나머진 할 수 있으니까 구글로만 정리를 해보려고한다.

우선 구글 개발자 콘솔에 들어가야한다.

https://console.cloud.google.com/

API 만드는데 들어가서 "OAuth 동의 화면"를 들어간다.

그 뒤 웹페이지 클라이언트를 만들어서 안에 들어가보면 다음과 같이 있을거다.

승인된 JavaScript 원본 승인된 리디렉션 URI

승인된 JavaScript 원본 여기에는 내가 사용하는 프로젝트의 주소, 아니면 테스트할 로컬 주소를 입력하면된다. 나의 경우는 https://www.livflow.co.kr, http://localhost:5173 이렇게 2개를 입력해주면 된다.

승인된 리디렉션 URI 로그인 이후에 올 페이지 엔드포인트를 적어주면된다. http://localhost:5173/auth/login/callback/google 이런식으로 해두었다.

이제 소셜로그인의 플로우를 봐보자

[사용자] → (로그인 버튼 클릭) ↓ [프론트엔드] → (구글 인증 서버로 리디렉션) ↓ [구글 로그인 완료] → (인가 코드 발급) ↓ [프론트엔드] → (인가 코드 백엔드로 전송) ↓ [백엔드] → (인가 코드로 액세스 토큰 요청) ↓ [구글] → (액세스 토큰 + 사용자 정보 반환) ↓ [백엔드] → (JWT 발급 + Redis에 리프레시 토큰 저장) ↓ [프론트엔드] ← (액세스 토큰 쿠키로 전달) ↓ [사용자 로그인 완료 🚀]

구글 인증서버는 이런 주소를 쓴다. https://accounts.google.com/o/oauth2/v2/auth 그럼 여기로 가서 사용자가 구글로그인을 성공하면 인가코드가 나온다. 그럼 인가코드를 백엔드로 전송해서 해당 함수에 넣어야한다 .

class GoogleAuth(APIView):
    authentication_classes = []
    permission_classes = [AllowAny]

    def post(self, request, *args, **kwargs):
        code = request.data.get("code")
        token_endpoint = "https://oauth2.googleapis.com/token"
        data = {
            "code": code,
            "client_id": os.getenv("GOOGLE_CLIENT_ID"),
            "client_secret": os.getenv("GOOGLE_CLIENT_SECRET"),
            "redirect_uri": os.getenv("GOOGLE_REDIRECT_URI"),
            "grant_type": "authorization_code",
        }

만약 이 엔드포인트가 www.api.liv/google/login/callback/ 이런식이라고 보면

프론트 엔드에서는 이 엔드포인트로 인가코드를 전달해야한다.

그럼 Googleauth라는 함수에서

  "code": code,

이 부분에서 인가코드를 받고 구글 개발자 콘솔에 있는 client_id, client_secret, redirect_uri 이 부분을 https://oauth2.googleapis.com/token 이 주소로 보내게 된다.

그럼 코드와 id, secret, uri가 모두 일치한다면

구글에서는 액세스 토큰과 리프레시 토큰을 재발급해준다.

그럼 이 토큰을 가지고

https://www.googleapis.com/oauth2/v2/userinfo

이 엔드포인트에 보내 원하는 유저 정보를 받아온다.

그 뒤 해당 정보를 가지고 백엔드 jwt에서 자체적으로 토큰을 제작한다 .

이 이름도 액세스토큰, 리프레시 토큰이다.

그럼 이제 소셜로그인을 통해

유저 정보와 jwt 액세스토큰, 리프레시 토큰이 생성된다.

그 뒤에 토큰 관리방법은 다양한 방법이 있어서 선택하면되지만

리프레시 토큰의 생명주기가 긴 만큼 보안이 확실하게 관리하고

액세스 토큰은 세션에서 관리하는게 편할 듯 하다.

services:
  # 프론트엔드 빌드 서비스
  frontend:
    build:
      context: .  # 현재 디렉토리를 빌드 컨텍스트로 사용
      dockerfile: dockerfile  # 사용할 Dockerfile 지정
    container_name: frontend-container  # 컨테이너 이름
    volumes:
      #- build_volume:/usr/share/nginx/html  # Nginx 컨테이너에서 제공할 빌드 결과물 경로에 매핑
      - /etc/letsencrypt:/etc/letsencrypt:ro
#./dist:

  # Nginx 컨테이너
  frontend-nginx:
    image: nginx:1.23-alpine  # Nginx 이미지 사용
    container_name: frontend-nginx  # Nginx 컨테이너 이름
    ports:
      - "80:80"
      - "443:443"  
    volumes:
     # - build_volume:/usr/share/nginx/html
      - ./nginx.conf:/etc/nginx/nginx.conf
      - /etc/letsencrypt/archive/livflow.co.kr/fullchain2.pem:/etc/letsencrypt/live/livflow.co.kr/fullchain.pem
      - /etc/letsencrypt/archive/livflow.co.kr/privkey2.pem:/etc/letsencrypt/live/livflow.co.kr/privkey.pem
      - ./certbot:/var/www/certbot

volumes:
  build_volume:
    driver: local
    driver_opts:
      type: "none"
      device: "./dist"  # 빌드된 정적 파일들이 있는 경로를 지정
      o: "bind"

사실 만들때부터 1개로..해도되나...? 하면서 만들긴했다.

백엔드만 배포해보다가 프론트엔드 배포를 처음해봐서 그런지 2개 컨테이너로 하는게 기본인가 했는데 역할을 생각해보면 1개여도 충분했었다.

근데 이 부분이 배포에서 문제를 일으킬줄 몰랐다. 보면 frontend-container, frontend-nginx

이렇게 있는데 frontend-nginx가 배포해주는 .DIST가 있는 컨테이너다. 이게 분리되어 있다보니

CICD도 잘되고, 서버에 코드도 최신화가 되는데 배포 .DIST파일이 과거 파일이라 웹페이지가 이전꺼로 보이는 문제가 발생했다. 괜히 이것때문에 소셜로그인 고쳐본다고 시간만 버렸다.

어쨋든 통합컨테이너로 바꾼 뒤 문제는 사라져서 다행이다.

이 gunicorn은 HTTP 요청을 받아서 Django 애플리케이션에 전달하고, 그 결과를 클라이언트에게 응답하는 역할을 한다.

장고를 예시로 들자면 장고를 실행할 수 있는 일반적인 방법은 3개이다.

하나는 로컬에서 테스트할때 많이 쓰는 runserver 다만 이건 단일스레드에 배포환경에서는 부적합하다.

두번째는 웹소켓을 사용할때 쓰는 uvicorn 이건 동기식 지원을 할때 쓴다.

그리고 세번째가 gunicorn이다.

uvicorn은 FastAPI, Starlette, Django ASGI에 많이 사용되고

Gunicorn은 Django, Flask에 많이 사용된다.

물론 이렇게 보다보면 장고에서 웹소켓을 사용할때 쓰는 daphen이랑 uvicorn이 비슷해 보일 수 있는데,

Daphne는 Django Channels와 함께 사용되도록 설계있기 때문에 장고 채널스를 쓰는 곳에서는 uvicorn이아니라 dahpen을 사용해야한다. uvicorn은 비동기 프레임워크에 사용하는 고성능 asgi서버이기 때문에 장고뿐아니라 다양한 곳에서 사용할 수 있고, FastAPI, Starlette에서 많이 사용한다.

도커를 사용하느라 구니콘은 그저 한,두줄만 사용해봐서 이런 기능이 있는지 몰랐는데

결론

guicorn은 동기식 방식의 멀티프로세스가 가능한 파이썬 htttp서버로, nginx와 같이 사용하면 더 효과적으로 사용할 수 있고,

이와 비슷한 개념으로 uvicorn, daphen, runserver가 있지만 각각 사용하는 프로젝트들이 다르다. 알맞게 사용해야한다.

이전 프로젝트에서는 access token이랑 refresh token을 둘 다 쿠키로 전달했는데 refresh token은 쿠키로 전달하면 안된다고 들어서

이전에 멘토님이 조언해준대로 refresh token을 redis에 담아서 전달해볼까한다.

우선 서버가 NAS라서 모든 배포를 컨테이너로 하고있기 때문에

Redis를 사용하려면 redis 컨테이너가 필요해서 우선 컨테이너를 먼저 구성했다.

  redis:
    image: redis:latest  
    container_name: redis01  
    restart: always  
    ports:
      - "6379:6379"  
    networks:
      - app-network
    command: redis-server --appendonly yes  
    env_file: .env

우선 컨테이너를 구성했고, redis에서 ping pong은 확인을 했는데

아직 토큰을 담고 전달하는 기능은 사용해본적이 없어서 어떤식으로 진행해야할지는 좀더 고민해봐야 할거같다.

이걸로 컨테이너가 하나 더 늘어났다. 이제 7개 컨테이너인데 이게 경쟁력이 있는건지는 잘 모르겠다.

login page에서 버튼 반응이 없는 문제가 발생했다.

고민해보다가 콘솔에 js를 .click으로 직접찍어보고 반응을 확인해보았는데

반응이 있는거로 봐서는 코드적으로는 버튼으로 문제가 있는건 아닌 듯 하다.

그렇다면 login hrf로 이동되지 않는 문제가 있는거 같은데

지금 내 생각으로는 backend login page로 제대로 연결이 안되는건가 싶어서 social login을 먼저 구현해놓아야 할 듯 하다.

간단하게 할때 -> viewset 복잡하게 할때 -> apiview

ViewSet이 적합한 경우

간단한 CRUD 중심 API:

데이터베이스 모델과 직결된 CRUD 작업을 구현할 때, ViewSet과 ModelViewSet이 적합합니다. URL 라우팅이 자동으로 처리되므로 코드가 간결하고 유지보수가 쉬워집니다.

RESTful API 설계:

RESTful 표준 동작(GET, POST, PUT, DELETE 등)을 따르는 경우, ViewSet은 빠르게 CRUD 기능을 구축할 수 있습니다. 커스텀 로직이 적음:

단순 CRUD 작업 외에 추가적인 로직이 거의 필요하지 않을 때 적합합니다. 예를 들어, 블로그 포스트, 사용자 관리 등의 단순한 API를 구축할 때.

커스텀 로직이 적음:

단순 CRUD 작업 외에 추가적인 로직이 거의 필요하지 않을 때 적합합니다. 예를 들어, 블로그 포스트, 사용자 관리 등의 단순한 API를 구축할 때.

APIView가 적합한 경우

복잡한 비즈니스 로직:

요청 처리 과정에서 데이터 검증, 외부 API 호출, 복잡한 계산 등이 필요할 때. 예를 들어, 주문 처리 로직, 동적 권한 부여, 상태 전이에 따른 동작 등이 포함된 경우.

비표준 URL 설계:

RESTful 표준이 아닌 커스텀 URL이 필요하거나, Router로 처리할 수 없는 경로가 있는 경우. 예를 들어, /orders//confirm/와 같은 특정 동작이 포함된 API.

HTTP 메서드별 세부 제어 필요:

각 HTTP 메서드(GET, POST, PUT, DELETE)에서 동작을 세밀하게 제어해야 할 때. 예를 들어, POST 요청에서 특정 조건에 따라 다른 동작을 실행하거나, 응답 구조가 복잡한 경우.

추가적인 인증/권한 로직:

기본 권한 설정 외에 복잡한 인증 및 권한 로직이 필요한 경우.

ViewSet은 데이터 모델과 관련된 CRUD 작업을 효율적으로 처리할 때 가장 적합하다. Router와 함께 사용하여 URL 라우팅을 자동화하고, RESTful API 설계를 간소화할 수 있다.

만약, 복잡한 비즈니스 로직이나 비표준 URL 설계가 필요하다면 APIView나 GenericAPIView를 사용하는 것이 더 나은 선택일 수 있다. 즉, 간단한 CRUD 중심 API를 개발할 때는 ViewSet이 가장 강력하고 효율적인 도구이지만, 로직이 복잡해질걸 예상한다면 apiview나 다른 커스텀 가능한 DRF를 쓰는게 유용할 듯 하다.

Serializer의 주요 역할

직렬화 (Serialization):

Python 객체(Queryset 등)를 JSON 데이터로 변환하여 클라이언트에 응답할 수 있게 합니다.

역직렬화 (Deserialization):

클라이언트로부터 받은 JSON 데이터를 Python 객체로 변환하여 서버에서 처리할 수 있게 합니다.

유효성 검사:

데이터를 변환하는 동시에, 데이터가 유효한지 확인하는 역할을 합니다. 필드의 형식, 값의 범위 등을 검증하고, 문제가 있을 경우 오류를 반환합니다.

기본 serializer와 modelserializer등 다양한 기능이 있는데 Django에서는 주로 model로 쓰는듯하다. 시리얼라이저로 추가하면 모델인스턴스를 데이터베이스에 자동으로 저장해주는 편함이 있다.

is_valid() validated_data save() error()과같은 메서드를 통해 유효성검사를 한다.

주요 메서드에는 4가지가 있고

1. GET

서버에서 데이터를 조회하기 위해 사용. 데이터를 가져올 때 주로 사용되며, 서버의 상태를 변경하지 않음. 예시: GET /users: 모든 사용자 조회 GET /users/1: 특정 사용자(ID 1) 조회

2. POST

서버에 데이터를 생성하거나 전송하기 위해 사용. 클라이언트가 요청 본문(body)에 데이터를 포함하여 전송. 예시: POST /users: 새로운 사용자 생성

3. PUT

서버에서 특정 자원의 전체를 수정하거나 대체할 때 사용. 자원이 없으면 새로 생성할 수도 있음. 예시: PUT /users/1: ID가 1인 사용자 정보 전체 수정

4.DELETE

서버에서 특정 자원을 삭제할 때 사용. 예시: DELETE /users/1: ID가 1인 사용자 삭제

이외에도

5. PATCH

자원의 일부를 수정할 때 사용. PUT은 자원의 전체 교체를 수행하는 반면, PATCH는 필요한 필드만 변경. 예시: PATCH /users/1: ID가 1인 사용자의 일부 정보 수정

6. HEAD

GET 요청과 유사하지만, 응답 본문(body)은 포함하지 않고 헤더만 반환. 자원의 존재 여부나 상태를 확인할 때 사용. 예시: HEAD /users

7. OPTIONS

서버에서 지원하는 HTTP 메서드와 옵션을 확인. 예시: OPTIONS /users

8.CONNECT

클라이언트와 서버 간의 터널을 설정하기 위해 사용. 주로 HTTPS 요청을 처리할 때 프록시 서버와 함께 사용.

9.TRACE

요청이 서버에 도달하는 경로를 디버깅하기 위해 사용. 실무에서는 보안 문제로 인해 거의 사용되지 않음.

이것을 위한 주요 원칙들이 있다.

REST의 주요 원칙

1. 자원(Resource) 기반

웹의 모든 데이터는 "자원(Resource)"으로 간주됩니다. 각 자원은 고유한 URI(Uniform Resource Identifier)로 식별됩니다. 예: /users/1는 ID가 1인 사용자라는 자원을 나타냄.

2. HTTP 메서드의 활용

REST는 HTTP 메서드를 사용해 자원 조작 방식을 명확히 합니다: GET: 자원을 조회 POST: 자원을 생성 PUT: 자원을 수정 DELETE: 자원을 삭제

3. 무상태성(Statelessness)

서버는 클라이언트의 상태를 저장하지 않으며, 모든 요청은 독립적입니다. 클라이언트는 필요한 모든 정보를 요청에 포함해야 합니다.

4. 캐시 가능(Cacheable)

응답은 캐시 가능해야 하며, HTTP 헤더를 통해 캐시 정책을 정의할 수 있습니다.

5.계층화(Layered System)

클라이언트와 서버 간에 중간 계층(예: 로드 밸런서, 프록시)이 추가될 수 있지만, 클라이언트는 이를 알 필요가 없습니다.

6. 표현(Representation)

자원은 JSON, XML, HTML 등 여러 형태로 클라이언트에게 전달될 수 있습니다. 자원의 상태는 이 표현을 통해 전달됩니다.

Restful api

REST와 RESTful은 웹 API 설계 및 구현에서 자주 언급되는 개념이다.

REST : Representational State Transfer

REST는 아키텍처 스타일(Architectural Style)입니다. 웹 서비스 설계의 원칙과 제약 조건을 정의하는 일종의 가이드라인으로, HTTP기반으로 표현하고 조작하는데 중점을 둔다.

여기서 아키텍쳐 스타일은 소프트웨어 시스템의 구조를 설계하기 위한 패턴이나 가이드라인을 의미한다.

RESTFUL 이란건 이런 REST한 아키텍쳐 스타일을 잘 적용한 것을 뜻하는 말이다.

한 서버에 2개를 배포하려니까 더 문제가 되는거같다.

하나하나 해결하기 위해 우선 swagger가 안들어가지는 문제를 해결하려고한다.

백엔드 주소로 들어갓는데

/swagger에 접속을 하니 정적파일이 안뜬다.

/admin에 들어가니 거기도 정적파일이 안뜬다.

/portainer에 들어가니 이건 외부 프로그램이라 그런지 잘뜬다.

그렇다면 어디 정적파일이 문제인거같은데..

swagger/    200    document    swagger    2.8 kB    13밀리초
swagger    200    document / 리디렉션    기타    (디스크 캐시)    대기 중
swagger-ui.css    404    stylesheet    swagger/:18    155 B    11밀리초
swagger-ui-bundle.js    404    script    swagger/:41    155 B    11밀리초
swagger-ui-standalone-preset.js    404    script    swagger/:42    155 B    15밀리초
insQ.min.js    404    script    swagger/:43    155 B    15밀리초
immutable.min.js    404    script    swagger/:44    155 B    15밀리초
swagger-ui-init.js    404    script    swagger/:45    155 B    23밀리초
contentscript.js    200    script    inject.js:82    4.9 kB    10밀리초
style.css    404    stylesheet    swagger/:17    155 B    13밀리초
contentscript.js    200    script    inject.js:82    4.8 kB    9밀리초

이런 문제가 보였는데

딱봐도 정적파일이 어디 있거나 없거나 하는 상황에 사이트에 접속하면 이 정적파일로 안내가 안되는 듯 했다.

그렇다면 확인할 문제는 몇개 있다.

정적파일은 있는가?

정적파일은 어디에 있는가?

정적파일이 잘 마운트 되고 있는가?

이렇게 확인을 하면 될 것 같았다.

정적파일은 있는가?

joo@liv:~$ docker exec -it liv_pro ls /app/staticfiles/drf-yasg
README          insQ.js      redoc-init.js  swagger-ui-dist
immutable.js      insQ.min.js  redoc-old      swagger-ui-init.js
immutable.min.js  redoc        style.css

있다. 우선 app에는 있다.

정적파일은 어디에 있는가?

위치를 보면 app/staticfiles에 있다. collectstatic이 잘된거같다.

정적파일은 잘 마운트 되고 있는가?

이 부분을 확인하려고 어떻게 할지 고민하다가 gamebox에서 파일을 마운트해서 배포하단걸 기억하고

nginx에 파일이 있는지 확인해보았다.

joo@livdocker exec -it ng01 ls /app/staticfiles/drf-yasgyasg
ls: /app/staticfiles/drf-yasg: No such file or directory

파일이 없다

맙소사

그러면 잘 컨테이너화 되서 nginx에 저 파일로 마운트를 시도했으나 그게 실패한거같다/

마운트 방법은?

당연히 docker compose로 가보자.

  - ./nginx.conf:/etc/nginx/nginx.conf
  - /etc/letsencrypt:/etc/letsencrypt
  - ./certbot:/var/www/certbot  # 인증서 발급을 위한 볼륨 추가
  - static_volume:/app/static
  - media_volume:/app/media

보면 static 파일로 마운트가 되고 있었다.

   - ./pyproject.toml:/app/pyproject.toml:ro
  - ./poetry.lock:/app/poetry.lock:ro
  - ./django:/app/django
  - /home/joo/back-end-coffee/django/logs:/home/joo/back-end-coffee/django/logs 
  - static_volume:/app/django/static
  - media_volume:/app/django/media

web에서도 보면 장고 스태틱 파일로 마운트 중이다.

이부분이 debug true일땐 문제가 없었지만 false일때 문제가 된 부분인듯하다.

이부분을 전부 staticfile로 수정해주니 문제가 해결되었다.