Всем здравия! Сегодня будет рассмотрена авторизация с помощью сессий между Django и React, которые находятся на разных доменах, т.е случай "cross-origin". Я в двух словах донесу принцип работы, причины появления концепций и технологий описанных здесь, оставлю ссылки на более подробные источники и приведу код конкретной реализации с объяснением своих шагов. Кого интересует полный код, он находится на GitHub.
Django *
Фреймворк для веб-приложений на Python
Новости
Мульти-тенант в Django
Привет, Хабр!
Мульти-тенант (multi-tenancy) — это подход, который позволяет одному экземпляру приложения обслуживать множество клиентов или арендаторов (тенатов). Каждый арендатор изолирован от других, имея возможность кастомизации под свои нужды, при этом основной кодовой базой и инфраструктурой делится между всеми.
Когда применять эту замечательную концепцию? Если говорить простыми словами, то мульти-тенант подход наиболее ценен для SaaS-продуктов, когда одно и то же приложение предоставляется разным клиентам, и каждый клиент работает со своим набором данных. Все это серьезно экономит ресурсы на обслуживание инфраструктуры, тк все изменения вносятся централизованно и мгновенно становятся доступны всем клиентам.
В Django мульти-тенант реализовывается довольно часто и для этого есть библиотека django-multitenant.
Лучший стек для питониста-джуна 2024 (2 часть)
Итак, что же поменялось за чуточку больше чем полгода? Если мы будем говорить об актуальности - ничего. Django до сих пор, а скорее всего так будет и всегда, остается "на плаву". Большая часть вакансий для back-end разработчика на Python имеет в себе требования по знаниям Django. Говорить вечно о том, что он удобен, постоянно поддерживаем, дает довольно обширный функционал и так далее - бессмысленно. Все основные моменты я упомянул в первой части.
Ладно, вступление в сторону! Лучше обсудить то, что изменилось с Django за это время.
Самое грандиозное из этого - выход Django 5! По сути скачок на пятую версию не принес в фреймворк особо крупных изменений, но парочку моментов хочу подчеркнуть. Первое и самое важное, на мой взгляд, это то, что разработчики решили добавить больше асинхронности без подключения таск-менеджеров. Для этого они добавили несколько декораторов и методов. Хотя это немного, на мой взгляд, противоречит самому принципу работы Django (напоминаю: Django синхронный фреймворк и для того, чтобы сделать очередь задач, нужно подключать таск-менеджеры, например, Celery), но тем не менее, это все равно крутой шаг в эволюцию. Надеюсь, что разработчики и дальше будут двигаться в этом направлении.
Далее, не могу не упомянуть очень важный момент - совместимость с Python. Django 5 будет работать только с версиями Python 3.10 и выше. Django 4.2.x - последняя версия, которая работает с Python 3.8 и 3.9.
Остальное я могу отнести в одну кучу: добавление фасетных фильтров в админке, упрощение шаблонов для отрисовки полей формы, прикольная, на мой взгляд, функция для значений по умолчанию, вычисленных базой данных, и еще пару приколюх с БД. Все остальное и более подробно вы сможете почитать в официальной документации. Я же не буду все разжевывать, так как отойду от темы статьи.
Некоторые антипаттерны проектирования в Django
Привет, Хабр!
В Джанге существует множество глубоко укоренившиеся привычек, которые кажутся правильными на первый взгляд, но в долгосрочной перспективе приводят к серьезным проблемам в производительности, масштабируемости и безопасности проекта. Эти решения могут казаться удобными костылями или временными фиксами, но на самом деле они создают технический долг, который со временем будет только расти, усложняя все с каждым разом.
Умение избегать этих привычек – это основополагающие элементы компетентности, гарантирующие, что проекты будут не только удобными для пользователя, но и устойчивыми к проблемам.
Истории
Как перевести Django-сайт на разные языки: плюсы, минусы, подводные камни
Рано или поздно любой сервис задумывается о расширении аудитории. И часто возникает вопрос языков, т.к. единого для всех стран не существует. В целом, это довольно стандартная задача для разработчиков, когда компания начинает работать на международную аудиторию. В случае с Django, который славится универсальностью, есть стандартное решение, но действительно ли оно хорошее, как можно его улучшить и с чем вообще придётся столкнуться во время процесса — обо всём этом расскажу. Меня зовут Камиль, я более трех лет был техническим директором и главным backend-программистом продукта Zonesmart, а с начала 2023 года продолжаю управлять разработкой этого продукта уже в составе Kokoc Group.
Время, как часть платформы ERP-систем
Всем привет!
Продолжаю публиковать странные и непонятные статьи.
Но вдруг, кому-то пригодится.
Поехали...
Хочется поговорить о времени, как о состоянии системы.
Но для начала нужна вводная: первая из них — временнАя переменная. С чего стартуем? Стартуем с дебага, как и я когда-то. Сидишь, трейсишь программу, и в дебаге у тебя есть несколько инструментов для похода по исходному коду: какой-нибудь step over, step into, run to cursor, step next. Ну, вроде все есть, но как бы: а где step back? Вы никогда не пролетали в отладке мимо того, что отлаживаете? И сколько раз приходилось перезапускать отладку? Может, я один такой… несчастливый?
Как раз, проблема в том, что обратные операции неочевидны. Процессоры, (может я и неправ, это просто гипотеза), не могут работать в обратном направлении по исходному коду. Операция степени в обратном направлении - это извлечение корня, например. Возможно, поэтому у нас нет такого очевидного и удобного, лично для меня, инструмента - как вернуться на строку назад от текущей…
Что может помочь? Например, какие-нибудь инструменты логирования. Мы берем область памяти, которая выделена для хранения значения переменной, и записываем в “блокнот”, что там происходит. В этом такте одно значение, в следующем другое… Мы формируем логи, так сказать.
Когда мы объявляем переменную, она будет “работать” с момента объявления до момента окончания работы исходного кода (выхода из подпрограммы или удаления этой переменной). Ее значение в процессе может быть многократно изменено без возможности восстановления. Обычно нас это устраивает, и значения в дебаге нас интересуют только в текущий момент. Обычно это говорит о том, что значение “вечно”, оно было таким всегда, даже если один такт назад это было не так.
Время, как часть платформы ERP-систем
Всем привет!
Продолжаю публиковать странные и непонятные статьи.
Но вдруг, кому-то пригодится.
Поехали...
Хочется поговорить о времени, как о состоянии системы.
Но для начала нужна вводная: первая из них — временнАя переменная. С чего стартуем? Стартуем с дебага, как и я когда-то. Сидишь, трейсишь программу, и в дебаге у тебя есть несколько инструментов для похода по исходному коду: какой-нибудь step over, step into, run to cursor, step next. Ну, вроде все есть, но как бы: а где step back? Вы никогда не пролетали в отладке мимо того, что отлаживаете? И сколько раз приходилось перезапускать отладку? Может, я один такой… несчастливый?
Как раз, проблема в том, что обратные операции неочевидны. Процессоры, (может я и неправ, это просто гипотеза), не могут работать в обратном направлении по исходному коду. Операция степени в обратном направлении - это извлечение корня, например. Возможно, поэтому у нас нет такого очевидного и удобного, лично для меня, инструмента - как вернуться на строку назад от текущей…
Что может помочь? Например, какие-нибудь инструменты логирования. Мы берем область памяти, которая выделена для хранения значения переменной, и записываем в “блокнот”, что там происходит. В этом такте одно значение, в следующем другое… Мы формируем логи, так сказать.
Когда мы объявляем переменную, она будет “работать” с момента объявления до момента окончания работы исходного кода (выхода из подпрограммы или удаления этой переменной). Ее значение в процессе может быть многократно изменено без возможности восстановления. Обычно нас это устраивает, и значения в дебаге нас интересуют только в текущий момент. Обычно это говорит о том, что значение “вечно”, оно было таким всегда, даже если один такт назад это было не так.
Авторизация в Django (DRF) и React по JWT-токену
Когда-то давно я уже делал авторизацию в Django и думал, что знаю о ней всё, но то была ошибка и оказалось, что я вообще ничего не знал и пользовался готовыми инструментами Django из коробки.
Когда я начал писать авторизацию для своего сайта, я столкнулся с тем, что в интернете есть информация и по JWT токену и по самой реализации авторизации, однако все реализации, найденные мною были нагромождены ненужным кодом, который мало относится к основной идее, либо одна из частей реализации будь то BackEnd или FrontEnd были плохо раскрыты. Поэтому я решил написать эту статью.
Django, PostgreSQL, Gunicorn/uWSGI, Nginx
Подробное описание шагов при деплое web-проекта на Django с PostgreSQL, Nginx, Gunicorn.
Задачи статьи - агрегировать информацию из мануалов по деплою, избавить читателя от повторений ошибок и описать теоретически, для чего делаются те или иные шаги, чтобы избежать бездумного копирования и вопросов "почему у меня не работает".
Переводы полей моделей Django + Vue
Всем привет! Это вторая статья из цикла статей о разработке приложений в нашей компании. В первой статье я рассказал Вам про общую архитектуру некоторых наших проектов. В данной статье хочется описать наши варианты решения часто встречающихся задач в рамках Django + Vue приложения.
Аутентификация, авторизация пользователей и единый вход (SSO) с использованием Django
В этой статье исследую технологию SSO. Начинаю с разбора концепций аутентификации и авторизации. Рассматриваю как они работаю в контексте Django.
После прохожу путь от описания как работает SSO простыми словами, до разбора протоколов используемых в SSO.
В итоге делаю реализацию SSO с Django, объединять Django и Keycloak.
TMS на замену TestRail: писали для себя, а выложили в open source
В прошлом году TestRail прекратил предоставлять и продлевать лицензии компаниям из России, поэтому мы в YADRO решили разработать собственную тест-менеджмент систему TestY. Опирались на опыт работы с другими сервисами, чтобы добавить тот функционал, которого не хватало нашим командам тестирования. За несколько месяцев написали core-часть системы и выложили ее в open source, чтобы другие компании и разработчики, для которых актуален вопрос лицензионной чистоты используемого софтай, пользовались решением и развивали его.
В этой статье рассказываем об отличиях TestY от других TMS и преимуществах нашей системы для команд любого размера. Спойлер: в TestY могут одновременно работать 300 тестировщиков — система справляется. Для тех, кто хочет опробовать TestY в своей команде, в конце статьи есть короткая инструкция, как ее развернуть.
Как мы делаем проекты
Все мы знаем что такое клиент-серверное приложение, на тему их создания написано не мало статей. В этой статье хотелось бы поделиться с вами наработками нашей компании, которыми мы пользуемся в своих Django проектах.
Ближайшие события
Как опубликовать свое первое приложение на Django и не упасть духом. Гайд для выпускников курсов
Я закончил курсы "Fullstack разработчик на Python" от одной известной компании. Обучение завершено успешно, но не было ощущения полноценности — на курсах не учили, как сделать самостоятельно деплой приложения на Django. И никто из студентов не задавался эти вопросом 😁
Так что я решил закрыть этот вопрос и все-таки пройти путь по развертыванию django-приложения, так как, возможно, больше никогда такого случая не представится. Потом я уже могу не вернуться к этой теме, так как это потребует мучительного вспоминания и повторного прохождения материала. Все должно быть вовремя.
В этой статье я хочу дать небольшой гайд для выпускников подобных курсов и заодно рассказать про российский облачный сервис (еще раз внимательно прочитал их статью и увидел, что она опубликована буквально за 3 недели до моих тестов - то есть мне повезло).
Обкатка альфа-теста и обновления на Капибаре
Сегодня у нас вышел второй официальный пост о прогрессе в разработке уже на самом сайте
Продолжу рассказывать о развитии Капибары, опенсорсном проекте, цели которого воспроизвести лучшее что было на пикабу и не наступить на их же "грабли". Первая часть здесь: https://habr.com/ru/articles/759598/. Вторая часть здесь: https://habr.com/ru/articles/773234/
🌟 Сегодня у нас в арсенале кое-что интересное. 🌟
Новый редактор
Как я написал программу для преданалитики клиентов
Привет! Меня зовут Александр Кулагин. Я не занимался разработкой профессионально, но заинтересовался созданием нейросетей. После изучения основ Python, NumPy и TensorFlow я захотел попрактиковаться на реальных задачах. Так я решил создать проект, который оценивает, какие компании потенциально заинтересованы в сотрудничестве с конкретным бизнесом.
В этой статье я расскажу о процессе создания проекта: от поиска заказчика и сбора данных до финального этапа — создания веб-интерфейса. Проект претерпевал много изменений, потому что реальность вносила коррективы: иногда у меня не хватало знаний, иногда изначальное решение просто нельзя было применить.
Руководство по кэшированию в Django
В этой статье поговорим о том, что такое кэширование и о его преимуществах, как настроить кэширование в Django, какие бэкенд-системы поддерживают Django, а также о лучших практиках кэширования. Материал будет полезен в первую очередь начинающим веб-разработчикам.
Запуск альфа-теста Капибара(Новый Старый Пикабу)
Продолжу рассказывать о развитии Капибары, опенсорсном проекте, цели которого воспроизвести лучшее что было на пикабу и не наступить на их же "грабли". Первая часть здесь: https://habr.com/ru/articles/759598/. Первый официальный пост о прогрессе в разработке на новом сайте здесь: https://www.kapi.bar/post/dnevnik-razrabotki-kapibary-ot-10-xi-2023. Но обо всем по порядку.
Пару недель назад у нас стартанул полу-закрытый альфа-тест. Сейчас выдаём ранний доступ на сайт kapi.bar отважным авторам-альфатестировщикам и активным комментаторам взамен просим слать нам багрепорты и пока быть самим себе модераторами. Функционал для создания постов, комментариев и выставления оценок для них есть. Ленты "Новое", "Тренды", "Топ", "Обсуждаемое" и поиск по тегам уже работают и доступны для чтения всем желающим.
Gryffine — история одного пет-проекта
Как-то раз один знакомый сисадмин пожаловался мне на жизнь суровую. Он рассказал об одном инциденте в его конторе. Стоит оговориться, что контора небольшая и такой сущности как отдельный специалист по информационной безопасности там нет. Инцидент стандартный до банальности. Случайно заметили аномальную активность на линуксовых серверах. Подозрения сразу же подтвердились выводом команды who, который показал подключение по ssh с прокси-сервера с IP одной маленькой, но очень гордой страны. Дальше было то, что и положено в таких ситуациях, а именно: сменить доступы, понять откуда зараза по сети пошла, и что именно она делала. Доступы сменили, а вот когда полезли в логи, с удивлением обнаружил, что они уже несколько дней как пишутся в /dev/null, то есть у злоумышленника на сервере был root-доступ. Позже выяснили, что причиной была утечка пароля от аккаунта одного из сотрудников с доступом к sudo.
История, в общем-то, типичная, тысячи таких. Но меня она зацепила и побудила задаться вопросом: а как, собственно поймать хакера в тот самый момент, когда он попал на сервер впервые и пытается там закрепиться? Возможно, существуют enterprise-решения аудита и мониторинга входа на удалённую машину, но даже крупный бизнес с неохотой тратится на инфобез. Не говоря уже о небольших конторах с IT-отделом в 3,5 человека. Будем делать всё сами, благо в линуксах требуемая функциональность есть практически из коробки.
Взлетаем на backend: наш путь к победе в номинации «Лучший backend-разработчик» на хакатоне от ООО «Лента» и ЯП
«Недоджун» решил проверить свои силы и поучаствовать в хакатоне, который организовали Яндекс Практикум и ООО «Лента».
Вклад авторов
Azy 295.0kmike 276.0shulyndina 255.0fata1ex 247.6grigoryvp 241.0Dreadatour 220.0junk 194.0printf 186.0kesn 180.0marazm 170.0