Как сделать регистрацию в или вход через вконтакте construct 2

Обновлено: 04.07.2024

Однако давайте вспомним, как часто мы встречали идеальную регистрацию? Почему даже крутые компании не могут сделать удобную и безопасную систему логина и восстановления доступа? Кажется, что все продуктовые дизайнеры настолько свыклись с тем, что регистрация — это просто, что даже не прилагают особенных усилий для её проектирования.

Простой пример. Кто из нас не сталкивался с тем, что тупит перед формой входа, не помня, как именно он регался на этом сервисе: через почту или какую-то из соцсетей? И таких примеров тьма. Но самое грустное в том, что мы сами считаем это нормой, и чаще всего виним себя и свою забывчивость, тогда как чаще всего виноват в этом именно сервис.

Я решил написать подробную инструкцию без привязки к конкретному языку программирования или методологии проектирования. Чистая логика, которую каждый без труда сможет подогнать под себя и реалии своего проекта.

Опыт в разработке и продуктовом дизайне тут тоже не особенно важен: начинающие могут использовать эту статью в качестве пошагового руководства; опытные же, возможно, почерпнут из неё какие-то отдельные удачные решения.

Реализовать схему регистрации, аутентификации и восстановления доступа посредством email и соцсетей.

Из-за универсальности инструкции, не допускается привязка к конкретным фреймоворкам, базам данных или программным решениям.

Кроме того, в схеме не реализована двойная аутентификация, так как она предполагает определённые технические решения (например, TOTP или SMS), которые также могут быть продиктованы особенностями продукта или бизнес-логики.

Инструкция представлена в виде набора сценарных схем с пояснениями. Отдельно описываются сложные или не очевидные сценарные моменты.

Каждый серый (клиент) и синий (сервер) блок является функцией разрабатываемой системы. Такие функции не описываются отдельно, так как их реализация может зависеть от особенностей конкретного языка или программного окружения.

Важное значение имеют соединительные линии (стрелки) на схемах. Они могут быть двух видов: пунктирные (переходы) и сплошные (обмен данными). На основании пунктирных линий можно, например, спроектировать API.

заполнение формы регистрации;
подтверждение email.

Наличие аккаунта

Временный аккаунт

До того, как пользователь не подтвердил свой email, его аккаунт является временным. Это позволяет:

более гибко управлять правами доступа (например, таким пользователям можно ограничить набор разрешённых действий);
автоматически очищать базу от неактивированных аккаунтов (например, по прошествии определённого времени).

В базе данных временный аккаунт может отличаться от обычного простым булевым флагом — или же такие аккаунты могут вообще храниться в отдельной таблице.

Подтверждение email классическое: ссылка с GET-параметрами в письме.

Срок жизни подтверждающей ссылки

Повторное подтверждение

При использовании соцсетей схема регистрации во многом использует те же механизмы, что и логин — поэтому здесь они объединены.

Соцсеть не вернула email

Если соцсеть не вернула email, система создаёт временный аккаунт без email. После этого пользователь должен ввести свою почту в специальном окне. После ввода email, проверяется его наличие в базе данных.

Объединение аккаунтов

Таким образом, при соответствии email, у пользователя не дублируются аккаунты, а сервис получает больше статистической информации о своих пользователях.

Механика логина максимально простая: пользователь вводит email и пароль, после чего сервер проверяет их на соответствие.

Защита от брутфорса

Способ защиты от перебора часто связан с конкретным программным решением или библиотекой, которую вы используете. Могут учитываться сессии, куки, ip-адреса, вспомогательные факторы (вроде включенного JS) и многое другое. Не забывайте про защиту от перебора, это важно.

Восстановление доступа к аккаунту осуществляется в два этапа:

заполнение формы восстановления;
подтверждение: переход из письма и ввод нового пароля.

Подстановка email

Если пользователь в рамках текущей сессии уже вводил email в формах регистрации или логина, то при переходе к восстановлению доступа, соответствующее поле предзаполняется.

Отсутствие пароля

Если пользователь регистрировался через соцсети, то у него по понятным причинам не будет пароля в аккаунте. Восстановление доступа в этом случае дополняется проверкой на привязку соцсети.

Если система обнаруживает отсутствие пароля в профиле, она проверяет, к какой соцсети привязан пользователь, и затем предлагает ему войти через эту соцсеть. Если же соцсеть по какой-то причине не была обнаружена, то запускается стандартная процедура отправки email со ссылкой на ввод нового пароля.

Срок жизни подтверждающей ссылки

Деактивация подтверждающей ссылки

Ну и разумеется, мы не можем позволять пользователям несколько раз сбрасывать пароль по одной и той же ссылке (банальный перехват URL позволит вытворять непозволительные вещи). Поэтому после первого перехода из письма ссылка будет деактивироваться.

В принципе, можно вообще удалять её из базы данных, но тогда будет сложнее отслеживать потенциально взломанных пользователей. Впрочем, это тема отдельной статьи.

После перехода по ссылке из письма мы не будем заставлять наших пользователей заново входить в аккаунт. Сам факт доступа к почте с возможностью последующей смены пароля упраздняет необходимость введения дополнительных мер безопасности в виде логина. Поэтому аутентификация происходит автоматически, как только был проверен ключ из ссылки.

Дополнительно, вы можете реализовать механизм принудительной смены пароля (чтобы после логина не перенаправлять пользователя в аккаунт, например). Но это уже на ваш вкус и реалии продукта.

Для упрощения архитектуры в этот раздел вынесены функции, которые используются более одного раза в системе. Их можно реализовать отдельно и обращаться к ним по мере необходимости. Удобно, быстро и сильно стабилизирует как саму разработку, так и поддержку продукта.

Тоже не сложно. Как правило, типов полей форм, которые надо валидировать, максимум 3-4, плюс один кастомный, по маске (RegExp). Логично вынести валидацию в отдельную функцию и применять к конкретным полям по необходимости. Благо, для любого фреймворка есть куча готовых решений на эту тему.

Отправка данных

Успешная аутентификация

Функция успешного логина. Подразумевает последующее перенаправление на целевую страницу. В схеме целевая страница представлена профилем с дефолтным состоянием (Nav.Profile, Default), однако хорошим тоном считается запоминать URL, с которого был вызван логин, и возвращать на него пользователя после успешной аутентификации.

Подсказка по логину через соцсети

Иллюстрация решения проблемы из начала статьи (когда пользователь не может вспомнить, через какую соцсеть он входил).

Если у пользователя истёк срок жизни сессии, но в браузере сохранились куки соцсетей, вы можете дать ему простую подсказку — например, подсветить нужную соцсеть. Или даже вывести рядом с кнопкой соцсети его аватар.

Эта функция может быть вызвана везде, где есть необходимость регистрации или логина (на отдельных страницах, в форме комментариев и тп), однако её программная реализация может зависеть от механик авторизации конкретной соцсети или сервиса.

Очистка данных

Любые данные, попадающие на сервер из клиента (и не только), должны быть в обязательном порядке очищены от всякой гадости, вроде SQL-инъекций или неприятных штук вроде XSS. Это действительно важно, потому что потом может сказаться на жизнеспособности всего продукта и безопасности данных его пользователей.

Аналогично функции на клиенте, можно написать отдельную функцию валидации данных на сервере, которая будет принимать в качестве параметров сами данные и тип валидации (включая регулярные выражения). Вызывать такую функцию можно буквально в пару строк.

Отправка email

Для многих языков и фреймворков есть готовые нативные решения по отправке email (в том числе, с помощью SMTP). Так как письма могут отправляться из многих частей продукта, логично использовать для этого единую функцию.

Запись успешного входа

Очень часто нужно отслеживать активные сессии пользователя или сообщать ему о новых логинах. Для этого как минимум потребуется фиксировать все случаи успешной аутентификации. Можно записывать их в БД или вести отдельный лог — как вам удобнее.

Проверка на привязанные соцсети

Абсолютно нечитаемая (особенно в рамках сайта), но исчерпывающая схема всего того, то было описано в этой статье. Может пригодиться архитекторам, которые хотели бы выявить дополнительные общие функции или оценить объём предстоящих работ.

Я много пишу про проектирование, разработку и продюсирование IT-проектов, и все свои материалы агрегирую в уютном телеграм-канале, велкам.

Отлично, спасибо большое за инструкцию! То, что надо!

Развели тут хабр

При том не просто хабр, а хабр-торт!

Боги сошли с небес и детально написали ТЗ

С точки зрения безопасности использовать для идентификации email. идентификация должна быть по логину а email всегда скрыт.
И да, пароли не шифруются а хэшируются!

Насчёт email спорно. Во-первых, логин — это неудобно, все привыкли вводить почты. Во-вторых, email нигде, кроме восстановления, можно и не светить. Да и там, при необходимости, можно повесить защиту от перебора.

Касаемо хэширования да, согласен, запарился. Исправил в статье.

Вы поймите что безопасность и "удобно", быстро и не согласуются между собой. Удобно вам-удобно атакующему. Быстро вам-быстро и атакующему.
email как минимум светится каждый раз когда человек логиниться на ваш сайт, а значит и во всяких запоминалках логинов. Для безопасности пользователя важно важно минимизировать засветку email как только можно.

Я это прекрасно понимаю, не первый год в индустрии. Однако любой цифровой сервис или продукт, если хочет быть успешным, вынужден балансировать между безопасностью и удобством. Вы можете быть максимально защищены, но какой в этом смысл, если конверсия в логин практически отрицательная, а пользователей у вас — полтора инвалида.

К сожалению (или к счастью), за создание цифровых продуктов отвечают не только одни разработчики и специалисты по цифровой безопасности. Два года назад я в рамках одного проекта проводил исследование: почту в качестве предпочтительной формы регистрации и входа выбрали более 80% респондентов. Предпочтя её и обычному логину, и номеру телефона.

Ну и напоследок. Почта — не самая чувствительная часть персональных данных. Если речь идёт о взломах условных "запоминалок логинов", то там вообще другого уровня проблемы.

Я вас понял, вы как и многие к сожалению побежали по популярной в последнее время дорожке-делать то что хотят пользователи. Только вот в опросе вы забыли упомянуть что риски компреметации аккаунта повышаются, если использовать почту как средство идентификации. И сколько % пользователей после этого все еще выбрали бы почту? Более того-в случае компрометации аккаунта кто будет у пользователя виноват? Он сам думаете? Я думаю пользователь будет обвинять именно вас, и кстати весьма обосновано.

А расскажите, пожалуйста, как повышаются риски компрометации аккаунта, если пользователь использует почту, а не логин? Посредством социнженерии? В 99% случаев нет разницы, email или логин вытаскивать из доверчивых пользователей или из их скомпрометированных устройств.

И да, я, как вы выразились, "побежал по популярной дорожке" удобства пользователей. Почти все цифровые продукты — это бизнес. В наше время невозможно сделать продукт успешным, если он неудобен пользователям. А без успешности у него не будет денег. А без денег нечем будет платить разработчикам и прочим членам проектной команды. Как итог: если продукты не будут удобными, то такие "борцы", как вы, останетесь без работы.

И заметьте, я не призываю полностью отказываться от безопасности или даже серьёзно её снижать. Перечитайте статью.

В случае если для идентификации используется почта, атакующему нужно ее узнать. В случае если для идентификации используется логин, атакующему нужно узнать и логин и почту.
По поводу бизнеса-я так понял вы не особо паритесь насчет рисков информационной безопасности, впрочем как и многие ныне действуют по принципу срубить денег и свалить. Если это ваш путь-наздоровье, но не поминайте пожалуйста тогда информационную безопасность всуе

Первая часть вашего ответа спорная в сценарной области. Вторая же просто не обоснована и даже оскорбительна. Думаю, разговор закончен, всего доброго.

Спасибо, с вами все ясно

Инструкция огонь. Делали подобные вещи для проекта реши-пиши с нуля и до всего из статьи доходили со временем ;-) Прочитать бы раньше. Но ещё будем прикручивать соцсети, так что обязательно перечитаю и сделаю подсказки через какую соц сеть логинились, если сессия пропала и в куках помним. Так просто и удобно!

Если пользователь пока не подтвердил email (или соцсеть его не вернула), то ему может быть доступна ограниченная функциональность (например, только просмотр). Блокировать или нет основную функциональность — это уже больше вопрос к основной механике продукта, как и объединение аккаунтов с разными email.

Более того, история с объединением аккаунтов вообще общая и не относится напрямую к регистрации (например, соцсеть может вернуть другой email — и тогда для появления "условий задачи" даже не понадобится отложенное подтверждение).

В целом, ваш вопрос справедлив, но ответить "универсально" я на него не могу, всё очень сильно зависит от особенностей конкретного продукта. Если выкинуть из требований, указанных в начале статьи, обязательность подтверждённого email, то достаточно будет просто убрать пару веток из схем.

Клёвый вопрос, спасибо. Этот кейс выходит за рамки непосредственно регистрации, но решаем довольно просто.

1. Если пользователь авторизован, и он прикрепляет новую соцсеть, то сначала мы проверяем, вернула ли соцсеть email. Если email не возвращён или email соответствует текущему, просто прикрепляем соцсеть к аккаунту.

5. После подтверждения нового email объединяем аккаунты. Эта механика уже совсем индивидуальная для каждого проекта. Плюс, как и в шаге 2, можем из нового email сделать резервный.

Шаги 3 и 4 можно миксовать, в зависимости от особенностей продукта и целевой аудитории. Понятно, что этот алгоритм подойдёт далеко не всем, но его совершенно точно можно подпилить под себя.

В этой статье мы разберём как делается на React.js форма регистрации, и немного поговорим как сделать вход, думаю всем кто разрабатывает на React, это будет интересно.

Также стоит сказать, что по сути это продолжение предыдущих двух статей по разработки на Express.js, и если вы на нём разрабатываете, то вам точно они будут интересны.

Создание формы регистрации на React.js:

Первым делом разберём как сделать регистрацию, но стоит сказать, мы тут будем использовать принцип RestAPI, то есть у нас отдельно работает клиент и сервер, поэтому для отправки запросов нам нужно использовать AJAX запросы, а для это мы будем использовать библиотеку Axios.js.

Для того чтобы скачать эту библиотеку, нужно использовать команду NPM, вот что мы прописываем в терминал:

Ещё нам пригодиться библиотека для валидации формы, для этого мы будем использовать библиотеку validator.js, для скачивание так же используем NPM, вот что пишем в терминал:

В начале рассмотрим что мы в него подключили:

Тут мы подключаем React и хук useState , для создания состояния, это нужно так как мы создадим функциональный компонент, а не классовый, они сейчас для работодателей гораздо более предпочтительней, чем классовые, и плюс, если их понять, то на мой взгляд и легче.

Следующие подключаем библиотеку Axios и Validator, о которых мы говорили чуть выше, ну и последние, это две константы DOMEN_SERVER , для хранения домена сервера и DOMEN_SITE , для хранения домена клиентской части, их создавать не обязательно в отдельном файле конфигурации, но полезно для удобства.

Когда мы всё подключили, создаём наш функциональный компонент, который тут же экспортируем, вот что пишем:

Теперь напишем пару функций для работы с регистрацией:

alert ( "Password must consist of one lowercase, uppercase letter and number, at least 8 characters" )

В начале мы создаём состояние, для регистрации, конкретно мы используем имя пользователя, его Email и два пароля, первый основной, а второй для повтора, вы же конечно может ещё какие либо параметры добавить, зависимо от ваших нужд.

Потом создаём функцию, которая нужна для изменения состояния формы, во первых мы там используем метод event.persist() , которая позволяет получить доступ к событие асинхронным способом.

Дальше используем функцию setRegister() , которая нужна для изменения состояние, и тут вы можете заметить, что мы в качестве названия свойства используем название поля ы форме, поэтому атрибут name поля должен равен быть его состоянию.

Вторая функция которая тут есть, это submitChackin() , она уже отправляет данные на сервер, но перед этим мы проверяем поля с помощью библиотеки validator , сначала проверяем Email, потом совпадает ли пароль который изначальный и повторный, ну и проверяем сам пароль.

Если хоть одна ошибка сработала, то выводим её, через alert() , иначе отправляем данные на сервер, если и там случилась ошибка, то выводим её так же или если нет, то отправляем пользователя в форму для входа на сайт.

Последние что осталось, это рендер самой формы, вот что, вот как строиться рендер:

По рекомендации пользователей сайта начал добавлять авторизацию через социальные сети на сайт. Первой такой социальной сетью стала ВКонтакте, как наиболее популярная социальная сеть у пользователей моего сайта.

Django сам по себе имеет необходимый функционал по работе с протоколом OAuth 2.0, который мог используется в API ВКонтакте для авторизации пользователей на сторонних ресурсах (и не только для авторизации). Но в данном случае я не стал писать свой велосипед, используя голую поддержку OAuth в Django, а нашёл очень хорошую батарейку, которая пожалуй достаточно известна среди разработчиков сайтов на Django, которая позволила внедрить авторизацию через ВКонтакте всего за пару часов.

Эта батарейка называется Python Social Auth Django .

Давайте пошагово разберёмся, что нам нужно сделать, чтобы подключить авторизацию через ВКонтакте на сайт с Django

Шаг 1 - Установка Python Social Auth Django

Делается это одной командой в вашем виртуальном окружении через утилиту pip

В документации предлагается при конфигурировании два вариант ORM для работы системы аутентификации через социальные сети. Это классическая ОРМ Django и ОРМ MongoEngine, но так получилось, что требуемый для MongoEngine пакет устарел и немного несовместим с последними версиями Django, просто не работает, даже в документации разработчиков mongoengine висит призыв о помощи с поддержкой утилиты. Поэтому будем настраивать только для классической ОРМ.

Прописываем приложение аутентификации в INSTALLED_APPS

Шаг 3 - Миграция базы данных

Вам потребуется применить изменения в структуре базы данных, поскольку данная батарейка имеет свои таблицы для работы с авторизацией пользователей.

Далее последуем ещё одной рекомендации по настройке базы данных, если Вы, как и я, используете PostgreSQL. А именно.

При использовании PostgreSQL рекомендуется использовать встроенное поле JSONB для хранения извлеченных дополнительных_данных. Чтобы включить его, задайте настройку:

Шаг 4 - Настройка бекендов аутентификации

Также прописываем в settings.py

Обязательно включите бекенд классической аутентификации, иначе потеряете возможность зайти через логин и пароль на сайт.

Шаг 5 - Настройка процессора шаблонов

У меня за полтора года разработки данного сайта настройка TEMPLATES осталась практически нетронутой, но я добавил одну строку для этой батарейки

Шаг 6 - Настройка ключей для ВКонтакте

Здесь дана настройка секретных ключей для ВКонтакте

Чтобы их получить, нужно создать в инструментарии разработчика ВКонтакте приложение и взять ID вашего приложения и секретный ключ для него.

Заходим в его настройки и видим всё, что нужно

В итоге прописываем в данные переменные следующие настройки

Шаг 7 - Подключение маршрутов для авторизации в urls.py

Делается это так

Шаг 8 - Добавление ссылки на маршрут

А теперь добавим ссылочку на маршрут где-нибудь в шаблоне, чтобы запускать авторизацию через ВКонтакте

Шаг 9 - Настройка редиректа при авторизации

Это необязательная настройка, которая укажет URL для перенаправления пользователя на вашем страницы после успешной авторизации. Оставим корень сайта

Там уже разберётесь, как вам лучше будет сделать

Шаг 10 - Запрос разрешений на получение доступа к email

Для Django рекомендую VDS-хостинг TIMEWEB