Skip to content

Latest commit

 

History

History
279 lines (177 loc) · 5.18 KB

File metadata and controls

279 lines (177 loc) · 5.18 KB

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

User Object Hierarchy


  • 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', 'email-address@gmail.com', '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