2022. 11. 14. 20:28ㆍ스파르타코딩(22.8.29~22.12.31)/TIL(Today I Learned)
- Today I Learned
- 장고가 제공해주는 인증의 기능이 담긴 Tutorial을 하며
User 모델을 알아보려고 한다.
모델링을 공부하려고 하는데 컨셉을 웹페이지로 생각하니
각 모델의 연관성을 생각해보니 지을게 생각이 떠오르지 않았다.
공부하려고 하는 웹의 기획자체가 유저(User)가 돌아다니면서 게시판,댓글 팔로우 등
여러 모델의 흐름을 만들어주는 주체라고 생각되어
장고가 제공해주는 인증의 기능이 담긴 User 모델부터 알아보려고 한다.
User Model Tutorial 시작 더보기 ↓
이전에 DRF APIVIEW를 공부하면서 DRF는 장고를 기반하여 기능을 추가한것으로 확인했었다.
당연히 장고를 별도로 설치를 안해도 설치가 되겠지? 라고 생각했다
역시나 예상했다
DRF가 기반으로 하는 패키지들이 같이 설치되었다.
물론 위에 보이듯 장고 또한 포함^^
그외는 DRF,Django에서 필요한 기본 패키지같다. 내눈엔 sqlparse가 왜 눈에들어오는지
참다못해 검색해보았다..
하나의 패키지에 모든게 들어가 있는게 아닌 패키지로 나누고 기능별로 build up(*쌓아올리다) 한것같다.
이 녀석들 이제 어떻게 만드는지 감이 조금 오는것같다. 하나씩 하나씩 추가하고 분류한 느낌
자 이제 프로젝트를 만들어보자. 음.. 이름은 모델을 테스트하는 프로젝트니까
model_test(project)?가 좋을것 같다. 아님말고..
끝에 . 을붙여줘야 해당 프로젝트 폴더내에 만든다.(아니면 별도의 폴더를 생성한다.)
model_test 앱에서 생성해도되나(*app : 안드로이드의 어플이 아니라 기능 단위를 app이라고 한다.)
기능적으로 구분을 위해 새로운 앱을 하나 만들어준다.
복수의 회원을 담을예정이니 users라고 만든다.
장고는 바보기 때문에 인식을 못하니 새로운 app끼리 연결해줘야 한다.
settings.py에서 INSTALLED_APPS에 "users" 추가 끝에 쉼표,꼭 확인
안적으면 후에 후에 앱을 생성한다면 추가앱이 인식을 못한다.끝단에는 안적어도 된다고 알고 있지만 적어도 무방하니 붙여주는 습관을 기르자.
이제 경로를 적어서 이어주자.main project(model_test)의 urls.py에서 포함하는 기능을 담고있는 include(포함하다)를import 해준 후 경로를 추가해준다.
이렇게 해주면 users앱은 model_test에 귀속(?),포함,연결된다. 경로는 별도로 지정하지 않았다.
여기까지하고..잠깐 멍때렸다 뭐..하지?
모델을 만들기 전 User모델을 참조하는 설정을 해줘야한다
위의 내용을 읽어보면 custom user는 바로 쓰지 않더라도 꺼내 놓고 시작하는 것을 강력 추천한다고 적혀 있다
*recommended(추천)
Django에서 권장하는 사용자 모델 참조 방법
여러방법이 있지만 크게 2가지 방법이 있다고한다.
- User 모델 참조하는 방법 # 1번째 (AUTH_USER_MODEL = 'users.User')
AUTH_USER_MODEL = '앱명.해당앱의 User클래스명'
AUTH_USER_MODEL = 'users.User'
*Auth = 인증
특징 : 외래키 모델을 전달할 때 문자열로 전달합니다.
외래키가 임포트될 때 모델 클래스 탐색에 실패하면 모든 앱이 로드될 때까지 실제 모델 클래스의 탐색을 미룹니다. 그렇기 때문에 항상 올바른 사용자 모델을 얻을 수 있습니다.
- User 모델 참조하는 방법 # 2번째 get_user_model()
get_user_model()는 객체 인스턴스를 리턴합니다.
특징 : Django 앱이 로드되는 그 순간에 실행되기 때문에 반드시
유효한 사용자 모델 객체를 리턴한다는 보장을 하지 않습니다.
None이 리턴될수도 있다.
INSTALLED_APPS가 변경되는 등 캐시에 있는 앱이 다시 로드되는 경우 문제가 생길 확률은 더 높아집니다.
앱의 변경사항이 생길경우 문제생길 소지가 있어 1번째 방법을 권장한다고 한다.
※ 주의사항
- 관리자페이지(admin)에 User model 등록하기
이제 Django에서 제공해주는 다양한 유저모델을 알아보자.
Django의 표준 유저 모델 구조와 종류
직전에 공부했던 다이아몬드 상속의 모습이 보인다.
위에서 다이어그램대로
User는
AbstractUser에 상속을 받고
AbstractUser는
각각 AbstractBaseUser 와 PermissionsMixim에 상속을 받고
AbstractBaseUser 와 PermissionsMixim는
django.db.models.Model에 상속을 받는다.
상속관계를 토대로 위의 장고에서 제공해주는 User 모델을 분류하자면 3가지 방법이 있다.
공식문서를 보면 프로젝트 시작할 때 커스텀 유저모델을 적극 권장한다고 한다.
기본 유저는 자유도가 낮고 커스텀이 어렵고 중간시점에서 변경이 어렵기 때문이다.
*recommended(추천)
이제 각 모델의 특징을 알아보자.
User 모델을 만드는 4가지 방법 (Django제공 User 외 one to one model 포함)
- One-to-One 특징
- 새로운 모델을 추가하여 기존 User 모델과 1:1 관계로 연결시켜 사용자 정보를 저장한다.
- 기존 User 모델과 관계됨으로서 auth(인증) 기능을 사용 할 수 있다.
- 프록시 방식에 비해 필드에 대한 자유도가 매우 높다.
- (튜터님께 현업에서는 django모델보다는 직접 one to one으로 모델링하는 경우가 있다고 들었다.)
- AbstractBaseUser 특징
- AbstractBaseUser 모델을 상속한 User 모델을 새로 정의하여 사용한다.
- 프로젝트 시작 전 준비 단계에서 사용되어져야 한다.
- 새로운 User 모델을 정의함에 따라 Settings.py 에 AUTH_USER_MODEL =’app이름.User’ 값을 추가해야 한다.
- 가장 많은 구현을 필요로 한다. (장고 제공 User중 자유도가 가장 좋다.)
- Django User 기법 중 가장 적은 필드가 포함되어 있다.
- 필수 필드로서 password 하나의 필드만 설정되어 있음 (별도의 name 이나 email을 고유로 지정해줘야함)
- AbstractUser 특징
- AbstractBaseUser 모델을 상속한 User 모델을 새로 정의하여 사용한다.
- 프로젝트 시작 전 준비 단계에서 사용되어져야 한다.
- 새로운 User 모델을 정의함에 따라 Settings.py 에 AUTH_USER_MODEL =’app이름.User’ 설정 값을 추가해야 한다.
- 서비스 규모에 따라 달라지겠지만 가장 일반적인 사용법이다.
- User (Proxy) Model 특징 (*proxy = 프로토콜에 있어서 대리응답이라는 뜻)
- 기존 User 모델을 직접 상속한다.
- Meta 클래스에서 proxy =True 속성을 추가한다.
- DB 스키마에 영향을 주지 않는다.
- 기존 User 모델에서 DB 스키마 외에 최소한의 변경사항만을 적용할 때 사용한다.
- 프로젝트 중간에 모델을 추가할 때 사용하기 좋아보인다.
- 모델 설계의 자유도가 가장 낮다.
- 자주 사용하는 방식은 아니다
이제 알아본 Django의 User모델이 갖고있는 field와 속성을 장고 문서를 통해 알아보자.
각각의 column에는 Django가 제공해주는 기능이 포함되어있다.
- AbstractBaseUser 모델 클래스(models.User) field와 속성
- password 필수 비밀번호의 해시 및 메타데이터입니다. (Django는 원시 암호를 저장하지 않습니다.)
- last_login 사용자의 마지막 로그인 날짜/시간입니다.
- 두개의 필드 밖에 없지만 인증기능이 담겨있다.(= 자유롭게 커스텀 할수있다.) 더보기↓
- AbstractUser 모델 클래스(models.User) field와 속성
- username 필수의. 150자 이하 사용자 이름에는 영숫자, , , _및 @문자 가 포함될 수 있습니다 .+.-
- first_name 선택 사항( blank=True). 150자 이하
- last_name 선택 사항( blank=True). 150자 이하
- email 선택 사항( blank=True). 이메일 주소.
- password 필수의. 비밀번호의 해시 및 메타데이터입니다. (Django는 원시 암호를 저장하지 않습니다.)
• groups 그룹에 대한 필드이다. 다대다 관계Group
(공식문서에서의 상속하는 User모델과 대조되는 부분)
• user_permissions 유저의 권한을 설정하는 필드 다대다 관계Permission
(공식문서에서의상속하는 User모델과 대조되는 부분)
• is_staff (boolean) 참이면 admin 사이트에 접속할 수 있다.
이 사용자가 관리 사이트에 액세스할 수 있는지 여부를 지정합니다.
• is_active (boolean) 이 사용자 계정을 활성으로 간주할지 여부를 지정합니다.
False 계정을 삭제하는 대신 이 플래그를 로 설정하는 것이 좋습니다.
이렇게 하면 애플리케이션에 사용자에 대한 외래 키가 있는 경우 외래 키가 손상되지 않습니다.
이것은 사용자가 로그인할 수 있는지 여부를 반드시 제어하는 것은 아닙니다.
인증 백엔드는 is_active 플래그를 확인하는 데 필요하지 않지만
기본 백엔드( ModelBackend) 및 RemoteUserBackend수행이 필요합니다.
비활성 사용자의 로그인을 허용 하려면 AllowAllUsersModelBackend 또는 를 사용할 수 있습니다
AllowAllUsersRemoteUserBackend이 경우 비활성 사용자를 거부하므로
AuthenticationForm에서 사용하는 를 사용자 정의할 수도 있습니다.
비활성 사용자 에 대해서는 Django 관리자의 인증 및 인증과 LoginView같은 권한 확인 방법이
모두 반환된다는 점에 유의하십시오 .has_perm()False
- is_superuser (boolean) 명시적으로 할당하지 않고 이 사용자가 모든 권한을 갖도록 지정합니다.
- last_login 사용자의 마지막 로그인 날짜/시간입니다.
• date_joined 계정이 생성된 시간을 지정하는 날짜/시간입니다.
계정 생성 시 기본적으로 현재 날짜/시간으로 설정됩니다.
- User모델 클래스(models.User) field와 속성
- username 필수의. 150자 이하 사용자 이름에는 영숫자, , , _및 @문자 가 포함될 수 있습니다 .+.-
- first_name 선택 사항( blank=True). 150자 이하
- last_name 선택 사항( blank=True). 150자 이하
- email 선택 사항( blank=True). 이메일 주소.
- password 필수의 비밀번호의 해시 및 메타데이터입니다. (Django는 원시 암호를 저장하지 않습니다.)
- groups 그룹에 대한 필드이다. 다대다 관계 Group
- user_permissions 유저의 권한을 설정하는 필드 다대다 관계 Permission
• is_staff (boolean) 참이면 admin 사이트에 접속할 수 있다.
이 사용자가 관리 사이트에 액세스할 수 있는지 여부를 지정합니다.
• is_active (boolean) 이 사용자 계정을 활성으로 간주할지 여부를 지정합니다.
False 계정을 삭제하는 대신 이 플래그를 로 설정하는 것이 좋습니다.
이렇게 하면 애플리케이션에 사용자에 대한 외래 키가 있는 경우 외래 키가 손상되지 않습니다.
이것은 사용자가 로그인할 수 있는지 여부를 반드시 제어하는 것은 아닙니다.
인증 백엔드는 is_active 플래그를 확인하는 데 필요하지 않지만
기본 백엔드( ModelBackend) 및 RemoteUserBackend수행이 필요합니다.
비활성 사용자의 로그인을 허용 하려면 AllowAllUsersModelBackend 또는 를 사용할 수 있습니다
AllowAllUsersRemoteUserBackend이 경우 비활성 사용자를 거부하므로
AuthenticationForm에서 사용하는 를 사용자 정의할 수도 있습니다.
비활성 사용자 에 대해서는 Django 관리자의 인증 및 인증과 LoginView같은 권한 확인 방법이
모두 반환된다는 점에 유의하십시오 .has_perm()False
- is_superuser (boolean) 명시적으로 할당하지 않고 이 사용자가 모든 권한을 갖도록 지정합니다.
- last_login 사용자의 마지막 로그인 날짜/시간입니다.
• date_joined 계정이 생성된 시간을 지정하는 날짜/시간입니다.
계정 생성 시 기본적으로 현재 날짜/시간으로 설정됩니다.
결론 : 사용해본 필드는 일부밖에 없지만 관련기능이 필요하다면
장고가 제공해주는 기능을 활용해보면 좋을것 같다.
장고에서 User모델의 종류와 속성에 대해 알아보았다.
처음 User모델을 사용했을땐 AbstractUser만 사용하고 구조나 다른방법에 대해 의문은 있었지만
자세하게 알아보지 않았었다.
속성들을 보면 비밀번호 해싱뿐만 아니라 마지막로그인 일시, 계정생성 날짜 , 계정비활성화
커스텀 및 인증 등
현재까지 장고에 대해 알아보면서 장고는 개발자가 사용자를 관리함에 있어서
꽤나 배려한 부분이 여럿 보인다고 생각했다.
참조 : [Django] User모델 커스터마이즈하기 (커스텀 User 모델)
참조 : 【Django】독자 사용자 모델의 작성 独自ユーザーモデルの作成（カスタムUserモデル：AbstractBaseUser）
참조 : Django에서 권장하는 사용자 모델 참조 방법
'스파르타코딩(22.8.29~22.12.31) > TIL(Today I Learned)' 카테고리의 다른 글
| [TIL] 관계형 Model (1 대 1,Many Field) 22/11/15 12일차 미완 (0) | 2022.11.17 |
|---|---|
| [TIL] Model Types형 Field와 속성에 대해 22/11/14 11일차 (0) | 2022.11.16 |
| [TIL] django.db.models.Model에 관하여 11/10 9일차 (0) | 2022.11.13 |
| [TIL] ORM과 객체,Class,instance에 대해 11/9 8일차 (0) | 2022.11.13 |
| [TIL] 강력한 기능 파이썬의 상속(Inheritance)에 대해 복습 11/8 7일차 (1) | 2022.11.11 |