mirror of
https://github.com/lemeow125/Notes.git
synced 2024-11-17 12:19:25 +08:00
232 lines
No EOL
11 KiB
Markdown
232 lines
No EOL
11 KiB
Markdown
### Authentication with Djoser
|
|
Django REST Framework provides basic authentication out of the box, provided with the defaults located in **INSTALLED_APPS** under `settings.py`
|
|
|
|
To build robust applications however, you will need to more functionality than what it offers;
|
|
- Registration
|
|
- Account Activation (with activation codes sent via email)
|
|
- Password Resets (also sent via email)
|
|
- Session expiry with JSON Web Tokens (so that you don't just stay logged in forever)
|
|
- and so on...
|
|
|
|
These features are not built in to DRF, and so we'll have to bring in another package or library for this, [Djoser](https://github.com/sunscrapers/djoser)
|
|
|
|
To start, run the command `pipenv install djoser djangorestframework-simplejwt`
|
|
|
|
|
|
Add **djoser** and **rest_framework_simplejwt** to **INSTALLED_APPS** under `settings.py`
|
|
|
|
|
|
|
|
You should also add the following code blocks to the end of your `settings.py`.
|
|
|
|
**REST_FRAMEWORK** will change the authentication type
|
|
|
|
**DJOSER** provides settings that you will use later on for user registration
|
|
|
|
```python
|
|
REST_FRAMEWORK = {
|
|
'DEFAULT_AUTHENTICATION_CLASSES': (
|
|
'rest_framework_simplejwt.authentication.JWTAuthentication',
|
|
),
|
|
}
|
|
|
|
DJOSER = {
|
|
'SEND_ACTIVATION_EMAIL': True,
|
|
'SEND_CONFIRMATION_EMAIL': True,
|
|
'ACTIVATION_URL': 'activation/{uid}/{token}',
|
|
}
|
|
```
|
|
|
|
|
|
|
|
Add the following to your **url_patterns** in `urls.py` file under the **api** app
|
|
|
|
```python
|
|
path('', include('djoser.urls')),
|
|
path('', include('djoser.urls.jwt'))
|
|
```
|
|
|
|
|
|
|
|
Next step, models!
|
|
|
|
### Note!
|
|
If you've gotten this far, congratulations! If you're not familiar with basic and intermediate SQL or Python exercises yet, you may have trouble catching up in the following sections. Please consider learning those first or alongside the sections below.
|
|
|
|
### User Model
|
|
We've added authentication (Djoser) and so we will need to create our own concept of a user.
|
|
|
|
Models are the heart of backend development (not just Django!). While you may know what a car or a person is, your backend (Django) and your database have no idea how this should be structured.
|
|
|
|
A person can have the following
|
|
|
|
- Name
|
|
- Age
|
|
- Birthday
|
|
|
|
Cars can have them too! But you get my point.
|
|
|
|
Django already provides a default [User](https://docs.djangoproject.com/en/5.1/ref/contrib/auth/) model, hidden away from sight. We will be overriding and replacing this with our own.
|
|
|
|
To start, we will need to create a separate app.
|
|
|
|
In the previous section, we created a simple folder for the **api** app, this will not work for this step.
|
|
|
|
Instead, make sure you're inside the Django project directory by doing `cd PROJECT_NAME`, in my case, `cd djangobackend`
|
|
|
|
We will then create an **accounts** app. Run the command `python manage.py startapp accounts`
|
|
|
|
This will create the **accounts** app
|
|
### Note!
|
|
The best practice when creating Django apps would be naming them in plural form (Books, Records, Posts)
|
|
|
|
The Books app can hold
|
|
- Books
|
|
- Pages
|
|
- Chapters
|
|
|
|
Because of this, there is usually no need to make another app for pages and chapters as mentioned above, unless your app is big enough.
|
|
|
|
With that out of the way, let's begin creating our User model.
|
|
|
|
We will be creating our own version of a User based on the default one provided by Django [here](https://docs.djangoproject.com/en/5.1/ref/contrib/auth/)with an age and a birthday
|
|
```python
|
|
from django.contrib.auth.models import AbstractUser
|
|
from django.db import models
|
|
|
|
class CustomUser(AbstractUser):
|
|
# Some fields are referenced or copied over from AbstractUser
|
|
# first_name, last_name, email, username, and password are among a few of these
|
|
|
|
birthday = models.DateTimeField(null=True)
|
|
age = models.IntegerField(null=True)
|
|
|
|
@property
|
|
def full_name(self):
|
|
return f"{self.first_name} {self.last_name}"
|
|
```
|
|
|
|
If we CTRL + Click on **AbstractUser**, we can take a deeper look under the hood on Django's default User
|
|
|
|
|
|
By referencing **AbstractUser** on the User we're creating, we're can skip over creating the other fields a user would have (password, email) and the work that comes with how those work under the hood. This is something you will regularly see with Django and will make developing projects faster.
|
|
|
|
We'll now need to connect our **accounts** app and the **User** model to our existing project
|
|
|
|
Open the `admin.py` file in the **accounts** app and add the following code block.
|
|
```python
|
|
from django.contrib import admin
|
|
from .models import CustomUser
|
|
|
|
# Register your models here.
|
|
admin.site.register(CustomUser)
|
|
```
|
|
|
|
|
|
|
|
This will register the model you just created into the Django admin panel (which you will look into later on).
|
|
|
|
You should then head over to your `settings.py` under the **config** app and add **accounts** to **INSTALLED_APPS**
|
|
|
|
|
|
Point your authentication to your new **User** model by adding this to `settings.py` under the **config** app
|
|
```python
|
|
AUTH_USER_MODEL = 'accounts.CustomUser'
|
|
```
|
|
|
|
|
|
|
|
Next, you will need to shuffle some things around
|
|
|
|
Head back to the **accounts** app and create a `urls.py` file. Add the following code block
|
|
```python
|
|
from django.urls import path, include
|
|
|
|
urlpatterns = [
|
|
path('', include('djoser.urls')),
|
|
path('', include('djoser.urls.jwt')),
|
|
]
|
|
```
|
|
|
|
You might notice that this is similar to what we have on the **api** app, we'll be moving these entries to here.
|
|
|
|
Now that we have those moved over, remove the entries for **djoser.urls** and **djoser.urls.jwt** in `urls.py` under the **api** app
|
|
```python
|
|
from django.contrib import admin
|
|
from django.urls import path, include
|
|
|
|
urlpatterns = [
|
|
path('admin/', admin.site.urls),
|
|
]
|
|
```
|
|
|
|
Instead, replace what we've removed with
|
|
```python
|
|
path('accounts/', include('accounts.urls')),
|
|
```
|
|
|
|
Things should look like this after
|
|
|
|
`urls.py` under **api** app
|
|
|
|
`urls.py` under **accounts** app
|
|
|
|
|
|
With this, your new **accounts** app is now connected.
|
|
|
|
### Migrations
|
|
Django and Django REST Framework (DRF) serves as an interface between your database (MySQL, PostgreSQL, SQLite) and the internet.
|
|
|
|
It **DOES NOT** hold your data. Rather, it serves as the **backend** to access said data.
|
|
|
|
|
|
|
|
This is an important distinction to make especially for starters. Exposing your database without a framework such as Django can allow malicious actors to easily make a mess of everything. Everything Django and DRF provides (authentication, middleware, etc.) serves this purpose.
|
|
|
|
Carrying on, migrations!
|
|
|
|
Migrations keep track of what types of kinds of things we wish to store. You previously created a **User** model **(accounts app)**.
|
|
|
|
To apply these changes to your database, run the command `python manage.py makemigrations`
|
|
|
|
### Note!
|
|
Make sure you're inside the Django project directory! (e.g. `cd PROJECT\_NAME`)
|
|
|
|
This will create a migration file for your **User** model, which will instruct Django on how to create it inside your SQL database.
|
|
|
|
Taking a closer look at the newly created migrations file, you can see the following file in `accounts/migrations/0001\_initial.py`
|
|
|
|
|
|
The previous command you just ran (`python manage.py makemigrations`) just translated your **User** model (located in `accounts/models.py`) into instructions which will then be used to create the SQL statements under the hood (e.g. `CREATE TABLE USER (username char, password ...)`)
|
|
|
|
Migrations are very analogous to sandwiches and burgers in a sense, if you decide to add a **grumpy** attribute to your **User**
|
|
|
|
|
|
and run `python manage.py makemigrations` again,
|
|
|
|
|
|
This will create a second migration file (`0002\_customuser\_grumpy.py`)
|
|
|
|
|
|
When you apply these migrations (which we will do shortly), Django reads each migration file in order, starting off with #1 to create the initial **User** model, and then to step #2 to add the **grumpy** field, which under the hood uses SQL Alter (e.g. `ALTER USER ADD grumpy boolean`).
|
|
|
|
Django's migrations will also let you know if you make changes to your models that might break things (e.g. removing an already added field when you have records for that already).
|
|
|
|
This is something you should ideally understand with Django and how it interfaces with your database under the hood.
|
|
|
|
### Apply Migrations
|
|
If you've noticed this error in the previous sections, this is because we haven't applied our migrations yet!
|
|
|
|
With your user schema or template now set up, you should now apply these changes to the database.
|
|
|
|
Run the command `python manage.py migrate` to apply these changes
|
|
|
|
|
|
This will apply your changes to the database, which by default is SQLite**,** the **db.sqlite3** file.
|
|
|
|
With that out of the way, running your Django project (`python manage.py runserver 0.0.0.0:8000`) will no longer yield the migration warning.
|
|
|
|
|
|
It's always important to apply your migrations before running your app, otherwise you might run into issues.
|
|
|
|
In the next section, you will be creating your first (superuser) account to access the Django admin panel. |