Django : Authentication system 1

외워야 할건 점점 늘어난다.. 나 주거~

---

Authentication (인증)

: 사용자가 자신이 누구인지 확인 (=신원 확인)

 

개발자가 User의 데이터를 직접 다루기 위해서는 custom이 필요하므로 accounts라는 app을 생성하여 직접 정의해야한다. 

이제는 자동적으로 app을 추가했을때 어떤 작업을 해야하는지는 모두 알 것이다

 

Custom User model로 대체하기

 

: django가 기본적으로 제공하는 User model이 아닌 직접 작성한 User model을 사용하기 위함

: User class를 대체하는 이유는 django 내부의 내장된 auth 앱의 User class를 사용했는데, 개발자가 직접 수정 불가

: Django는 새 프로젝트를 시작하는 경우 개발자 Custom User Model 설정을 강력히 권장

: 기본 User 모델과 동일하게 작동 하면서도 필요한 경우 맞춤 설정을 하기 위함

• : 개발자가 직접 작성하되 내장된 auth app에서 사용할 수 있는 것은 가져올 예정이다
• : 위의 사진에서 INSTALLED_APPS를 살펴보면 django.contrib.auth로 내장된 auth 앱을 확인할 수 있다
• auth.models의 AbstractUser 클래스를 상속 받아 User 클래스를 작성
• 기존 User 클래스 역시 AbstractUser를 상속받기 때문에 커스텀 User 클래스도 동일한 모습을 갖게 한다

이외 바꾸는 것은 없기 때문에 class 생성까지만 진행한다

 

• django 프로젝트가 사용하는 기본 User 모델을 우리가 작성한 User 모델로 지정해야한다
• User 모델은 프로젝트 단위로 지정되기 때문에 settings에서 바뀐 모델을 지정해줘야 한다 (수정 전 기본 값은 auth.User)

AUTH_USER_MODEL을 정의해줘야 한다

acounts앱의 User 모델을 할당해준다

AUTH_USER_MODEL

- > Django 프로젝트의 User를 나타내는데 사용하는 모델을 지정 

- > 프로젝트 중간에 AUTH_USER_MODEL을 변경할 수 없으므로 프로젝트 초기에 설정해줘야 하는 값

- > 이미 프로젝트가 진행되고 있을 경우 데이터베이스 초기화 후 진행

---

• admin site에 대체한 User 모델을 등록
• auth.User의 기본 모델이 아니기 때문에 등록을 명시해줘야 auth.User와 동일한 기능을 할 수 있다

auth의 admin으로부터 UserAdmin을 가져오고, accounts의 User 모델을 가져온다

User 테이블이 변화된 것을 확인할 수 있다

 

---

Login (로그인)

: Session을 Create 하는 과정

 

AuthenticationForm()

 

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

: built-in form은 Django 가 제공하는 Login Form 을 가져오는 것으로 accounts에서 Form을 만들 필요 없이 import 한다

차근차근 따라가면 된다. import 하는걸 외울 필요는 없다

runserver를 통해 accounts/login.html에 접속해보면 깔끔한 로그인 페이지를 확인할 수 있다

 

html에는 form을 호출만 했는데도 설정하지 않았던 Username, Password, 입력칸이 모두 생성되어 있는 것은 불러온 Form인 AuthenticationForm의 내부를 확인해보면 알 수 있다.

위의 view함수에서는 아직 GET 요청만 해결하는 부분만 작성했기 때문에 POST 요청도 마무리해보자

새로운 개념이 많으니 잘 따라가자

 

login(request, user), get_user()

 

login(request, user) : AuthenticationForm을 통해 인증된 사용자를 로그인 하는 함수

 

get_user() : AuthenticationForm의 인스턴스 메서드로 유효성 검사를 통과했을 경우 로그인 한 사용자 객체를 반환한다

get_user()에 대한 함수를 AuthenticationForm 함수 내부에 정의되어있는 것을 확인할 수 있다

 

 

로그인이 되었는지 확인하는 방법은 총 2가지가 있다.

• Database 중 session 데이터를 확인
• 개발자 도구에서 Cookies의 정보를 확인

DB에서 세션 데이터 확인, session_key는 개발자 도구에서 Value 값에 해당된다

---

Logout (로그아웃)

: Session을 Delete 하는 과정

- > logout(request)

: Login과 반대로 현재 요청에 대한 Session Data를 DB에서 삭제, 클라이언트 쿠키에서도 Session ID를 삭제하는 과정

Delete는 항상 쉽다. csrf_token과 logout 함수를 import 해주는 것만 잊지 말자!

 

로그아웃을 진행하면 Cookies에서 삭제되고, Database에서도 Sessions가 없어져있는 것을 확인할 수 있다.

 

 

+ 템플릿과 인증 데이터 (Template with Authentication data)

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

 

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

 

: user 라는 context 데이터를 사용할 수 있는 이유는 django가 미리 준비한 context 데이터(context processors)가 존재하기 때문이다

 

context로 user를 명시해서 넘겨주지 않아도 데이터를 사용할 수 있는 모습

settings.py에서 context_processors를 살펴보면 request와 auth가 있는 것을 확인할 수 있다

• 템플릿이 렌더링 될 때 호출 가능한 context 데이터 목록
• 작성된 context 데이터는 기본적으로 템플릿에서 사용 가능한 변수로 포함된다
• django에서 자주 사용하는 데이터 목록을 미리 템플릿에 로드해두었기 때문에 별다른 작업 없이 사용이 가능하다

---

+ 부록

User 모델 상속 관계

 

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

상위 개념인 Class AbstractBaseUser을 직접 상속 받지 않는 이유는 개발자가 필요로하는 중요한 구성을 AbstractUser에 묶어두었기 때문에 고도의 커스터마이징이 필요하지 않다면 간단하고 효율적인 Class를 선택하여 상속받는 것

---

User Model을 직접 커스텀해보면서 Login과 Logout을 구현하니 웹에 대해 10%는 이해한 것 같다. 아직 갈길은 멀었지만 점점 눈에 보이는 것이 많아지니 흥미도 더 생기는 것 같구나.. 조금만 더 열심히 하자