user activate что это
В Сеть утекла база данных сервиса анонимной СМС-верификации
В интернет утекла база данных с платежной информацией пользователей сервиса виртуальных онлайн-номеров sms-activate.ru, сообщает «Коммерсантъ». Первым о сливе рассказал Telegram-канал «Утечки информации».
Файл размером 2,35 Гб содержит имена, адреса электронной почты, IP-адреса, частичные номера платежных карт, суммы платежей. За исключением дубликатов в базе данных более 163 тыс. уникальных электронных адресов.
Сервис sms-activate.ru и другие подобные ему предоставляют «в аренду» мобильные номера. Это позволяет пользователям анонимно верифицироваться в соцсетях, мессенджерах, на торговых площадках и других онлайн-платформах.
Основатель сервиса разведки утечек данных и мониторинга даркнета DLBI Ашот Оганесян в беседе с «Коммерсантом» уточнил, что из 163 тыс. утекших позиций около 50 тыс. являются валидными, то есть пригодными к использованию.
Эксперт отметил, что в июне уже была подобная утечка — тогда в Сети появились около 1,5 млн сообщений, предположительно отправленных с номера 900 (короткий СМС-номер Сбербанка). В них содержались имена клиентов, суммы снятия или перевода средств, баланс банковских карт и их последние четыре цифры.
Гендиректор Infosecurity a Softline Company Кирилл Солодовников объяснил, что слитая база sms-activate.ru может использоваться и мошенниками, и маркетологами. Данные о платежных операциях, частичные номера карт, электронные адреса позволяют составить профиль владельца. Имея эту информацию, мошенники методами социальной инженерии могут манипулировать своими жертвами.
Начальник отдела информационной безопасности «СерчИнформ» Алексей Дрозд заметил, что одной из главных опасностей слива sms-activate.ru является деанонимизация — временными мобильными номерами часто пользуются в сомнительных целях, в том числе сами мошенники, а также для накруток активности в соцсетях и на платформах для голосования.
В прошлом году в Сеть утекли данные 55 тыс. клиентов банков, пользовавшихся маркетплейсом Joom. Некоторые банки перевыпустили скомпрометированные карты. В апреле 2021 года мошенники начали продавать в интернете данные граждан, которые хотели взять кредит в «Дом.РФ» — речь шла о 100 тыс. учетных записей.
После этого депутат Госдумы от КПРФ Валерий Рашкин обратился в Генпрокуратуру с просьбой проверить сообщения об утечках данных россиян с государственных и других ресурсов. По словам парламентария, отсутствие реакции правоохранительных органов на такие случаи подрывает доверие граждан к официальным ресурсам и организациям.
Настройка аутентификации JWT в новом проекте Django
Данная статья является сборкой-компиляцией нескольких (основано на первой) статей, как результат моих изучений по теме jwt аутентификации в джанге со всем вытекающим. Так и не удалось (по крайней мере в рунете) найти нормальную статью, в которой рассказывается от этапа создания проекта, startproject, прикручивание jwt аутентификации.
Добротно исследовав, отдаю на людской суд.
Ссылки на пользуемые статьи прилагаются:
Настройка аутентификации JWT
Django поставляется с системой аутентификации, основанной на сеансах, и это работает из коробки. Это включает в себя все модели (models), представления (views) и шаблоны (templates), которые могут быть нужны вам для создания и дальнейшего логина пользователей. Но вот в чем загвоздка: стандартная система аутентификации Django работает только с традиционным ‘запрос-ответ’ циклом HTML.
Почему важно знать, что встроенная система аутентификации Django работает только с традиционным ‘запрос-ответ’ циклом HTML? Потому что клиент, для которого мы создадим данный API, не придерживается этого цикла. Вместо этого, клиент будет ожидать, что сервер вернет JSON, вместе обычного HTML. Возвращая JSON, мы можем позволить решать клиенту, а не серверу, что делать дальше. В цикле ‘запрос-ответ’ JSON, сервер получает данные, обрабатывает их и возвращает ответ (пока что как и в цикле ‘запрос-ответ’ HTML), но ответ не управляет поведением браузера. Ответ просто сообщает браузеру результат запроса.
К счастью, команда разработки Django поняла, что тренды веб разработки движутся именно в этом направлении. Они также знали, что некоторые проекты могут не захотеть использовать встроенные модели, представления и шаблоны. Вместо этого, они могут использовать собственные. Чтобы убедиться, что все усилия, затраченные на создание встроенной системы аутентификации Django, не потрачены зря, они решили сделать возможным использование наиболее важных частей, сохраняя при этом возможность настройки конечного результата.
Мы поговорим об этом позже в этом руководстве, а пока что вот список того, что вам нужно знать:
Мы создадим собственную модель User, взамен модели Django
Нам нужно будет написать наши собственные представления для поддержки возврата JSON вместо HTML
Поскольку мы не будем использовать HTML, нам не нужны встроенные шаблоны входа и регистрации Django
Аутентификация, основанная на сессии
По умолчанию, Django использует сессии для аутентификации. Прежде чем идти дальше, нужно проговорить, что это значит, почему это важно, что такое аутентификация на основе токенов и что такое JSON Web Token Authentication (JWT для краткости), и что из всего этого мы будем использовать далее в статье.
if request.user is not None and request.user.isauthenticated(): в if request.user.isauthenticated():
В нашем случае, клиент и сервер будут работать в разных местах. Например, сервер будет напущен по адресу http://localhost:3000, а клиент по адресу http://localhost:5000. Браузер будет считать, что эти две локации будут находиться в разных местах, аналогично запуску сервера на http://www.server.com и клиента на http://www.clent.com. Мы не будем разрешать внешним доменам получать доступ к нашим файлам cookie, поэтому нам нужно найти другое, альтернативное решение, для использования сессий.
Если вам интересно, почему мы не разрешаем доступ к нашим файлам cookie, ознакомьтесь со статьями о совместном использовании ресурсов между источниками (Cross-Origin Resource Sharing, CORS) и подделке межсайтовых запросов (Cross-Site Request Forgery, CSRF), по ссылкам ниже:
Аутентификация, основанная на токенах
Наиболее распространенной альтернативой аутентификации на основе сессий/сеансов является т.н. аутентификация на основе токенов. Мы будем использовать особую форму такой аутентификации для защиты нашего приложения. При аутентификации на основе токенов сервер предоставляет клиенту токен после успешного запроса на вход. Этот токен уникален для пользователя и хранится в базе данных вместе идентификатором пользователя (если точнее, возможны раные вариации генерации токена, основная же идея в том, чтобы он аутентифицировал пользователя, позволяя знать кто это и давая доступ к апи, и имел время жизни, по истечении которого «протухал»). Ожидается, что клиент отправит токен вместе с будущими запросами, чтобы сервер мог идентифицировать пользователя. Сервер делает это путем поиска в таблице базы данных, содержащей все созданные токены. Если соответствующий токен найден, то сервер продолжает проверять, действителен ли токен. Если не найден, мы говорим, что пользователь не аутентифицирован. Поскольку токены хранятся в базе данных, а не в файлах куки, аутентификация на основе токенов соответствует нашим потребностям.
Верификация токенов
JSON Web Tokens
Помните, что мы сказали, что будем использовать особую форму аутентификации на основе токенов? JWT это как раз то, что имелось ввиду.
Почему JSON Web Tokes лучше обычных токенов?
При переходе с обычных токенов на JWT мы получаем несколько преимуществ:
JWT содержат информацию о пользователе, что удобно для клиентской стороны.
Библиотеки здесь берут на себя основную тяжелую работу. Развертывание собственной системы аутентификации опасно, поэтому мы оставляем важные вещи проверенным «в боях» библиотекам, которым можем доверять.
Создание приложения, создание пользовательской модели
Для начала, создадим проект. Перейдите в терминале в вашу рабочую директорию, и выполните команду django-admin startproject json_auth_project (если вылезает ошибка, установите глобально джангу командой pip3 install django ).
Наберите следующий код класса UserManager в файл apps/authentication/models.py и обязательно примите к сведению комментарии (больше про менеджеров: https://docs.djangoproject.com/en/3.1/topics/db/managers/):
Теперь, когда мы имеем класс менеджера, мы можем создать модель пользователя, наберите далее:
Если хотите узнать немного больше о кастомной аутентификации пользователя, несколько ссылок для глубокого изучения:
В справочнике по полям модели перечислены различные типы полей, поддерживаемые Django, и параметры, которые принимает каждое поле (например, db_index и unique ) https://docs.djangoproject.com/en/3.1/ref/models/fields/
Определение AUTH_USER_MODEL в настройках проекта
Создание и запуск миграций
Теперь мы готовы создавать и применять миграции. После этого мы сможем создать нашего первого пользователя. Чтобы создать миграцию, необходимо запустить в консоли следующую команду:
Это создаст стандартные миграции для нашего нового проекта Django. Однако, это не создат миграции для новых приложений внутри нашего проекта. В первый раз, когда мы хотим создать миграции для нового приложения, мы должны быть более конкретны.
./manage.py makemigrations authentication
Теперь мы можем применить миграции с помощью команды:
Наш первый пользователь
Итак, мы создали нашу модель User, более того, наша база данных поднята и работает. Следующим шагом будет создание первого объекта пользователя, User. Мы сделаем этого пользователя суперадмином, так как будем использовать его для дальнейшего тестирования нашего приложения.
Создайте пользователя с помощью следующей команды терминала:
Для проверки успешного создания пользователя, перейдите в шелл Django, посредством выполнения следующей команды:
Оболочка shell_plus предоставляется библиотекой django-extensions, которую необходимо установить (pip3 install django-extensions), если вы хотите пользоваться shell_plus. Это удобно, так как он автоматически импортирует модели всех приложения, указанных в INSTALLED_APPS. При желании, его также можно настроить для автоматического импорта других утилит.
После открытия оболочки, выполните следующие команды:
Регистрация новых пользователей
На текущий момент, пользователь не может делать чего бы то ни было интересного. Нашей следующей задачей будет создание эндпоинта для регистрации новых пользователей.
RegistrationSerializer
Создайте файл apps/authentication/serializers.py и наберите туда следующий код:
Прочитайте внимательно код, обращая особое внимание на комментарии, а затем продолжим.
Немного о ModelSerializer
RegistrationAPIView
Теперь мы можем сериализовывать запросы и ответы для регистрации пользователя. Далее, мы должны создать вью (views) для реализации эндпоинта (endpoint), что даст клиентской стороне URL для запроса на создание нового пользователя.
Создайте файл apps/authentication/views.py если его нет и наберите следующий код:
Проговорим о паре новых вещей в коде выше:
Почитать про Django REST Framework (DRF) Permissions можно по ссылке https://www.django-rest-framework.org/api-guide/permissions/
Теперь мы должны настроить маршрутизацию для нашего проекта. В Django 1.x => 2.x были внесены некоторые изменения при переключении с URL на путь (path). Есть довольно много вопросов по адаптации старого URL-адреса к новому способу определения URL’s, но это выходит далеко за рамки данной статьи. Стоит сказать, что в последних версиях Django работа с роутами значительно упростилась, в чем можно убедиться далее.
Создайте файл apps/authentication/urls.py и поместите в него следующий код для обработки маршрутов нашего приложения:
Откройте project/urls.py и вы увидите следующую строку в верхней части файла:
from django.urls import path
Первое, что нужно сделать, это импортировать метод include() из django.urls
from django.urls import path, include
Метод include() позволяет включить еще один файл без необходимости выполнения кучи другой работы, например, импортирования а затем повторной регистрации маршрута в этом файле.
Ниже видим следующее:
Обновим это, чтобы включить наш новый файл urls.py :
Регистрация пользователя с помощью Postman
Теперь, когда мы создали модель User и добавили эндпоинт для регистрации новых пользователей, выполним быструю проверку работоспособности, чтобы убедиться, что мы на правильном пути. Для этого использует прекрасный инструмент тестирования (и далеко не только) апи под названием Postman (ознакомиться с его функциональность подробнее можно по ссылке https://learning.postman.com/docs/getting-started/introduction/).
Необходимо сформировать POST запрос по пути localhost:8000/api/users/ со следующей структурой данных в теле запроса:
В ответ вернутся данных только что созданного пользователя. Мои поздравления! Все работает как надо, правда, с небольшим нюансом. В ответе вся информация пользователя находится на корневом уровне, а не располагается в поле «user». Чтобы это исправить (чтобы ответ был похож на тело запроса при регистрации, указанное выше), нужно создать настраиваемое средство визуализации DRF (renderer).
Рендеринг объектов User
Создайте файл под названием apps/authentication/renderers.py и наберите в него следующий код:
Здесь ничего особо нового или интересного не происходит, поэтому прочитайте комментарии в коде и двигаемся дальше.
Кроме того, необходимо установить свойство renderer_classes класса RegistrationAPIView :
Теперь, имея UserJSONRenderer на нужном месте, используйте запрос в Postman’e на создание нового пользователя. Обратите внимание, что теперь ответ находится внутри пространства имен «user».
Вход пользователей в систему
Поскольку теперь пользователи могут зарегистрироваться в приложении, нам нужно реализовать для них способ входа в свою учетную запись. Далее, мы добавим сериализатор и представление, необходимые пользователям для входа в систему. Мы также начнем смотреть, как наш API должен обрабатывать ошибки.
LoginSerializer
Откройте файл apps/authentication/serializers.py и добавьте следующий импорт:
После, наберите следующий код сериализатора в конце файла:
Когда сериализатор будет на своем месте, можно отправляться писать представление.
LoginAPIView
Откройте файл apps/authentication/views.py и обновите импорты:
А затем, добавьте само представление:
Далее, откройте файл apps/authentication/urls.py и обновите импорт:
И затем добавьте новое правило в urlpatterns :
Вход пользователя с помощью Postman
Перегрузка EXCEPTION_HANDLER и NON_FIELD_ERRORS_KEY
Позаботившись об этом, откройте файл project/settings.py и добавьте новый параметр под названием REST_FRAMEWORK в конец файла:
Обновить UserJSONRenderer
Нет, в ответе полученном с неверными почтой/паролем все совсем не так, как ожидалось. Да, мы получили ключ «error», но все пространство имен заключено в ключе «user», что совсем не хорошо. Давайте обновим UserJSONRenderer чтобы проверять ключ «error» и предпринять некоторые действия в таком случае. Откройте файл apps/authenticate/renderers.py и внесите следующие изменения:
Получение и обновление пользователей.
Пользователи могут регистрировать новые аккаунты и заходить, логиниться в эти аккаунты. Теперь пользователи нуждаются в возможности получить и обновить свою информацию. Давайте реализуем это прежде чем перейти к созданию профилей пользователей.
UserSerializer
Мы собираемся создать еще один сериализатор для профилей. У нас есть сериализаторы для запросов входа и регистрации, но нам так же нужна возможность сериализации самих пользовательских объектов.
Откройте файл apps/authentication/serializers.py и добавьте следующий код:
UserRetrieveUpdateAPIView
Откройте файл apps/authentication/views.py и обновите импорты следующим образом:
Прописав импорты, создайте новое представление под названием UserRetrieveUpdateView :
Теперь перейдем к файлу apps/authentication/urls.py и обновим импорты в начале файла, чтобы включить UserRetrieveUpdateView :
И добавим новый путь в urlpatterns :
Откройте Postman и отправьте запрос на текущего пользователя на получение информации о текущем пользователе (GET localhost:8000/api/user/). Если все сделано правильно, вы должны получить сообщение об ошибке как следующее:
Аутентификация пользователей
Создайте и откройте файл apps/authentication/backends.py и добавьте в него следующий код:
В этом файле много логики и исключений, но код довольно прост. Все, что мы сделали, это составили список условий, которые пользователю необходимо пройти для аутентификации, и описали исключения, которые выбросятся, если какое-то из условий окажется истинным.
Сообщить DRF про наш аутентификационный бекенд
Мы должны явно указать Django REST Framework, какой бекенд аутентификации мы хотим использовать, аналогично тому, как мы сказали Django использовать нашу пользовательскую модель.
Откройте файл project/settings.py и обновите словарь REST_FRAMEWORK следующим новым ключом:
Получение и обновление пользователей с помощью Postman
Теперь, когда наш новый бекенд аутентификаци установлен, ошибки аутентификации, которые мы наблюдали ранее, должна исчезнуть. Проверьте это, открыв Postman и отправив тот же самый запрос (GET localhost:8000/api/user/). Он должен быть успешным, и вы должны увидеть информацию о своем пользователе в ответе приложения. Помните, что мы создали эндпоинт обновления вместе с эндпоинтом получения информации? Давайте проверим и это. Отправьте запрос на обновление почты пользователя (PATCH localhost:8000/api/user/), передав в заголовках запроса токен. Если все было сделано верно, в ответе вы увидите, как адрес электронной почты изменился.
Итоги
Подведем краткие итоги того, что мы сделали в данной статье. Мы создали гибкую модель пользователя (в дальнейшем, можно ее расширять как душе угодно, добавляя разные поля, дополнительные модели и т.п.), три сериализатора, каждый из которых выполняют свою четко определенную функцию. Создали четыре эндпоинта, которые позволяют пользователям регистрироваться, входить в систему, получать и обновлять информацию о своем аккаунте. На мой взгляд, это очень приятный фундамент, основа, на которой можно строить какой-то новый ламповый проект по своему усмотрению:) (однако же, есть куча сфер, о которых можно говорить часами, например на языке крутится следующий этап о том, чтобы завернуть это все в контейнеры докера, прикрутив постгрес, редис и селери).
Включение, настройка и отключение User Account Control (UAC)
В современных версиях Windows существует много инструментов, которые предназначены для обеспечения безопасности. Один из них — User Account Control, что в переводе означает «Контроль учётных записей». Он выдаёт окно с предупреждением, если какая-то программа или процесс пытается внести несанкционированные изменения в систему. И надо либо разрешить запуск утилиты, либо отменить его. Разберитесь, для чего нужен UAC Windows 7, как отключить его, как активировать и как настроить.
В этой статье мы расскажем, как включить UAC в Виндовс
Что такое UAC и зачем он нужен?
Многих пользователей раздражают такие уведомления. Ведь приходится каждый раз подтверждать, что вы согласны на установку нового приложения. Но контроль учётных записей служит для защиты от вредоносного ПО: вирусов, шпионов, рекламщиков. Он не заменит антивирус, сетевой экран или firewall. Но без этой функции Windows будет уязвима.
Если отключить UAC, компьютер окажется под угрозой. Не стоит деактивировать Account Control без причин. Иначе абсолютно любая программа сможет менять настройки системы, устанавливать свои дистрибутивы и запускать их. И всё это без ведома пользователя.
Контроль учётных записей можно настроить, чтобы он не был таким «надоедливым», и оповещение не выскакивало при запуске любой программы. Но рекомендуется оставить эту функцию в активном состоянии, чтобы защитить ПК.
Панель управления
Отключение UAC Windows 7 выглядит так:
Настройте, в каких случаях показывать уведомления
Войти в это меню и отключить UAC можно и быстрее.
В Windows Vista такого ползунка нет. Соответственно, детальная настройка функции невозможна. Доступно только включение и отключение режима.
Групповые политики
Ещё один метод взаимодействия с Account Control — редактор групповой политики. Этот способ подойдёт не для всех версий операционной системы. Только для Профессиональной, Максимальной и Корпоративной Windows.
Чтобы отключить UAC:
Запустите редактор групповой политики
Снова включить Account Control можно в том же меню.
Редактор реестра
Перед тем как что-то менять в реестре, надо сделать его резервную копию. Чтобы в случае возникновения неполадок его быстро восстановить.
Вот как в Windows 7 отключить контроль учётных записей UAC:
Командная строка
Отключение Account Control при помощи команд:
Account Control — это необходимая мера безопасности. Отключайте её только в крайнем случае.
Расскажите, а у вас работает UAC, или вы обходитесь без него?
[Symfony 5] Раздельная авторизация для админов и пользователей с двумя разными сущностями и формами входа
Создать в Symfony 5 раздельную авторизацию:
Зачем нужен этот гайд?
У меня стояла задача разделить форму входа с сущностью User на две разные — для пользователя (entity User) и для администратора (entity Admin) для нормального функционала админ панели (в данном случае EasyAdmin).
В данном туториале я распишу пошагово весь путь, начиная с установки самого фреймворка, и заканчивая созданием двух разных форм авторизации.
Технические характеристики
Шаг 0 — ставим Symfony 5
Будем считать, что вы поставили все нужные компоненты, включая Composer в корневом каталоге OpenServer (. /domains).
Шаг 1 — настраиваем бд
Шаг 2 — создаем сущность User
Создаем сущность User, в качестве уникального значения выбираем email
Шаг 3 — создаем сущность Admin
Повторяем всё то, что описано в предыдущем шаге, вместо названия сущности User ставим Admin
Шаг 4 — подготовим Fixtures
Создадим 2 тестовых аккаунта, один для User, второй для Admin. Воспользуемся DoctrineFixturesBundle
Для начала нужно его поставить
После установки в /src появится папка DataFixtures, в котором уже будет создан файл AppFixtures.php
Переименуем его в UserFixtures.php и добавим в него нужный функционал
Тоже самое необходимо сделать и для админа — создаём AdminFixtures.php
Шаг 5 — загружаем миграции и fixtures в бд
Сущности созданы, fixtures мы прописали, осталось теперь всё это залить в бд, следующие действия я провожу при каждом изменении сущностей или fixtures
Шаг 6 — создаём авторизацию
В консоли прописываем
Настройки и названия ставим такие:
В результате у нас обновиться security.yaml и создадутся 3 файла
Шаг 7 — правим security.yaml
После создания авторизации security.yaml выглядит так:
Нам необходимо добавить новый provider admin_user_provider и поменять настройки у firewalls.
Финально, файл security.yaml должен выглядить вот так:
Шаг 8 — переименовываем шаблон login.html.twig
Это нужно сделать, так как мы повторно будем создавать авторизацию через make:auth.
Назовем этот файл.
Шаг 9 — редактируем UserAuthSecurityController
Файл находится по пути App\Controller, так как мы поменяли название шаблона, в контроллере это необходимо изменить.
Каким должен быть контроллер:
Шаг 10 — создаём вторую авторизацию
В консоли прописываем:
Так как мы добавили новый app_admin_provider — нам предложат выбрать какой firewall мы хотим обновить:
После выбора firewall предложать выбрать Entity, выбираем \App\Entity\Admin:
Шаг 11 — переименовываем только что созданный login.html.twig
Переименовываем только что созданный login.html.twig на admin-login.html.twig
Шаг 12 — редактируем только что созданный AdminAuthController
Меняем route и название шаблона:
Шаг 13 — редактируем файл config/routes.yaml
Создаем login_check и admin_login_check, которые мы определили в настройках firewall в файле config/packages/security.yaml
Как должен выглядеть файл config/routes.yaml:
Шаг 14 — редактируем файл templates/secutiry/user-login.html.twig
Добавляем в тег атрибут action:
Шаг 15 — редактируем файл templates/secutiry/admin-login.html.twig
Добавляем в тег атрибут action:
Шаг 16 — запускаем сайт
Для запуска сайта сначала ставим web-server-bundle:
Шаг 17 — тестируем авторизацию для User
Переходим на страницу 127.0.0.1:8000/login
Авторизовываемся, используя email user@example.com и пароль 123654.
Видим, что авторизация прошла успешно:
Если использовать неправильные данные, выбьет ошибку Invalid credentials.
Шаг 18 — тестируем авторизацию для Admin
Переходим на страницу 127.0.0.1:8000/admin/login
Авторизовываемся, используя email admin@example.com и пароль 123654.
Видимо, что всё успешно:
При вводе неправильных данных или если мы введем данные от User на странице /admin/login — вылетит ошибка, что Invalid credentials. Для страницы /login тоже самое — введем данные от Admin — будет ошибка.
Заключение
Спасибо всем, кто дочитал до конца, постарался максимально подробно расписать гайд, чтобы каждый при необходимости мог сделать нечто подобное.
Написать туториал решил после того, как не нашел подробной инструкции для данной задачи в английской документации, гайдах или обсуждениях, не говоря уже о материалах на русском языке.