devjingood 님의 블로그

Django

• 웹과 서버를 연결하는 강력한 프레임워크
• 주로 서버 사이드 렌더링 방식을 통해 HTML 페이지 반환
• 통신 방식
  • HTTP 요청 수신:
    • 클라이언트(주로 웹 브라우저)에서 HTTP 요청을 서버로 전송
  • URL 라우팅:
    • urls.py 파일을 통해 요청된 URL을 적절한 뷰(view) 함수나 클래스에 매핑
  • 뷰 처리:
    • 매핑된 뷰 함수가 요청을 처리.
    • 뷰 함수는 데이터베이스와 상호작용하고, 템플릿 엔진을 사용하여 HTML을 렌더링
  • 응답 반환:
    • 뷰 함수는 HTML, JSON, XML 등 적절한 형식의 응답을 생성하여 클라이언트에 반환
    • Django는 주로 서버 사이드 렌더링된 HTML 페이지를 반환

DRF

• RESTful API를 쉽게 구축할 수 있는 프레임워크
• 주로 JSON 형식의 데이터를 반환하여 RESTful API 개발에 특화
• 통신 방식
  • HTTP 요청 수신:
    • 클라이언트(주로 웹 애플리케이션 또는 모바일 앱)에서 HTTP 요청을 서버로 전송
  • URL 라우팅:
    • urls.py 파일을 통해 요청된 URL을 적절한 뷰셋(viewset)에 매핑
    • DRF는 DefaultRouter를 사용하여 라우팅을 간편하게 설정할 수 있다.
  • 뷰셋 처리:
    • 매핑된 뷰셋이 요청을 처리
    • 뷰셋은 데이터베이스와 상호작용하고, 시리얼라이저(serializer)를 사용하여
      데이터를 JSON 또는 XML 형식으로 변환
  • 응답 반환:
    • 뷰셋은 JSON, XML 등 적절한 형식의 응답을 생성하여 클라이언트에 반환
    • DRF는 주로 RESTful API의 특성에 맞춰 JSON 형식의 데이터를 반환

우리는 웹 뿐만 아니라 모바일 App에서 JSON 통신을 사용하기 위해 DRF 사용

1. 역할과 책임

• 프론트엔드: 사용자와 직접 상호작용하는 부분, 주로 웹 브라우저나 모바일 앱에서 실행,
  UI를 담당, 데이터를 표시하고 사용자 입력을 받아 서버로 전송
• 백엔드: 서버 측에서 실행, 데이터베이스와의 상호작용, 비즈니스 로직 처리, API 관리 등을 담당,
  클라이언트 요청을 처리하고 적절한 응답을 반환

2. 보안

• 프론트엔드:
  • 브라우저 또는 앱에서 실행되므로 코드가 노출될 수 있다.
  • 민감한 정보는 프론트엔드에서 직접 처리하지 않도록 해야 함
  • 인증 토큰 또는 API 키를 노출하지 않도록 해야 함
• 백엔드:
  • 서버에서 실행되므로 코드가 노출되지 않는다.
  • 데이터베이스와의 직접 연결, 비즈니스 로직 실행 등 민감한 작업을 안전하게 처리할 수 있다.
  • 사용자 인증 및 권한 부여와 같은 보안 기능을 구현

3. API 호출 위치

• 프론트엔드:
  • 주로 RESTful API나 GraphQL API를 통해 백엔드와 통신
    • Whateversong에서는 DRF를 통한 RESTful API 통신을 사용
    • RESTful API 및 API 통신 Method 설명 링크
  • AJAX 요청, Fetch API, Axios 등 다양한 방법을 사용하여 API를 호출
    • Whateversong에서는 바닐라 JS를 사용하고, Axios 라이브러리를 이용해서
      API를 호출
  • 사용자 입력을 받아 서버로 전송, 서버 응답을 받아 UI를 업데이트
• 백엔드:
  • 다른 마이크로서비스 또는 외부 서비스와 통신하기 위해 API를 호출
    • Whateversong에서는 Spotify의 API를 호출하여 Playlist 데이터를 가져옴
  • 서버 간 통신이기 때문에 더 높은 빈도의 호출이나 더 큰 데이터 양을 처리
  • 백엔드 간 API 호출은 프론트엔드에서 직접 접근할 수 없는 데이터나 기능을 사용할 때 유용

4. 데이터 처리

• 프론트엔드:
  • 서버로부터 받은 데이터를 화면에 표시하거나, 사용자 입력 데이터를 서버로 전송
  • 데이터 검증을 할 수 있지만, 최종 검증은 백엔드에서 이루어져야 함

// posts/create.js
function validateImage(file) {
            const validTypes = ['image/jpeg', 'image/png', 'image/gif'];
            return validTypes.includes(file.type);

Whateversong에서는 Post Create 시 image 파일의 형식을 프론트에서 먼저 검증을 함

• 백엔드:
  • 데이터를 받아 비즈니스 로직을 처리하고, 데이터베이스에 저장하거나 다른 서비스로 전송
  • 데이터 검증, 변환, 조작 등을 수행

5. 성능

• 프론트엔드:
  • 사용자 경험을 최적화하기 위해 빠른 응답 시간이 중요
  • API 호출 시 비동기 처리를 통해 UI가 멈추지 않도록 해야 함
    • Whateversong에서는 Axios 라이브러리를 이용하여 비동기 처리, 자세한 설명은링크
• 백엔드:
  • 다수의 클라이언트 요청을 효율적으로 처리하기 위해 고성능 요구
  • API 호출을 최적화하여 서버 자원을 효율적으로 사용해야 함

RESTful API의 정의 및 원칙

1. 자원(리소스) 기반 구조:
   • 모든 데이터는 "자원"으로 간주,
     각각의 자원은 고유한 URI(Uniform Resource Identifier)를 가짐
2. 표현(Representation):
   • 클라이언트와 서버 간의 데이터 교환은 자원의 표현으로 이루어짐
   • 자원의 표현은 일반적으로 JSON 또는 XML 형식을 사용
3. 상태 비저장성(Stateless):
   • 모든 요청은 독립적이며, 각 요청에는 필요한 모든 정보가 포함되어 있어야 함
   • 서버는 클라이언트의 이전 요청 상태를 저장하지 않는다.
4. HTTP 메서드:
   • RESTful API는 HTTP 메서드를 사용하여 자원에 대한 작업을 정의
   • 주요 HTTP 메서드:
     • GET: 자원을 조회
     • POST: 새로운 자원을 생성
     • PUT: 기존 자원을 변경
     • DELETE: 자원을 삭제
     • PATCH: 자원의 일부를 변경
5. 유형성(Uniform Interface):
   • 일관된 인터페이스를 제공하여 클라이언트와 서버 간의 상호 작용을 단순화
   • 자원 URI, HTTP 메서드, HTTP 상태 코드 등을 일관되게 사용
6. 캐시 가능성(Cacheability):
   • 응답은 캐시될 수 있어야 하며, 캐시 가능 여부를 명시하는 메타데이터를 포함해야 함
7. 계층화 시스템(Layered System):
   • 클라이언트는 중개 서버를 통해 여러 계층으로 구성된 시스템과 상호작용할 수 있다.
   • 이를 통해 시스템의 보안 및 확장성을 향상
8. 코드 온 디맨드(Code on Demand) (선택 사항):
   • 서버는 클라이언트에 스크립트를 전송하여 실행할 수 있다.
   • 이는 선택 사항이며, RESTful API에서 반드시 구현해야 하는 요소는 아니다.

Session Login과 JWT Token 로그인 차이점

무상태성(Stateless)

비 연결적인 특성으로 연결이 해제됨과 동시에 서버와 클라이언트는 클라이언트가 이전에 요청한 결과에 대해 잊어버리게 된다. 따라서 요청을 할 때마다 서버에 연결을 해야한다.

HTTP의 이러한 특성으로 인해 'Stateless Protocol'이라고 불리기도 하며 웹사이트는 매 페이지에서 로그인이 되어있는 상태인지 확인하는 로그인 인증 방식이 필요하다.

Session Login

Session: 방문자가 웹서버에 접속해 있는 상태를 하나의 단위로 보는 것
웹서버는 이러한 각 단위에 세션 Id를 부여하고 같은 브라우저인지 구별
브라우저를 닫거나 서버에서 이 (세션 Id가 들어있는)쿠키를 삭제 했을 때 삭제
session을 사용한다고 해서 cookie를 안쓰는 것은 아님.
다만, cookie가 탈취 되더라도 의미없는 문자열인 세션 Id가 들어있다.

Session Login 방식

1. 클라이언트가 서버에게 로그인 정보가 들어있는 파라미터와 함께 login을 요청
2. 서버에서 login 인증을 하고 정보가 올바르면 세션 객체를 생성하고
   세션 Id를 Set-cookie를 통해 클라이언트에게 전달
3. 세션 객체는 서버에 저장
4. 클라이언트가 서버에 작업을 요청할 때 요청 헤더에 세션 Id가 담긴 쿠키 전달
5. 서버에서는 클라이언트로부터 받은 쿠키에 세션 Id를 확인해서 세션 객체를 검색하고 정보가 있으면 요청한 작업에 대해 응답해주고 통신을 종료

장점

• 쿠키방식과 동일하지만 아무런 의미가 없는 세션 Id가 저장이 되므로 탈취되더라도 해석할 수 없다.

단점

• 해커가 중간에 가로채서 훔친 쿠키로 HTTP 요청을 보낼 수 있는 하이재킹 공격을 당할 수 있다.

해결법
(1) HTTPS를 사용해 요청 자체를 탈취해도 안의 정보를 읽기 힘들게 한다.
(2) 세션에 유효시간을 넣어 유효시간이 끝나면 더이상 해커가 이용할 수 없게 한다.

• 서버에 세션 객체를 저장해놓기 때문에 사용자가 다수일 경우 부하가 높아진다.

• 확장 시 모든 서버가 접근할 수 있도록 별도의 중앙 세션 관리 시스템이 필요하다.

• 확장성이 좋지 않다. (여러 대의 서버 컴퓨터를 추가할 경우 각 서버마다 세선 정보가 저장되기 때문에)

• CORS: 웹 어플리케이션에서 세션을 관리할 때 자주 사용되는 쿠키는 단일 도메인 및
서브 도메인에서만 작동하도록 설계되어 있다. 따라서 쿠키를 여러 도메인에서 관리하는 것은 번거롭다.

JWT Login

JWT: JSON Web Token, 전자 서명 된 URL-safe (URL로 이용할 수 있는 문자)의 JSON

JWT Login 방식

1. 사용자가 id와 password를 입력하여 로그인을 시도

2. 서버는 요청을 확인하고 secret key를 통해 Access token을 발급

3. JWT 토큰을 클라이언트에 전달

4. 클라이언트에서 API를 요청할때 클라이언트가 Authorization header에 Access token을
담아서 보냄

5. 서버는 JWT Signature를 체크하고 Payload로부터 사용자 정보를 확인해 데이터를 반환
(JWT는 Header, Payload, Signature로 나뉘어짐)
Header, Payload, Signature 간단한 설명은 이 링크에

1. 클라이언트의 로그인 정보를 서버 메모리에 저장하지 않기 때문에 토큰 기반 인증 메커니즘을 제공

장점

• 사용자 인증에 필요한 모든 정보는 토큰 자체에 포함하기 때문에 별도의 인증 저장소가 필요없다.
• 서버에 상태를 저장하지 않기 때문에 무상태(stateless)로 동작하며, 확장성과 성능이 좋다.

단점

• 토큰이 클라이언트에 저장되므로, 탈취되었을 때 보안 문제가 발생
• 서버에서 토큰을 강제로 무효화하기 어려움

JWT와 Session을 같이 사용하는 경우

민감한 작업(계정 설정 변경, 비밀번호 변경 등) - Session 인증을 사용하여 추가적인 보안

일반적인 작업(게시글 조회, 댓글 작성 등) - JWT를 사용하여 빠른 응답과 확장성을 챙김

JWT를 사용하고, localStorage에 저장한 이유

모바일에 더 용이한 방식

1. 무상태: 모바일 App은 주로 API 서버와 통신하는데, JWT 로그인은 무상태(stateless) 인증
   방식이기 때문에 서버 확장성이 높고, 서버 부하가 적다.
2. 오프라인 지원: JWT는 자체적으로 정보를 포함하고 있어 인터넷 연결이 불안정한 모바일
   환경에서도 일정 시간 동안 유효성을 유지할 수 있다.
3. localStorage: 모바일 App의 localStorage는 브라우저의 저장하는 웹과 다르게, App의 사유
   디렉토리에 저장되어 다른 App이나 사용자의 의해 접근이 어렵고, 보안성이 높다.
4. 보안: 운영 체제의 샌드박스 보안 모델 덕분에 다른 App으로부터 격리, 이를 통해 데이터의 안전성 보장

따라서, 모바일 App까지 확장을 생각했기에 우리는 JWT 로그인 방식과, localStorage 저장 방식을 선택했다.

Trouble

localStorage에 저장한 정보를 탈취 당해 다른 회원의 아이디를 임의로 사용하거나 변경한 이력 발생

--> 고안해낸 해결 방법

로그인 시 localStorage에 정보를 저장할 때, 정보를 암호화해서 저장,

localStorage에 저장하여 사용했던 정보들을, 서버 측에서 제공해서 사용하는 방식으로 변경

적용은 하지 않음, 고안만 했음