Архив рубрики: Python

В данном разделе размещены заметки по работе с python, которые могут помочь вам в работе с написанием кода и модулей на популярном языке программирования! Читаем и учимся!

Django Two Factor Face Authentication

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

Пользовательская аутентификация без пароля в Django

Бэкэндс аутентификации позволяет изменить метод проверки учетных данных ваших пользователей. Для веб-сервисов, то есть аутентификации 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. «»»… Читать далее »

Добавление личных сообщений и чатов на сайте — Часть 2 (Счётчик диалогов и чатов с непрочитанными сообщениями)

Выдалось свободное время, чтобы подкорректировать личные сообщения на сайте. Данный функционал используется не особо часто, поэтому не прилагаю больших усилий к его улучшению, хотя пора уже привести данный функционал к адекватной работе. Раньше имелась очень большая недоработка, которая заключалась в том, что не показывался счётчик диалогов с непрочитанными сообщениями, что приводило к тому, что пользователей, которому присылали сообщение, просто не обращал на него внимания, поскольку не знал об этом сообщений. Теперь я наконец исправил этот недостаток. И в рамках предыдущего кода покажу, какие были добавлены исправления. Я размышлял над двумя вариантами организации счётчиков непрочитанных сообщений. Вернее одним вариантов и его более продвинутой версией. При каждом запросе проверять все чаты, выбирать из них последние сообщения и проверять, является ли автором авторизованный пользователь, для которого нужно проверить данное сообщение. Если он не является автором, то проверяем, прочитано ли данное сообщение, если нет, то данный диалог для данного пользователя считаем непрочитанных. Количество таких диалогов будем считать… Читать далее »

Добавление личных сообщений и чатов на сайте — Часть 1

По сложившейся традиции расскажу о своих опытах по внедрению нового функционала на сайте. На данный момент этим функционалом являются личные сообщения между пользователями. Конечно, это сейчас работает не так хорошо, как в известных социальных сетях… но в итоге всё будет работать. Главное фидбек на форуме , пожалуйста. Итак. Очень хотелось добавить личные сообщения на сайте, тем более, что я уже обмолвился об этом полгода назад. Оставался вопрос, как вообще это реализовать. При поиске по интернету удалось наткнуться на вариант, когда формируется следующая модель данных. Id сообщения from_user — отправитель to_user — получатель pub_date — дата сообщения message — контент сообщения Попытался реализовать данный вариант, но меня остановило то, что вдруг после личных сообщений я захочу сделать чаты? Так почему бы сразу не заложить основу для чатов? Модели Chat и Message Это был бы отличный вариант для дальнейшего развития ресурса. Но в данном случае требуется создать две модели Chat и Message . # -*- coding: utf-8 -*-   from django.db import models from… Читать далее »

Удаление и импорт данных в базу psql

Для создания дампа БД 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… Читать далее »

Сериализация QuerySets. Получить запрос в sql виде

Используя 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 проектов (часть 3)

В этой части серии мы рассмотрим важнейший подход к обеспечению высокой производительности — кэширование. Суть кэширования в том, чтобы размещать часто используемые данные в быстром хранилище для ускорения доступа к ним. Важно понять, что быстрое хранилище (например, оперативная память) часто имеет очень ограниченный объем и его нужно использовать для хранения только тех данных, которые с большой вероятностью будут запрошены. Кэш фреймворк 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 проектов (часть 2)

Это продолжение серии статей про оптимизацию 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

Для получения значений из модели 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 проектов

Это первая статья из серии, здесь будут рассмотрено профилирование и настройки Django. Django это мощный фреймворк используемый в множестве отличных проектов. Из коробки в нем включено много полезных батареек, которые значительно ускоряют разработку и соответственно уменьшают ее стоимость. Однако, когда проект растет и набирает аудиторию, вы неизбежно столкнетесь с проблемами производительности. В этом посте я попробую рассказать о том с какими проблемами вы можете столкнуться и как их решить. Профилирование Перед тем выполнять оптимизацию необходимо измерить текущую производительность, чтобы после оптимизации можно было сравнить результаты. Такие измерения нужно будет делать часто, после каждого изменения, так что процесс должен быть автоматизированным. Профилирование — это процесс измерения метрик проекта. Таких как: время ответа сервера, использование CPU, использование памяти и тд. Python предоставляет профайлер в стандартной библиотеке, который вполне удобно использовать для измерения производительности кусков кода. Но для профилирования целового проекта существуют более удобные решения. Логирование Самая частая проблема производительности это лишние и/или не эффективные… Читать далее »