Authentication

User Registration

• Password provision and confirmation

  • Define additional columns in UserCreationForm

  • Check if they match in save logic

• Encrypted password storage

  • User.objects.create_user(username, email=None, password=None)

  • user.set_password(password)

Login

Is the user a logged in person?

Stateless & Connectionless

• Each request is an independent event

  • cookie connects this!

User Object

from django.contrib.auth.models import User

• 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

User Model

Primary attributes of default user

• username

• password

• email

• first_name

• last_name

Creating Users

from django.contrib.auth.models import User
user = User.objects.create_user('chloe', '[e-mail]', 'password-goes-here')

# At this point, user is a User object that has already been saved to the database. 

# You can continue to change its attributes, if you want to change other fields.
user.last_name = 'kim'
user.save()

Changing Password

1. Using command line

$ python manage.py changepassword haha
Changing password for user 'haha'
Password: 
Password (again): 

2. Using set_password()

In [6]: ha = User.objects.get(username='haha')                                                                  

In [7]: ha                                                                                                      
Out[7]: <User: haha>

In [8]: ha.set_password('dkgkgkgk')                                                                             
In [9]: ha.save()             

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

from django.contrib.auth import authenticate
user = authenticate(username='chloe', password='dkgkgkgk')
if user is not None:
    # A backend authenticated the credentials
else:
    # No backend authenticated the credentials

Shopping Cart

1. User ---> Shopping Cart ---> Coupang

2. User <--- Cookie <--- Coupang

• Shopping Cart == cookie

• Purchase History == data

Login == create

Logout == delete

Login Form

from django.contrib.auth.forms import UserCreationForm, AuthenticationForm

• AuthenticationForm is not a ModelForm but just a Form!

Login Function

from django.contrib.auth import get_user_model, login

def signin(request):
    if request.method == 'POST':
        # Value sent by user -> form
        form = AuthenticationForm(request, request.POST)
        # Validation
        # -> Login when validation is complete
        if form.is_valid():
            login(request, form.get_user())
            return redirect('accounts:index')
    else:    
        form = AuthenticationForm()
    context = {
        'form':form 
    }
    return render(request, 'accounts/signin.html', context)

• Filter POST first with the first if to handle else statement smoothly

  • why?

    • If you filter GET first, when POST doesn't pass .is_valid() and falls to else, you have to write code to render again!

    • That is, use POST first for code economy!

+

Reason for branching POST first

1. Code conciseness

2. REST API support

• Currently we only support GET & POST, but when configuring methods RESTfully later, multiple methods like GET/POST/PUT/DELETE will come, and handling GET method at the end allows for the most concise code configuration!

Message Framework

new

-> Post writing page (form)

create

-> Save to DB

-> render

-> redirect(success status)

-> redirect('articles:index')

HTTP is a repetition of request and response!

HTTP

• stateless

  • Once a request is sent, the state (past) cannot be known

  • All requests & responses are one-time

  • HTTP is a disconnected protocol

• connectionless

Message Framework

• It's meaningful to pass the previous state to the next Request & Response

  • Fallback Storage

    • If Cookie doesn't work, use Session

Dynamic view

Article CRUD

• title, content, created_at, updated_at

User CRUD (Manual < Django)

+

• in memory cache -> Think of it as cache loaded into ram

  • memcached

  • redis

• Google ad ID......gdpr

• macaddress = device information