Django Two Factor Face Auth — это модуль аутентификации, который обеспечивает дополнительный уровень безопасности с помощью распознавания лиц. Модуль предоставляет как внутренний, так и внешний код, необходимый для регистрации и регистрации пользователя с обнаружением и распознаванием лиц. Построен с использованием face_conition и ‘Современное распознавание лиц, построенное с глубоким обучением. Модель имеет точность 99,38% на метках Faces в диком тесте. Быстрый старт Добавьте «django-two-factor-face-auth» в настройку INSTALLED_APPS следующим образом: INSTALLED_APPS = [ … ‘django_two_factor_face_auth’, ] Включите URLconf django-two-factor-face-auth в ваш проект urls.py следующим образом: путь ( ‘/’, включает ( ‘django_two_factor_face_auth.urls’ ) ), запустить python manage.py migrate создать модели django-two-factor-face-auth. Теперь вы можете запустить сервер и получить доступ accounts/register ( создать новую учетную запись с идентификатором лица ) и accounts/login URL ( для входа в систему с использованием имени пользователя / пароля и идентификатора лица ) Прочитайте подробную документацию, чтобы переопределить шаблоны по умолчанию и правильно настроить приложение Статья взята с сайта: https://github.com/filipzelic/django-two-factor-face-auth
Бэкэндс аутентификации позволяет изменить метод проверки учетных данных ваших пользователей. Для веб-сервисов, то есть аутентификации Facebook, у вас нет доступа к пользовательским данным, таким как пароль. Без пароля ( не похоже на случайную строку ) мы не сможем создать пользователя в django. Подключение Facebook предоставляет вам информацию о текущем аутентифицированном пользователе. Бэкэндс аутентификации позволяет изменить метод проверки учетных данных ваших пользователей. Пример использования пользовательского бэкэнда аутентификации: Для веб-сервисов, то есть аутентификации Facebook, у вас нет доступа к пользовательским данным, таким как пароль. Без пароля ( не похоже на случайную строку ) мы не сможем создать пользователя в Джанго. Подключение Facebook предоставляет вам информацию о текущем аутентифицированном пользователе. Но для поддержания декоратора login_required или пользователя request.user вам все равно нужно, чтобы они вошли в систему с помощью Django. Вот где приходит бэкэнд аутентификации. from django.contrib.auth.backends import ModelBackend from peeldb.models import User class PasswordlessAuthBackend(ModelBackend): «»»Log in to Django without providing a password. «»»… Читать далее »
Выдалось свободное время, чтобы подкорректировать личные сообщения на сайте. Данный функционал используется не особо часто, поэтому не прилагаю больших усилий к его улучшению, хотя пора уже привести данный функционал к адекватной работе. Раньше имелась очень большая недоработка, которая заключалась в том, что не показывался счётчик диалогов с непрочитанными сообщениями, что приводило к тому, что пользователей, которому присылали сообщение, просто не обращал на него внимания, поскольку не знал об этом сообщений. Теперь я наконец исправил этот недостаток. И в рамках предыдущего кода покажу, какие были добавлены исправления. Я размышлял над двумя вариантами организации счётчиков непрочитанных сообщений. Вернее одним вариантов и его более продвинутой версией. При каждом запросе проверять все чаты, выбирать из них последние сообщения и проверять, является ли автором авторизованный пользователь, для которого нужно проверить данное сообщение. Если он не является автором, то проверяем, прочитано ли данное сообщение, если нет, то данный диалог для данного пользователя считаем непрочитанных. Количество таких диалогов будем считать… Читать далее »
По сложившейся традиции расскажу о своих опытах по внедрению нового функционала на сайте. На данный момент этим функционалом являются личные сообщения между пользователями. Конечно, это сейчас работает не так хорошо, как в известных социальных сетях… но в итоге всё будет работать. Главное фидбек на форуме , пожалуйста. Итак. Очень хотелось добавить личные сообщения на сайте, тем более, что я уже обмолвился об этом полгода назад. Оставался вопрос, как вообще это реализовать. При поиске по интернету удалось наткнуться на вариант, когда формируется следующая модель данных. Id сообщения from_user — отправитель to_user — получатель pub_date — дата сообщения message — контент сообщения Попытался реализовать данный вариант, но меня остановило то, что вдруг после личных сообщений я захочу сделать чаты? Так почему бы сразу не заложить основу для чатов? Модели Chat и Message Это был бы отличный вариант для дальнейшего развития ресурса. Но в данном случае требуется создать две модели Chat и Message . # -*- coding: utf-8 -*- from django.db import models from… Читать далее »
Для создания дампа БД PostgreSQL следует использовать в консоли SSH команду следующего вида: pg_dump -h hostname -U username -F format -f dumpfile dbname где: hostname — имя сервера БД; username — имя пользователя БД (совпадает с именем базы данных); format — формат дампа (может быть одной из трех букв: ‘с’ (custom — архив .tar.gz), ‘t’ (tar — tar-файл), ‘p’ (plain — текстовый файл). В команде букву надо указывать без кавычек.); dumpfile — имя создаваемого файла дампа; dbname — имя базы данных. Для баз созданных до 16.09.2019 имя хоста будет выглядеть так: pg.sweb.ru; для баз данных, которые были созданы после 16.09.2019 имя хоста будет таким: pg2.sweb.ru. После завершения задачи файл с именем dumpfile будет размещен в директории, из которой запускалась команда. Пример создания дампа базы vh36sup в файл архива формата postgress. где custom — архив, в формате самого postgress. pg_dump -h pg2.sweb.ru -U vh36sup -F c -f dump.tar.gz vhsup ИМПОРТ ДАМПА БД POSTGRESQL Для импорта необходимо использовать команду вида: pg_restore -h hostname -U… Читать далее »
Используя pickle для QuerySet, будет выполнен запрос к базе данных что бы загрузить данные в память для сериализации. Сериализация обычно используется перед кэшированием QuerySet или загрузкой из кеша, необходимо что бы результат был доступен для использования сразу после загрузки (чтение с базы данных занимает некоторое время, что свело бы всю пользу кэширования к нулю). Это означает что после восстановления сериализованного QuerySet, он будет содержать результат на момент сериализации, а не тот, который хранится в базе данных на текущий момент. Если вам необходимо сохранить запрос выполняемый QuerySet, что бы получить данные позже, сериализируйте атрибут query QuerySet. Позже вы можете воссоздать первоначальный QuerySet (без загрузки результата) используя такой код: >>> import pickle >>> query = pickle.loads(s) >>> qs = MyModel.objects.all() >>> qs.query = query # Получить оригинальный ‘запрос’. Атрибут query не является частью публичного API, и является частью внутреннего механизма создания запросов. Однако, поддерживает использование pickle и unpickle как показано в примере выше. Сериализация QuerySets возможна только для версии Django, которая была использована при сохранении объекта. При сериализации объекта в версии… Читать далее »
В этой части серии мы рассмотрим важнейший подход к обеспечению высокой производительности — кэширование. Суть кэширования в том, чтобы размещать часто используемые данные в быстром хранилище для ускорения доступа к ним. Важно понять, что быстрое хранилище (например, оперативная память) часто имеет очень ограниченный объем и его нужно использовать для хранения только тех данных, которые с большой вероятностью будут запрошены. Кэш фреймворк Django Django предоставляет ряд средств для кэширования из коробки. Хранилище кэша настраивается при помощи словаря CACHES в settings.py: CACHES = { «default»: { «BACKEND»: «django.core.cache.backends.db.DatabaseCache», «LOCATION»: «my_cache_table», } } Django предоставляет несколько встроенных бекендов для кэша, рассмотрим некоторые из них: DummyCache — ничего не кэширует, используется при разработке/тестировании, если нужно временно отключить кэширование, DatabaseCache — хранит кэш в БД, не самый быстрый вариант, но может быть полезен для хранения результатов долгих вычислений или сложных SQL запросов, MemcachedCache — использует Memcached в качестве хранилища, для использования этого бекенда вам понадобится поднять сервер(ы) Memcached. Для использования в продакшене лучше… Читать далее »
Это продолжение серии статей про оптимизацию Django приложений. Первая часть доступна здесь и рассказывает о профилировании и настройках Django. В этой части мы рассмотрим оптимизацию работы с базой данных (модели Django). В этой части часто будет использоваться логирование SQL запросов и DDT, про которые написано в первом посте. Работа с базой данных во всех примерах будет использоваться PostgreSQL, но для пользователей других СУБД большая часть статьи также будет актуальна. Примеры в этой части будут основаны на простом приложении блога, которое мы будем разрабатывать и оптимизировать по ходу статьи. Начнем с следующих моделей: from django.db import models class Tag(models.Model): name = models.CharField(max_length=64) def __str__(self): return self.name class Author(models.Model): username = models.CharField(max_length=64) email = models.EmailField() bio = models.TextField() def __str__(self): return self.username class Article(models.Model): title = models.CharField(max_length=64) content = models.TextField() created_at = models.DateField() author = models.ForeignKey(Author) tags = models.ManyToManyField(Tag) def __str__(self): return self.title Весь код доступен на GitHub с разбивкой по тегам. Массовые изменения Массовая вставка Предположим,… Читать далее »
Для получения значений из модели Django и дальнейшего их использования и манипуляций с ними можно воспользоваться подобным простеньким скриптом. Я использовал его для создания формы фильтрации по всем полям и приводил типы к виду для html разметки: type_filter ={ ‘CharField’: ‘text’, ‘TextField’: ‘textarea’, ‘IntegerField’: ‘IntegerField’, ‘DateField’: ‘DateField’, ‘AutoField’: », ‘ForeignKey’: » } your_fields = Your_model._meta.local_fields filter = dict() for f in your_fields: if type_filter[f.get_internal_type()]: filter[f.name] = { ‘name’: f.verbose_name, ‘type’: type_filter[f.get_internal_type()] }
Это первая статья из серии, здесь будут рассмотрено профилирование и настройки Django. Django это мощный фреймворк используемый в множестве отличных проектов. Из коробки в нем включено много полезных батареек, которые значительно ускоряют разработку и соответственно уменьшают ее стоимость. Однако, когда проект растет и набирает аудиторию, вы неизбежно столкнетесь с проблемами производительности. В этом посте я попробую рассказать о том с какими проблемами вы можете столкнуться и как их решить. Профилирование Перед тем выполнять оптимизацию необходимо измерить текущую производительность, чтобы после оптимизации можно было сравнить результаты. Такие измерения нужно будет делать часто, после каждого изменения, так что процесс должен быть автоматизированным. Профилирование — это процесс измерения метрик проекта. Таких как: время ответа сервера, использование CPU, использование памяти и тд. Python предоставляет профайлер в стандартной библиотеке, который вполне удобно использовать для измерения производительности кусков кода. Но для профилирования целового проекта существуют более удобные решения. Логирование Самая частая проблема производительности это лишние и/или не эффективные… Читать далее »