DEV Community: DoriDoro

Cheat Sheet for all Django `on_delete` options

DoriDoro — Fri, 20 Jun 2025 08:22:55 +0000

Django `on_delete` Cheat Sheet

Option	What Happens When Referenced Object is Deleted?	Use Case Example
`CASCADE`	Also delete the object with the ForeignKey	Delete all `Comment`s when a `Post` is deleted
`PROTECT`	Raises `ProtectedError` and prevents deletion	Prevent deleting a `User` if they’re linked to existing `Orders`
`SET_NULL`	Sets the ForeignKey field to `NULL`	Keep `Article`, but set `author = NULL` when `Author` is deleted
`SET_DEFAULT`	Sets the ForeignKey field to its default value	If a `Product` is deleted, fallback to a default `Category`
`SET(...)`	Sets the ForeignKey to a custom value or callable	Set to an "archived" user when original `User` is deleted
`DO_NOTHING`	Does nothing; deletion might fail due to DB-level constraints	Advanced use with manual control; avoid unless necessary
`RESTRICT` (Django 3.1+)	Raises error if there are any referencing objects (like `PROTECT`, but stricter in behavior visibility)	Similar to `PROTECT`, but enforces DB constraint at the SQL level

When to Use What?

Goal	Recommended Option
Automatically delete dependents	`CASCADE`
Prevent deletion if used somewhere	`PROTECT` or `RESTRICT`
Allow deletion, but keep dependent object	`SET_NULL` or `SET(...)`
Replace with default	`SET_DEFAULT`
Full manual control	`DO_NOTHING`

Example Code Snippets

from django.db import models
from django.conf import settings

class Post(models.Model):
    author = models.ForeignKey(
        settings.AUTH_USER_MODEL,
        on_delete=models.SET_NULL,
        null=True,
        blank=True,
    )

class Comment(models.Model):
    post = models.ForeignKey(Post, on_delete=models.CASCADE)

class Order(models.Model):
    user = models.ForeignKey(settings.AUTH_USER_MODEL, on_delete=models.PROTECT)

class Product(models.Model):
    category = models.ForeignKey(
        "Category",
        on_delete=models.SET_DEFAULT,
        default=1  # assuming category with id=1 is 'Uncategorized'
    )

Using JWT with Django REST Framework and Vue.js

DoriDoro — Fri, 14 Mar 2025 11:25:45 +0000

Here’s how JWT (JSON Web Token) works in Django DRF:

Step-by-Step JWT Flow

1️⃣ User Logs In

Frontend sends username & password to /api/token/.
Django returns access and refresh tokens.

{
  "access": "eyJhbGciOi... (valid for 60 minutes)",
  "refresh": "eyJhbGciOi... (valid for 7 days)"
}

2️⃣ Frontend Stores the Tokens

The access token is stored in Vuex, Pinia, or LocalStorage.
The refresh token is stored in HTTP-only cookies (for security).

3️⃣ Frontend Sends Access Token with Every API Request

When making a request to Django, Vue.js adds the token to the Authorization header:

fetch("/api/chats/", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${accessToken}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify(data)
});

4️⃣ Backend Verifies the Token

DRF checks if the access token is valid.
If valid → The request is processed.
If expired → The backend rejects it (401 Unauthorized).

5️⃣ Frontend Uses Refresh Token to Get a New Access Token

If the access token expires, Vue.js sends the refresh token to /api/token/refresh/ to get a new one.

Request to Refresh Token:

{
  "refresh": "eyJhbGciOi... (old refresh token)"
}

Backend Response (New Access Token):

{
  "access": "eyJhbGciOi... (new access token)"
}

6️⃣ Frontend Stores the New Access Token and Continues

The new access token replaces the old one and API requests continue normally.

Vue.js Example: Sending JWT Token

When the frontend sends a request to create a chat, it includes the JWT token:

async function sendChat(question, personas) {
  const accessToken = localStorage.getItem("accessToken");

  const response = await fetch("/api/chats/", {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      "Authorization": `Bearer ${accessToken}`
    },
    body: JSON.stringify({
      question: question,
      personas: personas.map(p => p.name),
      responses: personas.map(p => ({
        persona: p.name,
        response_text: "Simulated AI response"
      }))
    })
  });

  if (response.status === 401) {
    console.log("Access token expired. Refreshing...");
    await refreshToken();
    return sendChat(question, personas);
  }
}

What is `ContentFile` in Django?

DoriDoro — Thu, 13 Mar 2025 18:12:02 +0000

ContentFile is a Django utility class that allows you to create a file-like object from raw data (such as a string or binary data). It is particularly useful when you want to save an image or other file content directly into a Django FileField or ImageField without needing an actual file on disk.

Why is `ContentFile` Needed?

Normally, when you assign a file to a Django ImageField, Django expects a physical file. However, in cases where you generate or modify an image in memory (e.g., resizing it with Pillow), you don’t have a physical file yet.

This is where ContentFile comes in:

It allows you to take binary data (like an image stored in memory with BytesIO()) and treat it as if it were a normal file, so it can be saved into a model's ImageField.

How Does `ContentFile` Work?

from django.core.files.base import ContentFile

# Example: Creating a file-like object from raw data
raw_data = b"Hello, this is some binary data"
file_obj = ContentFile(raw_data, name="example.txt")

Now, file_obj behaves like a Django File object, even though it's just binary data stored in memory.

Why Is It Used in Your Code?

In your profile image resizing function, we don’t want to save the resized image to disk first before saving it into self.photo. Instead, we process it in memory and then directly store it into Django’s ImageField using ContentFile.

Here’s the key part of your function:

# Save the resized image to memory
buffer = BytesIO()
img.save(buffer, format="JPEG", quality=90)

# Use ContentFile to store the in-memory image into the ImageField
self.photo.save(new_image_filename, ContentFile(buffer.getvalue()), save=False)

Breakdown of What Happens Here

The image is processed and resized using Pillow.
The resized image is written into a BytesIO buffer (not saved to disk).
buffer.getvalue() extracts the binary image data.
ContentFile(buffer.getvalue()) creates a file-like object from the binary data.
self.photo.save(new_image_filename, ContentFile(buffer.getvalue()), save=False)
- Assigns the resized image directly to the photo field, without needing to write a file to disk first.
- save=False ensures we don’t accidentally call save() on the whole model multiple times.

What Would Happen Without `ContentFile`?

If we didn’t use ContentFile, we would have to:

Save the resized image to disk first.
Open the saved file and assign it to photo.
Delete the intermediate file after assigning.

That would be slow and inefficient. ContentFile lets us skip saving an unnecessary temporary file to disk, making the process faster and cleaner.

Final Takeaways

ContentFile is needed when saving files directly from memory into Django models.
It allows us to store an image in an ImageField without writing to disk first.
It works perfectly with Pillow (PIL.Image) and Django's file handling system.
It makes image processing more efficient and avoids unnecessary I/O operations.

When Should You Use `ContentFile`?

When working with images processed in memory (like resized thumbnails).
When creating dynamic files (e.g., a PDF or CSV generated on-the-fly).
When handling uploads via API where the file is received as raw data.

Understanding creating an Authentication Backend in a Django project

DoriDoro — Sun, 02 Mar 2025 08:17:00 +0000

Introduction

An authentication backend in Django is a class that determines how users are authenticated (logged in). By default, Django uses ModelBackend, which authenticates users based on their username and password. However, Django allows developers to define custom authentication backends to modify or extend authentication behavior or authenticate users against different sources (internal or external sources). An external authentication systems like Lightweight directory Access Protocol (LDAP) server or even third-party providers.

Why Use an Authentication Backend?

Authentication backends are used when you want to:

Authenticate users in different ways, such as logging in with an email as a username.
Support multiple authentication methods, like social logins (Google, Facebook) or external APIs.
Implement custom user verification logic, such as checking user roles, permissions, or account status.

How Does It Work?

Django uses authentication backends in the following way:

When a user tries to log in, Django iterates through the backends listed in AUTHENTICATION_BACKENDS in settings.py.
Each backend’s authenticate() method is called. If a backend returns a user, authentication is successful.
If no backend authenticates the user, login fails.

Example: Custom Email Authentication Backend

Here’s a simple authentication backend that allows users to log in with their email and password instead of a username:

# app/authentication.py

from django.contrib.auth import get_user_model

UserModel = get_user_model()

class EmailAuthBackend:
    """Authenticate users using their email address instead of a username."""

    def authenticate(self, request, username=None, password=None):
        try:
            user = UserModel.objects.get(email=username)
            if user.check_password(password):
                return user
        except UserModel.DoesNotExist:
            return None

    def get_user(self, user_id):
        """Retrieve a user by their ID."""
        try:
            return UserModel.objects.get(pk=user_id)
        except UserModel.DoesNotExist:
            return None

Configuring Authentication Backends in Django

To enable a custom authentication backend, update settings.py:

# project/settings.py

# Authentication backends configuration
AUTHENTICATION_BACKENDS = [
    "path.to.EmailAuthBackend",  # Allow email login
    "django.contrib.auth.backends.ModelBackend",  # Default username login
]

When you add a custom authentication backend like above you should consider some important changes in your application.

By default Django User model does not enforce unique email address. To ensure that the email address of each User instance is unique, it is better practice to set the email attribute inside of your User model to unique=True.

# accounts/models.py

class User(AbstractUser):
    """Default User model does not enforce unique emails!"""

    email = models.EmailField(unique=True)

Now Django automatically enforces uniqueness at the database level, meaning:

If someone tries to register with an existing email, the database will raise an IntegrityError.
However, Django’s form validation does not check this before submitting unless you explicitly add it.

Changing the email address to be unique requires additional changes. If a user registers or changes their email address within your application and the uniqueness of the email is not verified in the registration view, this will result in a 500 server error. And to have a more user friendly message instead of an error 500, you need to add additional logic to the registration form.

Add a clean_email() method to the registration form.

# accounts/forms.py

from django import forms
from django.contrib.auth.forms import UserCreationForm
from django.contrib.auth import get_user_model

UserModel = get_user_model()

class RegistrationForm(UserCreationForm):
    """Register form for new User instances"""

    class Meta:
        model = UserModel
        fields = ["username", "first_name", "email", "password1", "password2"]

    def clean_email(self):
        """Ensure email is unique before saving."""
        email = self.cleaned_data["email"]
        if UserModel.objects.filter(email=email).exists():
            raise forms.ValidationError("Email already exists. Please use a different one.")
        return email

With this setup:

Registration → Users provide a username, email, and password.
Login → Users can log in using either:
- Username + Password (handled by ModelBackend)
- Email + Password (handled by EmailAuthBackend)

This gives users flexibility while still keeping the registration process structured. It’s a great balance between user convenience and maintaining Django’s built-in authentication system.

Fixing Docker 'Permission Denied' Error on Ubuntu 24.04: A Step-by-Step Guide

DoriDoro — Sat, 01 Mar 2025 09:03:06 +0000

Intrduction

When setting up Docker on Ubuntu 24.04, you might encounter a "permission denied" error when running Docker commands without sudo. This issue typically occurs because the user does not have the correct permissions to access the Docker daemon. Even after adding the user to the docker group, the changes may not take effect immediately, leading to frustration when trying to run docker images or other commands.

1. Remove Old Docker Versions (If Any):

sudo apt remove -y docker docker-engine docker.io containerd runc

2. Update Package Lists:

sudo apt update

3. Add Docker's Official GPG Key:

sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

4. Verify Your Ubuntu Version:

lsb_release -cs

This should return noble (for Ubuntu 24.04). If not, check your installation.

4. Set Up Docker's Stable Repository:

echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu noble stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

5. Update Package Index Again:

sudo apt update

6. Install Docker Engine and Related Components:

sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

7. Verify Docker Installation:

sudo systemctl status docker

When the Service is working, the terminal should show:

docker.service - Docker Application Container Engine

and further information

End the running Service with:

8. Test Docker with a Sample Container:

sudo docker run hello-world

These steps install Docker on your machine.

When I installed Docker on my machine, there was still a message when trying to access all docker images (docker images) on my machine:

permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Head "http://%2Fvar%2Frun%2Fdocker.sock/_ping": dial unix /var/run/docker.sock: connect: permission denied

this message appears when you want to access docker images without sudo permission on your machine.

Solution: Add Your User to the docker Group
1. Check if the docker group exists:

getent group docker

If nothing is returned, create the group manually:

sudo groupadd docker

2. Add Your User to the docker Group:

sudo usermod -aG docker $USER

3. Apply the Changes: Log out and log back in, or restart your machine:

newgrp docker

4. Test Running Docker without sudo:

docker images

When you want to access the docker system without any sudo commands, restart your machine and it is done.

Conclusion

The "permission denied" error is usually resolved by ensuring the user is correctly added to the docker group and restarting the system to apply the changes. If the issue persists, checking and adjusting the permissions of the Docker socket can help. After completing these steps, you should be able to run Docker commands without sudo and manage containers smoothly.

What is the difference between INNER JOIN, LEFT JOIN and RIGHT JOIN in SQL?

DoriDoro — Wed, 19 Feb 2025 19:50:44 +0000

Once I came across the question: "what is a right table and what is a left table in SQL?"

In SQL, the terms "left table" and "right table" refer to the order in which tables are listed in a JOIN clause. His order determines how the join operates, especially in LEFT JOIN and RIGHT JOIN scenarios.

Determining the Left and Right Tables:

Left Table: The table that appears first in the JOIN clause.
Right Table: The table that appears second in the JOIN clause.

ELECT columns
FROM table1
LEFT JOIN table2 ON table1.id = table2.id;

In this above query:

table1 is the left table.
table2 is the right table.

Understanding LEFT JOIN and RIGHT JOIN:

LEFT JOIN: Returns all records from the left table and the matched records from the right table. If there's no match, the result is NULL on the side of the right table.
RIGHT JOIN: Returns all records from the right table and the matched records from the left table. If there's no match, the result is NULL on the side of the left table.

The designation of "left" and "right" is purely based on the order of tables in your SQL statement. By rearranging the order of tables and switching between LEFT JOIN and RIGHT JOIN, you can achieve the same results. However, LEFT JOIN is more commonly used in practice.

Now, what is the difference between `JOIN`, `LEFT JOIN` and `RIGHT JOIN` in SQL?

In SQL, joins are used to combine rows from two or more tables based on related columns. The primary types of joins are:

INNER JOIN: Returns only the rows where there is a match in both tables.
LEFT JOIN (LEFT OUTER JOIN): Returns all rows from the left table and the matched rows from the right table. If there's no match, the result is NULL on the side of the right table.
RIGHT JOIN (RIGHT OUTER JOIN): Returns all rows from the right table and the matched rows from the left table. If there's no match, the result is NULL on the side of the left table.

Syntax examples:

  ELECT columns
  FROM table1
  INNER JOIN table2
  ON table1.common_column = table2.common_column;

  ELECT columns
  FROM table1
  LEFT JOIN table2
  ON table1.common_column = table2.common_column;

  ELECT columns
  FROM table1
  RIGHT JOIN table2
  ON table1.common_column = table2.common_column;

Integrate Sentry into your Django project

DoriDoro — Thu, 02 Jan 2025 14:28:12 +0000

Introduction

When your project is ready to go live, it is a good time to integrate Sentry services to monitor your failures. It enables automatic reporting of defects and exceptions, as well as traceability.

1. Install Sentry in your project

pip install --upgrade 'sentry-sdk[django]'

If you have a Django project and want to use the DjangoIntegration option, you will only need this Django extension. And add sentry-sdk to requirements.txt.

2. Create a project on Sentry website

Log in to your account or sign up for a new free account from the Sentry home page. You will be taken to the main account dashboard after logging in or completing the Sentry sign-up process.

Click on 'Projects' in the left sidebar to go to the Projects page and create a new Sentry Project just for this application. Click on the 'Create Project' button at the top right of the page.

You choose 'Django' as platform. The next step is to give your new project a name and then press the 'Create Project' button. We can now integrate our Python code into our new project.

3. Set up your Django project

In your newly created Sentry project, you will find the documentation you need to continue to integrate the sentry-sdk into your project.

First, import the sentry-sdk at the top of your file and add the sentry-sdk to the end of your settings.py file:

# blog_project/settings.py

import sentry_sdk


sentry_sdk.init(
    dsn="https://yourkeygoeshere.ingest.sentry.io/project-number",
    traces_sample_rate=1.0,
    _experiments={
        "continuous_profiling_auto_start": True,
    },
)

The next step is to add a URL to your project to trigger your first error, which will be reported in your Sentry dashboard. Personally, in order to be able to check the functionality of the Sentry integration later in production, I do not remove this URL and the ability to trigger an error in your project.

# core/urls.py

from django.urls import path

app_name = "core"


def trigger_error(request):
    division_by_zero = 1 / 0


urlpatterns = [
    path("sentry-debug/", trigger_error),
]

4. Check the functionality

Start your development server with python manage.py runserver. Navigate to your URL pattern: http://127.0.0.1:8000/sentry-debug/.

This URL will cause a zero revision error in your project. Wait a minute or two and refresh the Sentry dashboard to see if the sentry-sdk integration was successful.

5. Additional informations

DjangoIntegration makes it much easier to debug and monitor a Django application with Sentry. It's highly recommended to include it when using Sentry in a Django project.

In order to integrate the DjangoIntegration option, you need to import DjangoIntegration at the top of the settings.py file and update the part from 'integrations' onwards.

# blog_project/settings.py

from sentry_sdk.integrations.django import DjangoIntegration

sentry_sdk.init(
    dsn="your-sentry-dsn",
    integrations=[
        DjangoIntegration(),
    ],
    traces_sample_rate=1.0,  # Enables performance monitoring
    send_default_pii=True,   # Sends Personally Identifiable Information (PII), like user details
)

The Django integration has more features. But for a simple Django project these settings are sufficient.

Sentry documentation Django section

Django built-in authentication system

DoriDoro — Fri, 27 Dec 2024 22:40:46 +0000

Introduction:

In this article I will explain to you how to create a simple Django project with the basic login and logout authentication process. Django has built-in authentication systems and built-in views that you can use to quickly and easily create a user authentication using your own templates.

Create the Django project:

Create a new project in your IDE or Terminal and go to the folder you have created. Create a virtual environment.

Now install the dependencies inside your virtual environment:

pip install django python-decouple ipyhton

You can chain multiple dependencies together. You install Django for your project. python-decouple is for the .env file where you put all your secret environment variables, like the SECRET_KEY or all email configurations, etc. And ipython is a nice tool for the shell.

After you have successfully installed your dependencies, store them in a file in the root directory with:

pip freeze > requirements.txt

pip freeze lists all dependencies in terminal
> requirements.txt this will save all installed dependencies in a the file called requirements.txt or create the file.

Now build your Django project inside the virtual environment using:

django-admin startproject authentication .

The . after the name of your project is to create the Django project directory inside the root directory.

After you have created your first application inside the Django project:

python manage.py startapp accounts

The application has to be added into to the INSTALLED_APPS in the settings.py file inside the authentication project directory.

# authentication/settings.py

# Application definition
INSTALLED_APPS = [
    "accounts",
    "django.contrib.admin",
    "django.contrib.auth",
    "django.contrib.contenttypes",
    "django.contrib.sessions",
    "django.contrib.messages",
    "django.contrib.staticfiles",
]

If you want to create your own custom authentication templates, you need to make sure that your created application accounts is placed before the "django.contrib.admin" application.

Ensure security of your project:

To ensure the security of your project, you should store the SECRET_KEY, DEBUG, ALLOWED_HOSTS, etc. in a locally stored .env file.

Enter the above command in your terminal to create a secure SECRET_KEY:

python manage.py shell -c 'from django.core.management import utils; print(utils.get_random_secret_key())'

Create an .env file in the root directory and add:

# general project variables:
SECRET_KEY="r^=cy=8w8$^p)!gd6#%*c)s-u4h!ua9r6!i317qt^6l47)94t^"
DEBUG=True
ALLOWED_HOSTS=localhost,127.0.0.1

To be able to start your development server, you need to have access to the project variables such as the SECRET_KEY. You need to make sure that your settings.py file has access to the environment variables stored in the .env file.

The first step is already done by installing python-decouple. Now update the settings.py file:

# authentication/settings.py

from decouple import config


# SECURITY WARNING: keep the secret key used in production secret!
SECRET_KEY = config("SECRET_KEY")

# SECURITY WARNING: don't run with debug turned on in production!
DEBUG = config("DEBUG")

ALLOWED_HOSTS = config("ALLOWED_HOSTS", default="").split(",")

ALLOWED_HOSTS should be a list. We have stored the value as a comma separated string in the .env file. Within the settings.py file, we split the comma-separated strings at the , and create a list from them.

The next file you need to create is the .gitignore file, to avoid sending your environment variables to GitHub or GitLab.

# Byte-compiled / optimized / DLL files
__pycache__/
*.py[cod]
*$py.class

# Django stuff:
*.log
*.pot
*.pyc

# virtual environment
.venv

# IDE
.idea

# Local configuration
.env

This .gitignore file is just an example, yours may look different depending on your IDE.

Creating a User model:

It is good practice to use the AbstractUser to create your own user model:

# accounts/models.py

from django.contrib.auth.models import AbstractUser


class User(AbstractUser):
    pass

If necessary, you can add additional attributes within the User class.

The next step is to add the User model to the Admin Panel. This way you can easily create User instances from the admin panel. You can also create User instances in the Python shell.

# accounts/models.py

from django.contrib import admin
from django.contrib.auth import get_user_model
from django.contrib.auth.admin import UserAdmin

UserModel = get_user_model()

admin.site.register(UserModel, UserAdmin)

In the settings.py file, we need to set the User we created to tell the project that we want to use our custom User model.

# authentication/settings.py

# template settings
TEMPLATES = [
    {
        'BACKEND': 'django.template.backends.django.DjangoTemplates',
        'DIRS': [BASE_DIR / "templates"],  # Make sure this is set correctly
        'APP_DIRS': True,
        'OPTIONS': {
            'context_processors': [
                'django.template.context_processors.debug',
                'django.template.context_processors.request',
                'django.contrib.auth.context_processors.auth',
                'django.contrib.messages.context_processors.messages',
            ],
        },
    },
]


# set the User
AUTH_USER_MODEL = "accounts.User"

The next commands create the migration file inside the accounts application and create the database tables inside the SQLite database.

python manage.py makemigrations
python manage.py migrate

Now, it is time to create an admin user in terminal:

python manage.py createsuperuser

Username: Admin
Email address: admin@mail.com
Password: 
Password (again): 
Superuser created successfully.

Remember or save these authentication details for future use.

Django provides a set of built-in authentication views for login, logout, password reset, etc. However, you do need to create templates for the different pages in folder: accounts/templates/registration. And add for every view a template, like: registration/login.html for the LoginView because Django’s built-in authentication system does not provide its own templates — it only provides the views.

Setting the authentication URLs and creating custom authentication templates:

The new application was already added to the project when we added the accounts name to the INSTALLED_APPS list in settings.py, but we need to integrate all future url patterns from the accounts application into the project URL file:

# authentication/urls.py

from django.contrib import admin
from django.urls import path, include

urlpatterns = [
    path("admin/", admin.site.urls),
    path("accounts/", include("accounts.urls", namespace="accounts")),
]

We will include all url patterns of the accounts application, which will be under the accounts namespace.

Inside the accounts application, create a new file called urls.py and add the following:

# accounts/urls.py

from django.urls import path, include


app_name = "accounts"

urlpatterns = [
    path("", include("django.contrib.auth.urls")),
]

The app_name should be the same as the namespace attribute inside the path() function in the authentication urls.py file.

If you start the development server with:

python manage.py runserver

and navigate to the URL: http://127.0.0.1:8000/accounts/ you will have access to the following URL patterns:

admin/
accounts/ login/ [name='login']
accounts/ logout/ [name='logout']
accounts/ password_change/ [name='password_change']
accounts/ password_change/done/ [name='password_change_done']
accounts/ password_reset/ [name='password_reset']
accounts/ password_reset/done/ [name='password_reset_done']
accounts/ reset/<uidb64>/<token>/ [name='password_reset_confirm']
accounts/ reset/done/ [name='password_reset_complete']

Let's create a test user and navigate to http://127.0.0.1:8000/admin/. Enter the username in my example: Admin and the password you set with the python manage.py createsuperuser command.

Under the heading ACCOUNTS you can add a new user. You enter the username, twice the password and save it. Then you have to enter additional information such as first and last name and email address and save again.

Login and Logout view:

The first template we will create is the base.html template in the accounts application. First create a directory inside the accounts application called: templates and inside the templates directory create a file called base.html:

<!-- accounts/templates/base.html -->

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>{% block title %}{% endblock %}</title>
</head>
<body>
  <div>
    <span class="logo">Authentication</span>
      {% if request.user.is_authenticated %}
        <ul class="menu">
          <li {% if section == "dashboard" %}class="selected"{% endif %}>
            <a href="{% url 'accounts:dashboard' %}">My dashboard</a>
          </li>
        </ul>
      {% endif %}
    <span class="user">
      {% if request.user.is_authenticated %}
        Hello {{ request.user.first_name|default:request.user.username }},
        <form action="{% url 'accounts:logout' %}" method="post">
          <button type="submit">Logout</button>
          {% csrf_token %}
        </form>
      {% else %}
        <a href="{% url 'accounts:login' %}">Log-in</a>
      {% endif %}
    </span>
  </div>

  <div id="content">
    {% block content %}
    {% endblock %}
  </div>
</body>
</html>

The URL syntax in my case always has the application name accounts before the URL name, otherwise the URL name will not be found. If the authentication URL is in a namespace, the application name must be added.

We will create three additional templates, a login template, a logged_out template and a template after the user has successfully logged in, a dashboard.

<!-- accounts/templates/registration/login.html -->

{% extends "base.html" %}

{% block title %}Log-in{% endblock %}

{% block content %}
  <h1>Log-in</h1>
  {% if form.errors %}
    <p>
      Your username and password didn't match.
      Please try again.
    </p>
  {% else %}
    <p>
      Please, use the following form to log-in.

    </p>
  {% endif %}
  <div class="login-form">
    <form method="post">
      {{ form.as_p }}
      {% csrf_token %}
      <input type="hidden" name="next" value="{{ next }}" />
      <p><input type="submit" value="Log-in"></p>
    </form>

  </div>
{% endblock %}

<!-- accounts/templates/registration/logged_out.html -->

{% extends "base.html" %}

{% block title %}Logged out{% endblock %}

{% block content %}
  <h1>Logged out</h1>
  <p>
    You have been successfully logged out.
    You can <a href="{% url 'accounts:login' %}">log-in again</a>.
  </p>
{% endblock %}

Make sure you use the template name: logged_out otherwise this template will be ignored.

<!-- accounts/templates/dashboard.html -->

{% extends "base.html" %}

{% block title %}Dashboard{% endblock %}

{% block content %}
  <h1>Dashboard</h1>
  <p>Welcome to your dashboard.</p>
{% endblock %}

It is not done yet. We need to create the view and an URL for the dashboard and set some variables in the settings.py file.

# accounts/views.py

from django.contrib.auth.decorators import login_required
from django.shortcuts import render


@login_required
def dashboard(request):
    return render(request, "dashboard.html", {"section": "dashboard"})

Only an authenticated user has access to this view, we ensure this with the login_required decorator.

# accounts/urls.py

from django.urls import path, include

from accounts.views import dashboard

app_name = "accounts"

urlpatterns = [
    path("", include("django.contrib.auth.urls")),
    path("", dashboard, name="dashboard"),
]

In settings.py file we have to set some variable to ensure the redirection after the login to our dashboard URL:

# authentication/settings.py

LOGIN_REDIRECT_URL = "accounts:dashboard"
LOGIN_URL = "login"
LOGOUT_URL = "logout"

The LOGIN_REDIRECT_URL leads the way to the dashboard URL pattern inside the accounts application.

Django documentation:
- Django authentication system
- Authentication Views
GitHub repository:
- URL patterns
- views

How to create a simple Flask application

DoriDoro — Tue, 03 Dec 2024 10:29:20 +0000

Introduction:

For this article, I wanted to create a guide to building a simple Flask app from scratch. This guide is just to get you through the first steps of creating a Flask application.

creating a simple Flask app

My favourite IDE is PyCharm. To create a simple Flask application, I have created a new project within PyCharm. The advantage of doing that in PyCharm is, that my IDE creates immediately a virtual environment.

You have to install Flask in your virtual environment:

pip install Flask

Save the dependencies in a file (requirements.txt) in root directory with command:

pip freeze > requirements.txt

Legend:

pip freeze: This command creates a list of all your installed packages in the virtual environment, along with their versions.
> requirements.txt: This part of the command saves all the installed packages and their versions into a file called: requirements.txt. When this file doesn't exist that command creates this file in root directory.

To create a simple Flask application, you have to create in your root directory a file named: 'server.py' (you can name it whatever you like but AVOID to name it 'flask.py') and add this:

# server.py

from flask import Flask

app = Flask(__name__)

@app.route("/")
def hello_world():
    return "<p>Hello, World!</p>"

Legend:

We import the Flask class at the beginning of our file. An instance of this class will be our WSGI application.
Next we create an instance of the Flask class.
The route() decorator tells Flask which URL triggers our function.
In this simple example, the function returns a paragraph with the content of "Hello World!".

The next step is to start the server:

flask --app server run --debug

Legend:

flask: Is the Flask CLI tool to manage the application.
--app server: This part specifies that the Flask application is defined in the server.py file.
run: This command starts the Flask development server and serves the application locally.
--debug: This part enables the debug mode of the Flask application.

And that is it, you can go to your browser and enter: http://127.0.0.1:5000 and you should see "Hello World!" displayed on your browser screen.

Flask documentation

Django migration operations

DoriDoro — Tue, 05 Nov 2024 16:51:15 +0000

# migrations/0002_auto_20240311_1546.py

from django.db import migrations


class Migration(migrations.Migration):

    dependencies = [
        ('oc_lettings_site', '0001_initial'),
    ]

    operations = [
        migrations.SeparateDatabaseAndState(
            state_operations=[
                migrations.RemoveField(
                    model_name='letting',
                    name='address',
                ),
            ],
            database_operations=[],
        ),
        migrations.SeparateDatabaseAndState(
            state_operations=[
                migrations.RemoveField(
                    model_name='profile',
                    name='user',
                ),
            ],
            database_operations=[],
        ),
        migrations.SeparateDatabaseAndState(
            state_operations=[
                migrations.DeleteModel(
                    name='Address',
                ),
            ],
            database_operations=[
                migrations.AlterModelTable(
                    name='Address',
                    table='lettings_address',
                ),
            ],
        ),
        migrations.SeparateDatabaseAndState(
            state_operations=[
                migrations.DeleteModel(
                    name='Letting',
                ),
            ],
            database_operations=[
                migrations.AlterModelTable(
                    name='Letting',
                    table='lettings_letting',
                ),
            ],
        ),
        migrations.SeparateDatabaseAndState(
            state_operations=[
                migrations.DeleteModel(
                    name='Profile',
                ),
            ],
            database_operations=[
                migrations.AlterModelTable(
                    name='Profile',
                    table='profiles_profile',
                ),
            ],
        ),
    ]

In Django, migrations are used to alter the database schema and structure when the models in the application change. In your code, the migrations.SeparateDatabaseAndState method is used to handle scenarios where the in-memory model state operations (state_operations) need to be decoupled from the actual database schema operations (database_operations). Here’s a breakdown of what each operation in your migration file is doing:

1. `migrations.RemoveField`

migrations.RemoveField(
    model_name='letting',
    name='address',
)

Purpose: This operation removes a field named address from the Letting model.
Effect:
- In terms of the model: After this operation, the Letting model in Django’s internal state will no longer have the address field.
- In terms of the database: If executed as a direct migration, this would typically drop the corresponding column (address_id) in the letting table. However, here it's specified within state_operations, so it affects the in-memory model state but not the database schema directly.

2. `migrations.DeleteModel`

migrations.DeleteModel(
    name='Address',
)

Purpose: This operation deletes the Address model entirely.
Effect:
- In terms of the model: The Address model is removed from Django’s internal state, meaning you can no longer query it or use it in your code.
- In terms of the database: The corresponding table (lettings_address) would usually be dropped from the database, but in this case, it's handled separately using database_operations to prevent this drop.

3. `migrations.AlterModelTable`

migrations.AlterModelTable(
    name='Address',
    table='lettings_address',
)

Purpose: This operation changes the table name for the Address model.
Effect:
- In terms of the database: It renames the existing database table to lettings_address.
- This is included in the database_operations section because it deals directly with the database schema rather than altering the model's in-memory state.

Summary of the Migration

migrations.RemoveField: Removes the address field from the Letting model (model state change).
migrations.DeleteModel: Deletes the Address model from the internal Django state (model state change), but since database_operations are defined, the table will not be dropped.
migrations.AlterModelTable: Changes the table name of the Address model to lettings_address (database schema change).

This approach is useful when you want to change the Django model state but preserve some aspects of the database schema manually. In this case, you are deleting the model Address from Django but keeping the corresponding table in the database, which is why you explicitly use AlterModelTable to rename it.

When dealing with Django migrations, it's common to encounter scenarios where you need to align Django's internal model state with the underlying database schema. In your example, the goal appears to be connecting a new or refactored model to an existing database table while ensuring consistency between the model's representation and the actual database schema.

Why Remove Fields and Delete the Model?

Django Tracks the Internal State of Models:
- Django maintains a representation of your models through its internal migration state. Any changes to your models (e.g., fields, models, or related tables) need to be reflected in this state so that Django knows what the "current" structure should be.
- If you have an Address model with fields, removing it in Django’s codebase will make Django expect that the model (and its fields) are no longer in use. This expectation needs to be formally expressed through migrations so that the model’s absence is understood.
Separating In-Memory State Changes from Database Schema Changes:
- By using SeparateDatabaseAndState, you can alter the in-memory state separately from the database schema.
- Removing fields and deleting the model in the state_operations ensures that Django’s migration system reflects the fact that this model and its fields no longer exist in your Python code. But this does not impact the actual database tables until you apply changes via database_operations.
Avoiding Conflicts and Data Loss:
- Without RemoveField and DeleteModel, Django would still have references to the old model (Address) and its fields. This can lead to schema conflicts when trying to connect a new model to the old database table.
- If you simply renamed the table and tried to associate it with a "new" model without removing the old one, Django’s migration system might get confused and create duplicate tables or fail with errors about field or table name conflicts.

Connecting the 'Old' Database Table to a 'New' Model

If your end goal is to connect an existing table to a new model, Django needs to see that you’ve removed the old model and are explicitly associating the new one.
By removing fields and deleting the old model, you’re effectively telling Django:
1. This old model and its fields should no longer be tracked.
2. I want to connect a new (or refactored) model to the same table using the AlterModelTable operation.

Migration Sequence Explanation

Here’s how it breaks down in your specific migration:

Remove the address field from Letting so that Letting is no longer linked to the Address model.
Delete the Address model in Django’s in-memory state, indicating it’s not used anymore in your application code.
Rename the table (using AlterModelTable) to keep the database content but update its association.

This pattern ensures that:

Django no longer tracks the old Address model or its fields.
The table remains in the database under the new name, ready to be re-associated with a different model.

What Happens Without This Sequence?

If you skip the RemoveField and DeleteModel operations:

Django would still consider the Address model and its fields part of your project, causing confusion when trying to associate a new model with the same table.
Schema conflicts can occur when two models (the old Address and a new one) try to interact with the same table.
Your database content might get corrupted or cause runtime errors if Django tries to apply changes based on the outdated model state.

Key Takeaway

The RemoveField and DeleteModel are necessary to "clean up" Django’s internal state so it correctly understands the structure you’re aiming for.
The AlterModelTable then safely renames the table and prepares it for use with the new model, ensuring no data loss.

This approach ensures a smooth transition of database content to a new model without disrupting Django’s tracking of your application’s schema.

Django REST Framework (DRF) - permissions

DoriDoro — Mon, 28 Oct 2024 10:37:23 +0000

Introduction

In Django REST Framework, permissions are a crucial part of the authentication and authorization mechanism. They determine the level of access that users have to various resources in your API, ensuring that sensitive information is protected and only accessible to authorized users.

Permissions can be applied at the view level, allowing you to specify who can list, retrieve, create, update, or delete resources. This fine-grained control is essential for building secure applications, as it restricts actions based on user roles, authentication status, or other custom rules.

DRF provides a set of built-in permission classes that cover common use cases, such as granting access to authenticated users or allowing only admin users to perform certain actions. You can apply these permission classes to individual views or viewsets using the permission_classes attribute.

For more complex scenarios, DRF's flexibility allows you to define custom permission classes by extending the BasePermission class. By leveraging permissions effectively, you can build robust APIs that cater to different user roles while maintaining data integrity and security.

Setting the permission policy

You can choose not to set a general restriction for your project. By doing so, the default settings of the Djnago REST framework will allow unrestricted access.

The DEFAULT_PERMISSION_CLASSES is set to the permission AllowAny.

'DEFAULT_PERMISSION_CLASSES': [
   'rest_framework.permissions.AllowAny',
]

In your settings.py file you can set a general restriction:

REST_FRAMEWORK = {
    'DEFAULT_PERMISSION_CLASSES': [
        'rest_framework.permissions.IsAuthenticated',
    ]
}

The restriction allows only authenticated users to access your entire project.

You can also set permissions in your view. You can set a general permission in your settings.py and override the permission_classes in your view. Or you can set your permissions in your view only.

How to apply a permission to a view?

class AccountViewSet(viewsets.ModelViewSet):
    queryset = Account.objects.all()
    serializer_class = AccountSerializer
    permission_classes = [IsAccountAdminOrReadOnly]

You add the permission into the permission_classed list in your view.

How does the system work?

There is a difference between the APIView and the ViewSet and GenericViewSet. The APIView provides a very basic view that you can extend. It doesn't come with automatic permission behavior, so you need to call check_object_permission manually. On the other hand, ViewSets and Generic Views are built on top of APIView and come with more built-in functionality. They come pre-equipped with mechanisms to handle permissions for detail routes. Essentially, inside ViewSets and Generic Views, there's logic that automatically handles permission checks when it accesses an object. This is done through the use of mixins and generic classes, making it unnecessary for you to manually invoke check_object_permission.

ViewSet and GenericView:
You don't have to worry about the permissions system, you just have to implement the permissions.

APIView:
If you are using an APIView within your method where you get the object, call self.check_object_permissions(self.request, obj) immediately after you get the object and before you perform any further actions. This will ensure that the permissions checks are properly enforced before any further operations are performed on the object.

Summary:

With an APIView, you must explicitly call check_object_permission to execute has_object_permission for all permission classes.
With ViewSets (like ModelViewSet) or Generic Views (like RetrieveAPIView), has_object_permission is executed via check_object_permission inside a get_object method out of the box.
has_object_permission is never executed for list views (regardless of the view you're extending from) or when the request method is POST (since the object doesn't exist yet).
When any has_permission returns False, the has_object_permission doesn't get checked. The request is immediately rejected.

1. Built-in permissions:
Django REST Framework are several built-in permissions that you can use for controlling access to your API views.

Here are the main ones:

AllowAny: This permission class allows unrestricted access, i. e., any user can perform any operation.
IsAuthenticated: This permission only allows access to authenticated users. Anonymous users will be denied access.
IsAdminUser: Grants access only to users with the is_staff attribute set to True.
IsAuthenticatedOrReadOnly: Allow read-only access to anonymous users and full access to authenticated users.
DjangoModelPermissions: This permission ties the access level to the model-level permissions set in Django admin.
DjangoModelPermissionsOrAnonReadOnly: Similar to DjangoModelPermissions, but allows read-only access to anonymous users.

These permissions can be applied to DRF's views and viewsets by setting the permission_classes attribute. For custom behaviour, you can also create your own permission classes by extending BasePermission.

2. Custom permissions:

If you need a custom permission, you will need to override one of the two BasePermission methods:

.has_permission(self, request, view)
.has_object_permission(self, request, view, obj)

The has_permission() method checks whether a user has the permission to perform a certain action on the API resource (view) or endpoint.

And the has_object_permission() method checks the permissions on a specific instance or object level. It is important to note that the has_object_permission() method is only called if the has_permission() method has granted access.

The method should return True to give access. By returning False a PermissionDenied exception will be raised.

To customise the error message that is raised when the permission is denied, you can implement a message attribute in your permission class.

from rest_framework import permissions

class CustomerAccessPermission(permissions.BasePermission):
    message = 'Adding customers not allowed.'

    def has_permission(self, request, view):
         ...

In general, you will want to create permissions for read or write operations.

Read operations are actions that retrieve data without modifying it. Methods such as GET, OPTIONS and HEAD are considered safe or read operations. These read operations (GET, OPTIONS and HEAD) can be checked using the SAFE_METHODS constant.

On the other hand, write operations are actions that change the state on the server by creating, updating or deleting data. Methods such as POST, PUT, PATCH and DELETE fall into this category.

if request.method in permissions.SAFE_METHODS:
    # Check permissions for read-only request
else:
    # Check permissions for write request

Here are some examples:

First example:

class IsAuthor(BasePermission):
    message = "You have to be the author to update or delete."

    def has_object_permission(self, request, view, obj):
        if request.method in SAFE_METHODS:
            return True

        return obj.author == request.user

In this example, I have not overridden the has_permission method. So the general permission or the view implemented permission is evaluated for access to the view. On the other hand, I want to make sure that only the author of the object (a project, issue or comment) has the permission to update or delete this object. Read operations, for this object, are allowed for other users. If permission is denied, the message attribute is set to deliver a customised message to the user.

Second example:

class UserPermission(BasePermission):
    def has_object_permission(self, request, view, obj):
        if not request.user.is_authenticated:
            return False

        if view.action in ["retrieve", "update", "partial_update"]:
            return (
                obj == request.user
            )  
        else:
            return False

In this example, the permission customisation is again at the object level. The first check is to see if the user is authenticated. If the user is an AnonymousUser (not authenticated), the permission is denied. The next check allows the user to retrieve, update or partial update their own data by verifying that specific view actions are met. All other view actions are denied.

- Django REST Framework Links:

Django REST Framework (DRF) - ModelViewSets

DoriDoro — Thu, 24 Oct 2024 15:38:40 +0000

Introduction:

A ModelViewSet in Django REST Framework (DRF) is a powerful view class that provides a set of common actions for working with models through an API. It combines the functionality of Django's generic views and viewsets, enabling you to quickly build CRUD (Create, Read, Update, Delete) APIs for your models without needing to manually define each individual action.

Key features of ModelViewSet:

Pre-built CRUD actions: It automatically provides the following actions:
- list - GET: Retrieves multiple objects of model instances.
- retrieve - GET: Retrieves a single model instance.
- create - POST: Creates a new model instance.
- update - PUT: Updates an existing model instance.
- partial_update - PATCH: Partially updates an existing model instance.
- destroy - DELETE: Deletes a model instance.
Automatic routing: When you use ModelViewSet with DRF's routers, URL routes are automatically generated for these actions.
Flexibility: You can easily customize or extend the default behavior by overriding methods or adding custom actions.

The queryset and serializer_class attributes are essential for using a ModelViewSet.

Here is a simple example of a ModelViewSet from the DRF documentation:

# app/views.py

class AccountViewSet(viewsets.ModelViewSet):
    queryset = Account.objects.all()
    serializer_class = AccountSerializer
    permission_classes = [IsAccountAdminOrReadOnly]

How can you customize your `ModelViewSet` and what do you need to be aware of?

You can use any of the standard attributes or method overrides that are provided by the GenericAPIView.

Here is a list of some of the key ones:

Standard Attributes:

queryset: The queryset that should be used for returning objects from this view.
serializer_class: Specifies the serializer class to use for validating and deserializing input, and for serializing output.
lookup_field: The model field that should be used to lookup objects. Defaults to 'pk'.
pagination_class: Pagination class to be used to paginate the list of objects.

Standard Methods:

get_queryset(): Returns the queryset that will be used to retrieve objects.
get_serializer_class(): Returns the class to use for the serializer.
get_serializer(): Returns the serializer instance that should be used for validating and deserializing input.
get_object(): Returns the object that this view is displaying.
get_serializer_context(): Can be overridden to change the context dictionary passed to the serializer instance.
filter_queryset(queryset): Given a queryset, filter it based on the view’s filtering configuration.
paginate_queryset(queryset): Paginate the given queryset, and return a page object.
get_pagination_response(data): Return a paginated style response for the given output data.
get_view_name(): Returns the view name that should be used as the title of the view.
get_view_description(): Returns the description to be used by browsable APIs and other descriptions.
get_renderer_context(): Creates a context dictionary for rendering.

1.) The get_queryset() method is overridden by the DRF documentation in this example.

# app/views.py

class AccountViewSet(viewsets.ModelViewSet):
    serializer_class = AccountSerializer
    permission_classes = [IsAccountAdminOrReadOnly]

    def get_queryset(self):
        return self.request.user.accounts.all()

The DRF documentation shows this example because if you override the get_queryset() method, you need to be aware that the basename in the router registry has to be set to a value. Normally DRF will automatically create the basename and set the value. It takes the values from the model name and creates the basename with the model name in lower case. In this case, you must set the basename to a value.

# project/urls.py

   from rest_framework import routers

   router = routers.SimpleRouter()
   router.register(r'accounts', AccountViewSet, basename='account')
   urlpatterns = router.urls

In the above example:

# app/views.py

class AccountViewSet(viewsets.ModelViewSet):
    queryset = Account.objects.all()
    serializer_class = AccountSerializer
    permission_classes = [IsAccountAdminOrReadOnly]

the basename is automatically set to basename='account'. It takes the model name of the queryset attribute Account and create a lower case name.

2.) Having multiple serializer classes:

Using a mixin is one way of generating multiple serializer classes. Why do I want to create multiple serializers?

Separation of Concerns: Different parts of an application may require different subsets of data. Multiple serializers allow you to fetch only the necessary data for each context, separating concerns.
Efficient Data Handling: By defining serializers specifically tailored to different API endpoints or logic, you can optimize data serialization/deserialization, improving performance and efficiency.
Security: Having different serializers lets you expose only the necessary fields to users who do not need full access to the data. This minimizes exposure to sensitive information.
Flexibility: Some API endpoints might need to validate data differently or handle it in a specific manner. Custom serializers provide the flexibility to add custom validation logic as needed.
Maintainability: Breaking down complex functionalities into simpler, smaller serializers makes the codebase easier to maintain. Each serializer handles a well-defined responsibility.

The serializer mixin can look like this:

# mixins.py

class SerializerClassMixin:
    serializer_create_class = None
    serializer_detail_class = None
    serializer_list_class = None

    def get_serializer_class(self):
        if self.action == "create":
            return self.serializer_create_class
        elif self.action == "retrieve":
            return self.serializer_detail_class
        elif self.action == "list":
            return self.serializer_list_class
        return super().get_serializer_class()

In a Django REST framework project, the self.action is an attribute that represents the current action being performed by a viewset. It is automatically set by Django REST framework based on the HTTP method of the request and the viewset's configuration.

This Mixin is designed to allow different serializers to be used in different situations within a single viewset:

serializer_create_class: Used when the create action is being performed.
serializer_detail_class: Used for the retrieve action, accessing a single instance.
serializer_list_class: Used when listing a collection of instances with the list action.

By using self.action, the get_serializer_class() method dynamically chooses which serializer class to use based on the current action. This can be very helpful in a scenario where you need different serializers for different operations on the same resource.

Here is an example of a view:

# views.py

from rest_framework.permissions import IsAuthenticated
from rest_framework.viewsets import ModelViewSet

from api.models.project import Project
from api.permissions import IsAuthor
from api.serializers.project import (
    ProjectCreateSerializer,
    ProjectListSerializer,
    ProjectDetailSerializer,
)
from api.views.mixins import SerializerClassMixin


class ProjectViewSet(SerializerClassMixin, ModelViewSet):
    serializer_class = ProjectCreateSerializer
    serializer_create_class = ProjectCreateSerializer
    serializer_detail_class = ProjectDetailSerializer
    serializer_list_class = ProjectListSerializer
    permission_classes = [IsAuthor, IsAuthenticated]

    _project = None

    @property
    def project(self):
        if self._project is None:
            self._project = Project.objects.filter(contributors=self.request.user)

        return self._project

    def get_queryset(self):
        # use order_by to avoid the warning for the pagination
        return self.project.order_by("created_time")

    def perform_create(self, serializer):
        # save the author as author and as contributor (request.user)
        serializer.save(author=self.request.user, contributors=[self.request.user])

In the ProjectViewSet we integrate the serializer mixin (SerializerClassMixin) to be able to use all the different serializers to list, create and display a detailed serializer.

We need to specify the basename in the URL pattern because we have overridden the get_queryset() method.

# urls.py

from rest_framework_nested import routers

from api.views.project import ProjectViewSet

app_name = "api"

router = routers.DefaultRouter()
router.register(r"projects", ProjectViewSet, basename="project")

Finally, there are the different serializers:

# serializers.py

from rest_framework import serializers

from api.models.project import Project


class ProjectCreateSerializer(serializers.ModelSerializer):
    class Meta:
        model = Project
        fields = [
            "id",
            "name",
            "description",
            "project_type",
        ]

    def validate(self, attrs):
        if (
            self.context["view"]
            .project.filter(name=attrs["name"], project_type=attrs["project_type"])
            .exists()
        ):
            raise serializers.ValidationError("Attention! This project exists already.")
        return attrs


class ProjectListSerializer(serializers.ModelSerializer):
    class Meta:
        model = Project
        fields = [
            "id",
            "name",
            "author",
            "contributors",
        ]


class ProjectDetailSerializer(serializers.ModelSerializer):
    class Meta:
        model = Project
        fields = [
            "id",
            "created_time",
            "name",
            "description",
            "project_type",
            "author",
            "contributors",
        ]

Link:
- ModelViewSets
- GenericViewSet
- GitHub repository: SoftDesk (Project 10 OpenClassrooms Path - SoftDesk -- create a secure RESTful API using Django REST framework)

DEV Community: DoriDoro

Cheat Sheet for all Django `on_delete` options

Django on_delete Cheat Sheet

When to Use What?

Example Code Snippets

Using JWT with Django REST Framework and Vue.js

Step-by-Step JWT Flow

What is `ContentFile` in Django?

Why is ContentFile Needed?

How Does ContentFile Work?

Why Is It Used in Your Code?

Breakdown of What Happens Here

What Would Happen Without ContentFile?

Final Takeaways

When Should You Use ContentFile?

Understanding creating an Authentication Backend in a Django project

Introduction

Why Use an Authentication Backend?

How Does It Work?

Configuring Authentication Backends in Django

Fixing Docker 'Permission Denied' Error on Ubuntu 24.04: A Step-by-Step Guide

Intrduction

What is the difference between INNER JOIN, LEFT JOIN and RIGHT JOIN in SQL?

Now, what is the difference between JOIN, LEFT JOIN and RIGHT JOIN in SQL?

Integrate Sentry into your Django project

Introduction

Django built-in authentication system

Introduction:

Create the Django project:

Ensure security of your project:

Creating a User model:

Setting the authentication URLs and creating custom authentication templates:

Login and Logout view:

How to create a simple Flask application

Introduction:

creating a simple Flask app

Django migration operations

1. migrations.RemoveField

2. migrations.DeleteModel

3. migrations.AlterModelTable

Summary of the Migration

Why Remove Fields and Delete the Model?

Connecting the 'Old' Database Table to a 'New' Model

Migration Sequence Explanation

What Happens Without This Sequence?

Key Takeaway

Django REST Framework (DRF) - permissions

Introduction

Django REST Framework (DRF) - ModelViewSets

Introduction:

Key features of ModelViewSet:

How can you customize your ModelViewSet and what do you need to be aware of?

Standard Attributes:

Standard Methods:

Django `on_delete` Cheat Sheet

Why is `ContentFile` Needed?

How Does `ContentFile` Work?

What Would Happen Without `ContentFile`?

When Should You Use `ContentFile`?

Now, what is the difference between `JOIN`, `LEFT JOIN` and `RIGHT JOIN` in SQL?

1. `migrations.RemoveField`

2. `migrations.DeleteModel`

3. `migrations.AlterModelTable`

How can you customize your `ModelViewSet` and what do you need to be aware of?