5.2 Тип Пользователь

Bubble предполагает, что ваше приложение будет полагаться на систему управления пользователями, то есть позволять пользователям регистрироваться, входить в систему, выходить из системы, совершать какие-то действия в вашем приложении. Поэтому каждое новое приложение Bubble имеет встроенный тип "Пользователь"/"User", который следует тем же принципам, которые описаны выше (!!!ЛНК!!!), но с несколькими дополнительными свойствами. Если ваше приложение не использует пользователей, это не повлияет на ваше приложение.

Отличия между типом Пользователь и другими типами.

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

Пользователь определяется своим уникальным email, или идентификатором, если аутентификация происходит с помощью сторонних сервисов (таких как Facebook OAuth, см. ниже). Таким образом, пользователь создаётся не с помощью "Создать новую сущность"/"Create a new thing", а с помощью действия "Зарегистрировать пользователя"/"Sign the user up" или "Создать аккаунт для кого-то другого"/"Create an account for someone else". Выполнение этого действия в ходе процесса (во время работы приложения) создаст новую сущность типа "Пользователь" и проверит уникальность электронной почты. Если пользователь создает учетную запись с помощью действия "Зарегистрировать пользователя", он сможет задать пароль, а если вы используете "Создать аккаунт для кого-то другого", пользователь будет отмечен как "временный пароль"/"temporary password" и ему будет предложено изменить пароль, если вы назначили соответствующий параметр во вкладке "Настройки". Эта настройка позволяет вам выбрать страницу, на которую перенаправляются пользователи, не вводившие еще свой собственный пароль, и создать форму (и связанный с ней процесс), которая позволяет пользователю задать свой пароль. Переадресация происходит при загрузке страницы в том случае, если предыдущее действие не "Авторизовать пользователя"/"Log the user in".

У типа "Пользователь" есть встроенные поля, которые вы можете использовать в своём приложении. Наиболее важным и общим является поле "email", которое содержит тот email, который пользователь использовал при регистрации, или тот, который первым был подтянут из сторонних сервисов, если вы используете их для авторизации пользователя (Facebook, см. ниже). Второе поле - это "email подтвержден"/"email confirmed", которое позволяет узнать, кликнул ли пользователь по ссылке для подтверждения владения электронной почтой. Это поле возвращает значение "да/нет".

Нужно отметить, что если пользователь был удален с помощью действия "удалить сущность"/"delete thing", этот пользователь больше не будет существовать в базе данных, не сможет войти в систему и т.д.

Понятие текущего пользователя

Один из самых важных источников данных, который вы можете использовать - это "Текущий пользователь"/"Current user". Он описывает пользователя, который использует приложение в данный момент (в отличие от другого пользователем в базе данных). Сессия - это то, что описывает понятие пользователя, использующего приложение в данный момент. Технически, сессия определяется по кукам на уровне браузера. В зависимости от настроек вашего приложения вы можете задать время действия куков. Обычно куки действуют бесконечно, поэтому у пользователя будет одна и та же сессия до момента выхода из системы либо до очистки куки-файлов (как у Facebook, вы в системе постоянно, пока не выйдете или не смените браузер).

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

Зарегистрированные пользователи

Если пользователь зарегистрировался в Bubble (с электронной почтой и паролем), в базе данных создается постоянная запись с использованием этого электронного адреса и пароля. Когда пользователь открывает ваше приложение в новом браузере (без файлов куки) и вводит свои учетные данные с помощью процесса входа в систему, он будет авторизован. Значение «Текущий пользователь вошел в систему»/"Current user is logged in" ​​вернет «Да». Если вы измените текущего пользователя, это будет сохранено навсегда в объекте базы данных, а если пользователь войдет в систему на другом устройстве, здесь тоже будут применены эти изменения.

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

Временные пользователи

В тот момент, когда приложение Bubble было открыто в браузере, создается сессия пользователя. Если пользователь уже в системе и не почистил куки, сессия будет использовать данные того же пользователя, что и прежде, а если сессия будет свежей (без авторизованного пользователя), будет создан временный пользователь. Этот пользователь будет помечен как "не авторизованный" (другими словами, "Пользователь не вошел в систему"/"Current user is logged in" вернет "да").

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

Когда пользователь впервые попадает в ваше приложение, он будет отображаться как временный пользователь. Если он пройдет процесс регистрации, то станет зарегистрированным пользователем и навсегда сохранится в базе данных. В контексте рабочих процессов у этого есть важное следствие. Представьте, что ваш процесс спрашивает пользователя сколько ему/ей лет до регистрации и сохраняет это значение в сущность "Текущий пользователь"/"Current user". Теперь, если пользователь зарегистрируется в течение трех дней, постоянный пользователь, который будет создан, будет иметь этот возраст.

Использование внешних сервисов для аутентификации

Самый распространенный способ аутентификации пользователей - предложить им ввести пароль или электронную почту. Тем не менее, очень часто вы будете использовать для аутентификации пользователей некоторые внешние сервисов, используя их учетные данные от этих сервисов. Это осуществляется с помощью плагинов (!!!ЛНК!!!). У использования такого способа при разработке вашего приложения есть ряд преимуществ. В качестве примера мы будем использовать Facebook (другими словами, у вашего приложения будет кнопка "Войти с помощь Facebook").

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

  • Также это позволяет посылать запросы к этим сервисам на стороне пользователя. В случае с Facebook, это позволит вам запросить email пользователя (зарегистрированный на Facebook), получить фото профиля, посты на стене и т.д.

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

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

Когда пользователь регистрируется в Bubble через социальную сеть (Facebook), в базе данных создается новый пользователь, аналогично традиционной логике регистрации с логином и паролем. Основное отличие в том, что при выходе из системы, пользователь будет входить обратно не с помощью ввода пароля (так как он его не задавал), а с помощью Facebook. Если пользователь вошел в браузере на Facebook, а ваше приложение использует вход через Facebook, пользователь автоматически войдет в систему как текущий пользователь Facebook.

Пользователь может одновременно использовать традиционный вход с помощью логинов и с помощью социальных сетей. Вот несколько примеров.

  1. Если пользователь уже вошел в систему по электронной почте и паролю, вы можете попросить его привязать свою учетную запись по протоколу Oauth (например, к Facebook, Google ...). Если пользователь проходит этот процесс, новая сущность не создается, а учетные данные Oauth добавляются к текущему, зарегистрированному пользователю. По завершении этого процесса пользователь сможет войти в систему либо по электронной почте и паролю, либо через протокол Oauth. Если другой пользователь существует в базе данных с электронной почтой, предоставленной внешним сервисом, действие завершится неудачно, и пользователю будет показано сообщение.

  2. Если пользователь не вошел в систему на момент прохождения авторизации через Oauth, будет создан новый пользователь, за исключением случаев, когда в базе данных приложения уже есть пользователь с такой электронной почтой (переданной от Facebook). В таком случае процесс прервется с ошибкой и пользователю будет выдано соответствующее сообщение.

  3. Если пользователь зарегистрирован с помощью стороннего сервиса и хочет добавить пароль к своей учетной записи, то он может это сделать с помощью действия "сбросить пароль пользователя"/"reset the user's password". Оно отредактирует пользователя, который входил в систему только через Oauth и скопирует значения почты и пароля в объект пользователя.

Last updated