Python_Times

‍⚡️ Базовая аутентификация в Django: как сделать правильно

В статье рассматривается, как настроить базовую (Basic) аутентификацию в Django для API и защищённых ресурсов.

Что такое Basic Authentication
Это самый простой способ аутентификации по HTTP: клиент отправляет логин и пароль в заголовке Authorization: Basic …, закодированные в base64. Подходит для API, но требует HTTPS, так как пароль передаётся в каждом запросе.

Django по умолчанию не предоставляет Basic Auth для view-функций. Он есть только в Django REST Framework. Если нужен собственный API или простая защита эндпоинтов без DRF — придётся реализовать самому.

Подход из статьи
Автор показывает, как создать middleware или декоратор, который:
- проверяет заголовок Authorization
- декодирует базу64
- валидирует логин/пароль
- возвращает 401 Unauthorized, если аутентификация не прошла

Пример (упрощённо):
1) Извлекаем заголовок
2) Проверяем, что он начинается с Basic
3) Декодируем base64
4) Сравниваем с нужными учётками

Для Django-view это можно обернуть в декоратор и использовать так:

@basic_auth_required
def my_view(request):
…


Плюсы
– очень лёгкий способ защитить API
– работает без дополнительных библиотек
– гибко настраивается

Минусы
– нет сессий, токенов, CSRF и других продвинутых схем
– подходит только под HTTPS
– пароль передаётся в каждом запросе

Кому полезно
Если нужен простой API или внутренняя служба, где полноценный OAuth/JWT:

https://adamj.eu/tech/2025/12/08/django-basic-authentication/

@python_times

‍🖥 Django 6.0 вышел - крупное обновление фреймворка

Вышел Django 6.0, и это одно из самых насыщенных обновлений за последнее время. Релиз добавляет функциональность, которую разработчики долго закрывали сторонними библиотеками или кастомными решениями.

Что нового и действительно важно:

Поддержка template partials из коробки
Теперь Django умеет частичные шаблоны на уровне фреймворка. Это упрощает структуру HTML, повышает переиспользуемость и делает шаблоны чище и понятнее без лишних include-хаков.

Нативный фреймворк для фоновых задач
В Django появился встроенный механизм для background tasks. Для многих проектов это означает, что Celery или RQ больше не обязательны для базовых задач — отложенные и асинхронные операции можно реализовать стандартными средствами.

Встроенная система Content Security Policy (CSP)
Django 6.0 получил полноценную поддержку CSP. Это серьёзный шаг в сторону безопасности по умолчанию и защита от XSS и других атак без внешних middleware.

Современный email API с нормальной Unicode-поддержкой
Работа с email стала более предсказуемой и дружелюбной к Unicode, что особенно важно для международных проектов и сложных шаблонов писем.

Жизненный цикл версий
Django 5.2 больше не имеет mainstream-поддержки. Разработчикам рекомендуется переходить на 6.0, чтобы получать новые возможности, обновления безопасности и улучшения платформы.

Django продолжает двигаться в сторону «batteries included», но делает это аккуратно и прагматично. Django 6.0 снижает зависимость от внешних библиотек, усиливает безопасность и делает повседневную разработку заметно удобнее.

Это релиз, который стоит внимательно изучить и запланировать апгрейд.

https://www.djangoproject.com/weblog/2025/dec/03/django-60-released/

@python_times

‍📌 Первые впечатления от системы фоновых задач в Django

В свежем разборе объясняется, как Django наконец получает встроенный инструмент для фоновой обработки заданий без необходимости тянуть сторонние библиотеки вроде Celery.

🔹 Что это такое
Django Background Tasks - новый официально поддерживаемый механизм для:
- отложенного выполнения задач (delayed jobs),
- периодических задач (cron-style),
- асинхронной фоновой обработки в рамках приложения.

🔹 Почему это важно
Раньше разработчикам приходилось выбирать сторонние решения (Celery, RQ, Dramatiq) с дополнительной инфраструктурой (Redis/RabbitMQ и т.п.). Теперь у Django будет собственный, простой и интегрированный способ:
- выполнять задачи после ответа пользователю,
- обрабатывать тяжёлые операции вне запроса,
- запускать периодические задачи без внешних кронов.

🔹 Как это работает
- Вы определяете задачу как обычную Python-функцию.
- Django регистрирует её в очереди внутреннего раннера.
- Фоновый воркер выполняет такие задачи по расписанию или сразу - без внешнего брокера.

🔹 Плюсы по сравнению с альтернативами
✔ встроенная интеграция с ORM и Django-экосистемой
✔ нет необходимости настраивать отдельный брокер
✔ ожидаемая простота и знакомый синтаксис для Django-разработчиков

🔹 О чём ещё в статье
- примеры кода с определением фоновых задач;
- как запускать и мониторить воркеры;
- ограничения и когда всё же стоит использовать более мощные системы.

📌 В сумме: Django делает шаг к тому, чтобы базовая фонвая обработка стала простой и доступной из коробки - это ускоряет разработку и снижает операционную сложность для большинства проектов.

https://roam.be/notes/2025/a-first-look-at-djangos-new-background-tasks/

@python_times

‍Почему «Async Django» часто решает не ту проблему

Django теперь умеет ASGI и async-views, но автор статьи отмечает: переход на async сам по себе почти ничего не ускоряет. Чтобы получить выгоду, весь код должен быть переписан под асинхронность, а в реальных проектах прирост обычно минимальный.

Где async реально нужен?
В задачах с большим количеством ожидания: внешние API, WebSockets, стриминг ответов. Там async даёт ощутимую экономию.

Но есть нюанс:
Django стал «двухрежимным» фреймворком - синхронные и асинхронные части живут рядом, усложняя архитектуру. ORM всё ещё в основном синхронная, и это становится бутылочным горлышком.

Поэтому для большинства проектов выгоднее оставить sync Django и вынести тяжёлые операции в фоновые задачи (Celery, RQ). Это проще, надёжнее и предсказуемее.

Итог:
Async Django - круто с инженерной точки зрения, но бизнес-ценность есть далеко не в каждом сценарии. Для большинства приложений классический Django остаётся лучшим выбором.


https://www.loopwerk.io/articles/2025/async-django-why/

@python_times

‍🔥 Как я пишу Django views

Автор предлагает использовать базовый класс Django View вместо generic class-based views (CBV) или function-based views (FBV). Такой подход даёт простоту и гибкость при работе с HTTP-запросами. Отказ от сложных миксинов и использование понятных вспомогательных методов делает код более читаемым и сопровождаемым, снижая когнитивную нагрузку на разработчика.

Ключевые идеи

- В Django есть два популярных способа писать views: FBV (функции) и CBV (классы, включая generic views).
- Generic CBV часто содержат слишком много "магии": базовые классы, миксины, переопределяемые методы — их трудно держать в голове.
- FBV наглядны, но при усложнении логики код превращается в большие конструкции if request.method == ....
- Автор выбирает компромисс: использовать базовый класс View.
- Код остаётся простым.
- Логика neatly разделяется по методам (`get`, post и др.).
- Неподдерживаемые методы автоматически возвращают 405 (Method Not Allowed).

Пример

Вместо функции с if request.method:


class CommentFormView(View):
def get(self, request, post_id, *args, **kwargs):
post = get_object_or_404(Post, pk=post_id)
form = CommentForm()
return TemplateResponse(request, "form.html", {"form": form, "post": post})

def post(self, request, post_id, *args, **kwargs):
post = get_object_or_404(Post, pk=post_id)
form = CommentForm(data=request.POST)
if form.is_valid():
comment = form.save(commit=False)
comment.post = post
comment.save()
return redirect(post)
return TemplateResponse(request, "form.html", {"form": form, "post": post})


👉 Источник: https://loopwerk.io/articles/2025/django-views/

@python_times

‍🖥 rest-filters — фильтрационный бэкенд для Django REST framework

Что это:
Новый инструмент для фильтрации в DRF, который расширяет возможности стандартного django-filter.

Особенности
- Использует serializer-поля для разбора и валидации (без Django-форм и виджетов)
- Поддержка группировки фильтров для гибкой логики
- Constraint system — проверка взаимозависимостей между параметрами
- Вложенные фильтры (nested filters) для работы со сложными структурами


Последний релиз — v0.6.0 (21 августа 2025)
- Возможность указывать группу по умолчанию для всего FilterSet (в том числе глобально)
- Поддержка subgroups для более сложных связей между фильтрами
- Новый метод FilterSet.get_combinator() для динамического выбора способа объединения фильтров
- ⚠️ Breaking change: теперь Entry нельзя создавать без указания группы

Почему стоит попробовать
Если стандартные фильтры Django REST кажутся ограниченными, rest-filters даёт:
- фильтрацию через сериализаторы,
- сложные сценарии с группировками и вложенностью,
- гибкость и расширяемость.

🔗 Репозиторий: https://github.com/realsuayip/rest-filters

@python_times

🔍 Django ModelSearch: Умный поиск для ваших моделей

Django ModelSearch позволяет индексировать модели Django и осуществлять поиск с использованием ORM. Поддерживает PostgreSQL FTS, SQLite FTS5, а также Elasticsearch и OpenSearch. Идеально подходит для создания мощных поисковых решений.

🚀Основные моменты:
- Индексация моделей в Elasticsearch и OpenSearch
- Поддержка автозаполнения и фацетного поиска
- Повторное использование существующих QuerySets
- Поддержка нечеткого и фразового поиска
- Нулевая простоя при перестройке индекса

📌 GitHub:

@python_times

https://github.com/kaedroho/django-modelsearch

🖥 Разбираем Новые версии: Django 5.2.5 (https://docs.djangoproject.com/en/5.2/releases/5.2.5/)и Python 3.13.6 (https://docs.python.org/3/whatsnew/changelog.html#python-3-13-6)

Django 5.2.5 (релиз — 6 августа 2025)
- Тип релиза: патч-релиз, устраняющий ошибки версии 5.2.4.
- Ключевые исправления:
- Восстановлена поддержка стратегии UNNEST в QuerySet.bulk_create() для PostgreSQL.
- Улучшена фильтрация по составному первичному ключу через tuple-выражения.
- Исправлены ошибки валидации модели при использовании GeneratedField, Q и Case.
- Добавлена совместимость с docutils версии 0.22.
- Исправлен сбой при использовании ManyToManyField с составным первичным ключом — обновлены проверки fields.E347.

Python 3.13.6 (релиз — 6 августа 2025)
- Тип релиза: шестой maintenance-релиз ветки 3.13, включает около 200 исправлений, улучшений сборки и обновлений документации.
- Ключевые особенности Python 3.13 по сравнению с 3.12:
- Новый усовершенствованный REPL с многострочным редактированием, цветным выводом и цветными трассировками ошибок.
- Экспериментальный free-threaded build mode (отключение GIL), доступен в виде python3.13t`/`python3.13t.exe.
- Встроенный экспериментальный JIT-компилятор (по-умолчанию отключён).
- locals() теперь имеет определённые семантики при мутации возвращаемого словаря.
- Включена изменённая версия mimalloc (по-умолчанию, если доступно), обязательна для free-threaded режима.
- Докстринги теперь очищаются от начальной отступной, что снижает объём `.pyc`-файлов.
- Новый бэкенд dbm.sqlite3 используется по умолчанию при создании файлов.
- Минимальная поддерживаемая версия macOS повысилась до 10.13 (High Sierra).
- Безопасность:
- Исправлена проблема, при которой фильтры filter="data" и filter="tar" в tarfile можно было обойти с помощью специально созданных сим- и жёстких ссылок.

Вывод:
- Django 5.2.5 — важный патч-релиз LTS-ветки, рекомендован для обновления производственных систем.
- Python 3.13.6 — очередной maintenance-релиз с множеством багфиксов и улучшений, особенно интересен разработчикам, работающим с производительностью (REPL, JIT, free-threaded).

Если нужно, могу подсказать, как безопасно обновиться или протестировать эти версии в вашем проекте.

@python_times

‍🎯 django-rls — декларативный Row-Level Security для Django + PostgreSQL

Пакет от [kdpisda](https://github.com/kdpisda/django-rls), который позволяет удобно задавать политики Row-Level Security (RLS) прямо внутри моделей Django — с генерацией SQL-политик на этапе makemigrations.

🔐 Основные возможности:
- Объявление RLS-политик в моделях (через класс `RLS`)
- Автоматическая генерация SQL-политик при миграциях
- Поддержка многотенантности (tenant_id)
- Совместимость с Django ORM и PostgreSQL

📦 Пример использования:


class Invoice(RLSModel):
customer = models.ForeignKey(Customer, on_delete=models.CASCADE)

class RLS:
policies = [
RLSPolicy(
name="tenant_isolation",
using="customer_id = current_setting('myapp.tenant_id')::integer"
)
]

📌 При makemigrations будут сгенерированы команды:

sql

CREATE POLICY tenant_isolation ON invoice
USING (customer_id = current_setting('myapp.tenant_id')::integer);
ALTER TABLE invoice ENABLE ROW LEVEL SECURITY;
🛠️ Установка:

bash

pip install django-rls
📚 Документация и исходники:

GitHub → github.com/kdpisda/django-rls

Идеально для: Django-проектов с многотенантной архитектурой и требованиями к безопасности на уровне данных.

@python_times