Django : Authentication system

우리가 평소에 웹 페이지를 둘러볼 때 우리는 서버와 연결되어 있는 상태가 아니다.

웹 문서를 요청하고 받을 때만 잠시 연결되고 요청받은 것을 응답하면서 서버는 바로 연결을 끊는다.

 

• HTTP

HTML 문서와 같은 리소스들을 가져올 수 있도록 해주는 규약

→ 웹(WWW)에서 이루어지는 모든 데이터 교환의 기초

 

• HTTP 특징

비 연결 지향 : 서버는 요청에 대한 응답을 보낸 후 연결을 끊는다.

무상태 : 연결을 끊는 순간 클라이언트와 서버 간의 통신이 끝나며 상태 정보가 유지되지 않는다.

→ 상태가 없다는 것 ex) 장바구니에 담은 상품이 없어짐, 로그인이 유지되지 않음

 

• 쿠키

서버가 사용자의 웹 브라우저에 전송하는 작은 데이터 조각

→ 클라이언트 측에서 저장되는 작은 데이터 파일이며, 사용자 인증, 추적, 상태 유지 등에 사용되는 데이터 저장 방식이다.

 

다음 요청을 보낼 때 같이 보내라고 주는 것!

서버로부터 쿠키를 받으면 같은 서버에 다른 페이지로 재요청시마다 저장해 놓았던 쿠키를 함께 전송한다.

 

HTTP는 상태를 저장할 수 없기에 클라이언트가 서버에 요청할 때마다 쿠키를 통해 사용자가 로그인했다는 사실을 계속 보내는 것이다. 쿠키가 상태를 유지 or 형성해주는 셈이다.

 

• 쿠키 사용 원리

1. 브라우저(클라이언트)는 쿠키를 KEY-VALUE 데이터 형식으로 저장
2. 쿠키를 저장해 놓았다가 동일한 서버에 재요청 시 저장된 쿠키를 함께 전송

→ 쿠키는 두 요청이 동일한 브라우저에서 들어왔는지 판단할 때 주로 사용된다. 이를 통해 사용자의 로그인 상태를 유지할 수 있다.

 

• 쿠키 사용 목적

1. 세션 관리
로그인, 아이디 자동완성, 공지 하루 안 보기, 팝업 체크, 장바구니 등의 정보 관리

2. 개인화
사용자 선호, 테마 등의 설정

3. 트래킹
사용자 행동을 기록 및 분석 (시크릿 모드는 이러한 추적 쿠키를 생성하지 않는 것)

 

• 세션

서버 측에서 생성되어 클라이언트와 서버 간의 상태를 유지한다.

상태 정보를 저장하는 데이터 저장 방식

 

• 세션 작동 원리

1. 클라이언트가 로그인을 하면 서버가 session 데이터를 생성 후 저장
2. 생성된 session 데이터에 인증할 수 있는 session id를 발급
3. 발급한 session id를 클라이언트에게 응답
4. 클라이언트는 응답받은 session id를 쿠키에 저장
5. 클라이언트가 다시 동일한 서버에 접속하면 요청과 함께 session id가 저장된 쿠키를 서버에 전달
6. 쿠키는 요청 때마다 서버에 함께 전송되므로 서버에서 session id를 확인해 로그인 되어있다는 것을 알도록 함.

 

• 로그인이 이루어지고 유지되는 원리

⇒ 서버 측에서는 세션 데이터를 생성 후 저장하고 이 데이터에 접근할 수 있는 세션 ID를 생성한다.

이 ID를 클라이언트 측으로 전달하고, 클라이언트는 쿠키에 이 ID를 저장한다.

 

• 쿠키와 세션의 목적 : 서버와 클라이언트 간의 ‘상태’를 유지하는 것

 

• 쿠키 종류별 수명

1. Session cookie
현재 세션이 종료되면 삭제된다.
브라우저 종료와 함께 세션이 삭제된다.

2. Persistent cookies
Expires 속성에 지정된 날짜 혹은 Max-Age 속성에 지정된 기간이 지나면 삭제된다.

 

• Authentication (인증) : 사용자가 자신이 누구인지 확인하는 것 (신원 확인)

 

• Custom User model

django가 기본적으로 제공하는 User model이 아닌 직접 작성한 모델을 사용하기 위해 Custom User model로 대체할 수 있다.

User 클래스를 대체하는 이유 → 별도의 User 클래스 정의 없이 내장된 auth 앱에 작성된 User 클래스를 사용할 수 있지만, 개발자가 클래스를 수정할 수 없는 문제가 존재한다.

 

• AUTH_USER_MODEL = Django 프로젝트의 User를 나타내는 데 사용하는 모델

 

주의 : 프로젝트 중간에 AUTH_USER_MODEL 을 변경할 수 없다!

이미 auth User 가 설정되었고 DB가 만들어지면서 수많은 User 의존성 알고리즘, 시스템이 만들어져있기에!

그래서 인증시스템을 나중에 만들더라도 무조건 User 대체하기를 첫 Migrate 이전에 먼저 하고 시작해야한다.

중간에 바꿀 경우 데이터베이스를 초기화하고 진행한다.

 

⇒ 프로젝트를 시작하며 반드시 User 모델을 대체해야 한다.

기본 User 모델이 충분하더라도 커스텀 모델을 설정하면 기본 모델과 동일하게 작동하면서도 필요할 때 맞춤 설정할 수 있기 때문이다.

 

• Login : Session을 Create하는 과정

 

• AuthenticationForm( )

로그인 인증에 사용할 데이터를 입력 받는 built-in form

ModelForm 이 아니라 그냥 폼으로 받고 있다.

사용자가 입력하는 데이터를 직접 DB에 저장하기 않기 때문이다!

이 데이터를 사용해서 세션 데이터를 만들고 그 데이터를 저장할 예정

 

• login(request, user)

AuthenticationForm을 통해 인증된 사용자를 로그인 하는 함수

보통 view 함수 이름과 겹쳐서 이름을 다른 것으로 바꿔 import 한다.

from django.contrib.auth import login as auth_login

# Create your views here.
def login(request):
    if request.method == 'POST':
        form = AuthenticationForm(request, request.POST)
        if form.is_valid():
            auth_login(request, form.get_user())
            return redirect('articles:index')

 

• get_user( )

AuthenticationForm의 인스턴스 메서드

유효성 검사를 통과했을 경우 로그인한 사용자 객체를 반환한다.

 

• Logout : Session을 Delete하는 과정

 

• logout(request)

현재 요청에 대한 Session Data를 DB에서 삭제한다.

클라이언트의 쿠키에서도 Session Id를 삭제한다.

 

• Template with Authentication data

템플릿에서 인증 관련 데이터를 출력하는 방법

현재 로그인 되어있는 유저 정보 출력하기

→ django가 미리 준비한 context 데이터가 존재하기 때문에 view 함수에서 넘겨받지 않고도 user 라는 context 데이터를 사용할 수 있다.

 

• context processors

템플릿이 렌더링 될 때 호출 가능한 context 데이터 목록

작성된 context 데이터는 기본적으로 템플릿에서 사용 가능한 변수로 포함된다.

django 에서 자주 사용하는 데이터 목록을 미리 템플릿에 로드해둔 것

 

• ‘ AbstractUser ‘ class

관리자 권한과 함께 완전한 기능을 가지고 있는 User model을 구현하는 추상 기본클래스

 

• Abstract base classes (추상 기본 클래스)

몇 가지 공통 정보를 여러 다른 모델에 넣을 때 사용하는 클래스

데이터베이스 테이블을 만드는 데 사용되지 않으며, 대신 다른 모델의 기본 클래스로 사용되는 경우 해당 필드가 하위 클래스의 필드에 추가된다.