Python Django

⚡️ Базовая аутентификация в 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/

🖥 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/

📌 Первые впечатления от системы фоновых задач в 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-проекта? Разработка крупного Python-проекта требует продуманной архитектуры. Правильная структура кода упрощает развитие, тестирование и поддержку приложения. В этой статье мы рассмотрим ключевые принципы архитектурной организации для разных типов проектов - веб-приложений, библиотек, микросервисов и систем обработки данных. Обсудим разделение системы на слои (domain, service, infrastructure), использование популярных шаблонов проектирования (Dependency Injection, Repository, Facade), организацию кода по модулям и пакетам, примеры структуры каталогов, работу с зависимостями и конфигурацией (Pydantic, dotenv), логгирование и мониторинг, обеспечение тестируемости, поддержку расширяемости и модульности. Также приведем примеры кода и структуры каталогов, а в конце – общие советы и распространенные ошибки, которых следует избегать. https://uproger.com/kak-organizovat-arhitekturu-bolshogo-python-proekta/

🚀 django-keel - мощный стартовый шаблон для Django-проектов 💡 Что это такое Готовый современный каркас для Django-приложений, который позволяет запускать новый проект за минуты — с правильной архитектурой, CI, Docker и продуманной конфигурацией. 🔥 Что внутри - Поддержка Python 3.12+ и Django 5.2+ - Несколько видов проектов: SaaS, API-backend, web-app, internal tools - Docker + Docker Compose - Настроенные линтеры, тесты, coverage и GitHub Actions - 12-factor конфигурация, разделённые settings (dev/test/prod) - Варианты API: DRF или GraphQL - Поддержка фронта: Next.js или HTMX + Tailwind 🎯 Почему стоит использовать - Экономит недели рутинной настройки - Даёт единообразную и поддерживаемую архитектуру - Ускоряет разработку MVP, внутренних сервисов и SaaS-продуктов 🛠 Быстрый старт

    
        
copier copy gh:CuriousLearner/django-keel my-project
{}
    

Репозиторий: https://github.com/CuriousLearner/django-keel

🔥 Подборка полезных ресурсов для программистов. Здесь ты найдёшь всё это - коротко, по делу и без воды. Пока другие ищут, где “подглядеть решение”, ты уже используешь самые свежие инструменты! AI: t.me/ai_machinelearning_big_data Python: t.me/pythonl Linux: t.me/linuxacademiya Devops: t.me/DevOPSitsec Собеседования DS: t.me/machinelearning_interview C++ t.me/cpluspluc Docker: t.me/DevopsDocker Хакинг: t.me/linuxkalii Data Science: t.me/data_analysis_ml Javascript: t.me/javascriptv C#: t.me/csharp_1001_notes Java: t.me/java_library Базы данных: t.me/sqlhub Python собеседования: t.me/python_job_interview Мобильная разработка: t.me/mobdevelop Golang: t.me/Golang_google React: t.me/react_tg Rust: t.me/rust_code ИИ: t.me/vistehno PHP: t.me/phpshka Android: t.me/android_its Frontend: t.me/front Big Data: t.me/bigdatai МАТЕМАТИКА: t.me/data_math Kubernets: t.me/kubernetc Разработка игр: https://t.me/gamedev Haskell: t.me/haskell_tg Физика: t.me/fizmat 💼 Папка с вакансиями: t.me/addlist/_zyy_jQ_QUsyM2Vi Папка Go разработчика: t.me/addlist/MUtJEeJSxeY2YTFi Папка Python разработчика: t.me/addlist/eEPya-HF6mkxMGIy Папка ML: https://t.me/addlist/2Ls-snqEeytkMDgy Папка FRONTEND: https://t.me/addlist/mzMMG3RPZhY2M2Iy Папка Linux:https://t.me/addlist/w4Doot-XBG4xNzYy 😆ИТ-Мемы: t.me/memes_prog 🇬🇧Английский: t.me/english_forprogrammers 🧠ИИ: t.me/vistehno 🎓954ГБ ОПЕНСОРС КУРСОВ: @courses 📕Ит-книги бесплатно: https://t.me/addlist/BkskQciUW_FhNjEy Сохрани себе, чтобы не потерять!

Почему «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/

👩‍💻 django-cors-headers — Django-приложение для обработки заголовков Cross-Origin Resource Sharing (CORS)! 🌟 Этот инструмент позволяет вашему Django-приложению принимать запросы из браузеров, отправленные с других доменов. Это особенно полезно для API-серверов или приложений, которые обслуживают фронтенд и бэкенд с разных доменов или портов. 🌟 Инструмент позволяет гибко управлять настройками CORS, включая поддержку конкретных методов, заголовков и настроек безопасности. Например, вы можете настроить разрешение только для определённых доменов или включить временный доступ для локальной разработки. Однако важно понимать риски, связанные с CORS, поскольку неправильная конфигурация может открыть доступ к вашим данным для нежелательных источников. 🔐 Лицензия: MIT 🖥 Github @python_job_interview