Общее руководство по переносу вашей существующей базы данных пользователей в Logto
В этой статье представлено, как использовать существующие инструменты для переноса предыдущих пользовательских данных в Logto, в ситуации, когда Logto еще не предоставила услуги миграции данных.
Darcy YeDeveloper
Хватит тратить недели на аутентификацию пользователей
Запускайте безопасные приложения быстрее с Logto. Интегрируйте аутентификацию пользователей за считанные минуты и сосредоточьтесь на вашем основном продукте.
Logto еще не имеет ряда инструментов для миграции данных, но мы раскрыли базовые возможности Management API. Это не помешает пользователям завершить миграцию существующих баз данных пользователей, написав скрипты.
Учитывая некоторые потребности, полученные от пользователей сообщества, и тот факт, что у нас в настоящее время нет документации, объясняющей конкретные шаги миграции базы данных пользователей, мы делаем подходящее введение в этой статье, чтобы помочь пользователям найти конкретные идеи и сэкономить время на чтении кода и документации Logto.
Шаг 1: Понимание базовой структуры данных пользователей Logto и вариантов использования#
Logto использует базу данных PostgreSQL под своим капотом. Помимо различных преимуществ по производительности, важной причиной является то, что она поддерживает пользовательский тип данных JSON / JSONB и позволяет создавать индексы на внутренние значения данных типа JSON, обеспечивая баланс между производительностью базы данных и расширяемостью.
Что касается структуры данных пользователей Logto, пожалуйста, обратитесь к ссылке пользователя чтобы понять все детали. Здесь мы сосредоточимся на описании некоторых аспектов, в которых Logto может отличаться от других служб идентификации.
Это случайно сгенерированный внутренний уникальный идентификатор для пользователей Logto. Пользователи не знают об id при использовании сервисов на базе Logto.
Инженеры, знакомые с базами данных, не должны найти это странным. Даже самые примитивные системы идентификации будут иметь id для уникальной идентификации пользователей, хотя их формы часто отличаются. Некоторые службы идентификации могут использовать имя пользователя для уникальной идентификации пользователей.
Здесь username, основной email, основной телефон - то, в чем Logto сильно отличается от других систем идентификации - все они могут служить уникальными идентификаторами, которые воспринимаются конечным пользователем.
Во многих других системах идентификации имя пользователя используется для идентификации (имена пользователей не могут дублироваться между учетными записями), что легко понять.
Но в Logto основной email/телефон также используются для различения пользователей. То есть, если пользователь A уже имеет основной email [email protected], то другие пользователи B не могут добавить этот адрес электронной почты в качестве своего основного e-mail'а. Основной телефон работает аналогично.
Некоторые другие системы идентификации позволяют регистрировать несколько учетных записей с разными именами пользователей, но привязывать одну и ту же электронную почту/телефон, что не допускается в Logto (e-mail'ы/телефоны могут быть добавлены в customData Logto). Это связано с тем, что основной e-mail/телефон в Logto могут быть использованы для входа без пароля.
Logto определяет это поле identities как JSON-тип, его определение типа:
В последние годы, чтобы облегчить привлечение новых пользователей, системы идентификации позволяют пользователям быстро войти в систему через некоторые существующие социальные учетные записи с большой базой пользователей, такие как google / facebook, и т.д.
В приведенном ниже примере поле identities хранит информацию о входе в социальную сеть:
Где facebook и github - это имена социальных провайдеров, userId - это id социального аккаунта пользователя, используемого для входа. В details также включены некоторые другие данные, которые пользователь разрешил социальному провайдеру отображать, которые будут добавлены в профиль пользователя Logto в определенное время.
Если в предыдущей базе данных содержится имя (например, facebook, google) и id социального провайдера, используемого пользователем (см. userId в предыдущем примере), то пользователь Logto может прямо войти в систему с тем же социальным аккаунтом.
Это поле может хранить любую информацию, относящуюся к пользователю, такую как вышеупомянутые электронная почта/телефоны, которые не могут быть использованы для входа в систему без пароля (могут быть использованы для получения уведомлений или для других деловых функций), и т.д.
Другие поля относительно легко понять (за исключением passwordEncrypted и passwordEncryptionMethod, которые будут объяснены позже), пожалуйста, прочитайте документацию самостоятельно.
Для миграции базы данных в большом масштабе написание скриптов миграции является наиболее распространенным подходом. Мы предоставим простой пример, чтобы помочь понять, как написать скрипты миграции, чтобы удовлетворить различные потребности.
Следует отметить, что при написании скриптов миграции, мы пропускаем процесс извлечения исходных данных, потому что существует множество способов получить данные, например, экспортировать из базы данных в файлы, а затем читать файлы, или извлекать через API. Это не является основным сюжетом скрипта миграции, поэтому мы не будем обсуждать их подробно здесь.
Когда вы видите tenant_id в скрипте миграции, вам может показаться это странным. Logto основана на многоклиентской архитектуре. Для пользователей открытого исходного кода Logto (Logto OSS), вы можете просто установить tenant_id пользователя в default.
Для пользователей самостоятельно размещаемого Logto OSS, подключение к базе данных легко получить. Однако для пользователей облачного Logto, по причинам безопасности, мы в настоящее время не можем предоставить разрешения на подключение к базе данных пользователей. Пользователям нужно обратиться к API Docs и использовать API связанные с Пользователем для миграции пользователей. Мы понимаем, что этот метод не подходит для миграции большого количества пользовательских данных, но все же может обрабатывать перенос ограниченного числа пользователей на данном этапе.
Шаг 3: Проблема миграции хешированного пароля и возможное обходное решение#
В нашем предыдущем блоге мы говорили о некоторых мерах по предотвращению атак на пароли. Одна вещь, которую могут сделать провайдеры инфраструктуры идентификации, - это не хранить пароли в открытом тексте, а сохранять хешированные пароли.
Другой блог объяснит хеши паролей, где мы заявили, что хеш-значения необратимы.
Второй блог также сравнивает эволюцию некоторых хеш-алгоритмов. Logto сама использует упомянутый в статье алгоритм Argon2i и не поддерживает другие хеш-алгоритмы на данный момент. Это означает, что хеш-значения паролей старых баз данных пользователей, использующих другие хеш-алгоритмы, не могут быть прямо перенесены в базу данных Logto.
Даже если Logto поддерживает другие общеиспользуемые хеш-алгоритмы, помимо Argon2i, все равно будет сложно прямо перенести старые данные из-за гибкости соли при применении хеш-алгоритмов.
Помимо поддержки других хеш-алгоритмов в будущем, Logto, вероятно, также предоставит пользовательские методы вычисления соли для приспособления к различным ситуациям.
До тех пор вы можете использовать конфигурацию знакомство с входом в систему Logto, чтобы разрешить пользователям входить в систему другими способами (например, электронная почта + код проверки) и заполнять новый пароль (который будет использовать алгоритм хеширования Argon2i) перед входом в приложение. Затем новый пароль можно использовать для входа в систему позже.
Следует отметить, что если исходные данные пользователя поддерживают только вход в систему с паролем, упомянутое выше обходное решение не будет работать для этого сценария. Это потому, что ранее упомянутое обходное решение фактически решает проблему несовместимости хеша пароля, используя альтернативные способы входа в систему и обеспечивая механизм "завершения необходимой информации" в потоке конечного пользователя Logto.
Так что, если в исходных данных пользователя поддерживается только вход в систему с паролем, обходное решение не сможет решить эту ситуацию, поскольку нет доступных альтернативных вариантов входа.
Указанное здесь обходное решение на самом деле не решает проблему миграции хешированного пароля, но предлагает альтернативное решение с точки зрения продукта Logto, чтобы избежать препятствий для пользователей при входе в ваш продукт.
Шаг 4: Постепенный переход на Logto и мониторинг состояния#
После выполнения вышеуказанных шагов конечные пользователи уже могут войти в систему и использовать вашу услугу через Logto.
Поскольку сервис обычно не отключается во время миграции, возможно, что синхронизированные в Logto пользовательские данные не обновлены. При обнаружении таких редких случаев необходимо выполнить синхронизацию из старой базы данных в Logto.
После более продолжительного периода времени (или могут применяться и другие определенные метрики) без случаев несоответствия данных, старую базу данных можно полностью отбросить.
В этом посте мы представили шаги, через которые проходит идеальная миграция базы данных.
Если у вас возникнут проблемы, не упомянутые выше, не стесняйтесь присоединиться к нашему сообществу или обратиться к нам за помощью. Проблемы, с которыми вы сталкиваетесь, могут также столкнуться другие, и они станут вопросами, которые мы должны учитывать при проектировании инструментов миграции в будущем.
