Authentication
회원 가입
비밀번호 제공 및 확인
UserCreateionForm
추가 column 정의저장 logic에서 일치하는지 확인
비밀번호 암호화 저장
User.objects.create_user(username, email=None, password=None)
user.set_password(password)
로그인
사용자가 로그인 한 사람이다?
Stateless & Connectless
매 요청이 독립 사건
cookie
가 이걸 이어준다!
User Object
core of the authentication system
'superusers'
or admin'staff'
users are just user objects with special attributes set, not different classes of user objects
AbstractBaseUser
AbstractUser
User

Primary attributes of default user
username
password
email
first_name
last_name
Creating Users
Changing Password
1. Using command line
2. Using set_password()
set_password()
Authenticating Users
authenticate(request=None, **credentials)
use it to verify a set of credentials
takes credentials as keyword arguments
username and password for the default cases
returns
User
object if credentials are valid for a backend
장바구니
사용자 ---> 장바구니 ---> 쿠팡
사용자 <--- 쿠키 <--- 쿠팡
장바구니 ==
cookie
구매내역 ==
data
로그인 == create
로그아웃 == delete
로그인 Form
AutehticationForm
은 ModelForm 이 아니라 그냥 Form 이다!
로그인 함수
else
문 처리를 매끄럽게 하기 위해 첫번째if
로 POST를 먼저 거른다why?
만약 GET을 먼저 거르면, POST에서
.is_valid()
에 걸리지 않고else
로 떨어지면 다시 render하는 코드 써줘야해서!즉, *code의 경제성을 위해 POST 를 먼저 쓴다!
+
POST
로 먼저 분기하는 이유
POST
로 먼저 분기하는 이유코드의 간결성
REST API 대응
현재 우리는 GET & POST만 대응하고 있는데 이후에 RESTful 하게 메소드 구성할 경우 GET/POST/PUT/DELETE 여러개의 메소드가 오게 되고 GET method가 마지막에에 핸들링되는 형태가 가장 간결한 코드 구성이 가능!
Message Framework
new
-> 글 작성 페이지 (form)
create
-> DB에저장
-> render
-> redirect(성공여부)
-> redirect('articles:index')
HTTP는 request와 response의 반복이다!
HTTP
stateless (무 상태성)
한번 요청을 보내면 상태(과거)를 알 수 없음
모든 요청 & 응답은 일회성이다
HTTP는 단절적인 protocol
connectionless (무 연결성)
Message Framework
이전의 상태를 다음
Request
&Response
에 넘겨준다는 것이 의미가 있다Fallback Storage
Cookie 가 안되면 Session
Dynamic view
Article CRUD
title, content, create_at, updated_at
User CRUD (직접 < Django)
+
in memory cache -> ram에 띄워놓는 cache라고 생각하면 됨
memcached
redis
구글 광고 아이디......gdpr
macaddress = 기기정보
Last updated
Was this helpful?