write:authentication (или read:authentication, чтобы получать список импортов). Они никогда не используют токен конечного пользователя или API-ключ верификации. В примерах MANAGEMENT_BASE выглядит так:
Два способа импорта
Импорт файла
1. Загрузка
Каждый переключатель
keep_* имеет значение true, если вы не передали false. Вызов возвращает 202 и задачу. В одном приложении одновременно может храниться не более 5 загруженных файлов.
2. Проверка пробного прогона
Каждая загрузка начинается с пробного прогона. Он проверяет каждого пользователя и ничего не записывает. ОпрашивайтеGET import-jobs/{id}/:
Если пробный прогон завершился с ошибкой, в ответе перечислены ошибки. Исправьте файл и загрузите его заново.
3. Запуск импорта
POST import-jobs/{id}/start/ импортирует данные, которые прошли пробный прогон, и возвращает 202.
- Пользователи импортируются пакетами по 1 000. Каждый пакет фиксируется отдельно.
- В одном приложении одновременно выполняется только один импорт (иначе возвращается
import_running). - Прерванный импорт продолжается после последнего зафиксированного пакета.
- Пользователи, которые уже импортированы, пропускаются, поэтому один и тот же файл можно запустить повторно.
- Тот, кто запустил импорт, получит письмо по его завершении или остановке.
Пакетный импорт
Отправляйте до 1 000 пользователей в одном запросе сidempotency_key длиной до 100 символов.
- Пробный прогон возвращает
200с результатом и ничего не записывает. - При
dry_run: falseуспешный импорт возвращает201. Если в пакете есть хотя бы одна ошибка, возвращается400, и ни один пользователь не импортируется. - Повторный запрос с уже зафиксированным ключом возвращает сохранённый результат. Тот же ключ с другим содержимым возвращает
400 {"idempotency_key": "different_payload"}. - Параметры Firebase передаются в объекте
firebase:{signer_key, salt_separator, rounds, mem_cost}. GET imports/показывает список зафиксированных пакетов.
Формат файла
JSON
Массив пользователей или объект, в полеusers которого находится массив.
CSV
Те же столбцы, содержащие одно значение, а такжеgoogle_id, apple_id, github_id, microsoft_id, microsoft_tenant_id, organization_slug, organization_name и organization_role. Для пользователя, состоящего в нескольких организациях, указывается отдельная строка для каждой организации.
Дубликаты и существующие аккаунты
- Строки с одинаковым email становятся одним пользователем. Полностью совпадающая строка учитывается как дубликат. Строка с большим количеством ссылок, организаций или приложением-аутентификатором объединяется.
- Два разных хеша пароля, секрета аутентификатора или роли в организации у одного пользователя считаются ошибками. Ошибкой также считается
external_idили идентификатор субъекта провайдера, указанный двумя разными пользователями. - Если аккаунт с таким email уже существует и его создал предыдущий импорт, пользователь пропускается (
already_imported). Если пользователь зарегистрировался самостоятельно, возникает ошибкаidentity_conflict. Импорт никогда не изменяет существующий аккаунт.
Пароли
Параметры Firebase хранятся в зашифрованном виде и только для этого приложения. Любой другой формат или параметр стоимости выше этих пределов означает, что человеку нужно задать новый пароль. После первого успешного входа Didit сохраняет пароль человека заново в своём формате.
Люди без пригодного пароля
Если у человека нет хеша или хеш не поддерживается, попытка входа с паролем получает обычный ответ о неверном пароле. Didit также отправляет ему на email ссылку для установки нового пароля (действует 30 минут, не чаще одного раза в день). Это происходит только в том случае, если его email подтверждён, аккаунт не заблокирован и вход по паролю включён. В результатеreset_required считает людей без пригодного пароля. reset_emails считает среди них тех, у кого email подтверждён: только до них можно дотянуться таким способом. Люди с неподтверждённым email не могут войти по паролю. Они по-прежнему могут войти по коду из email, если вы включите этот способ.
Социальные связи, аутентификаторы и организации
- Социальные связи сохраняются для провайдеров, которые ваше приложение уже настроило, с его текущим идентификатором клиента. Повторный вход в этом случае не требует подтверждения по email. Идентификаторы (subject) Google и GitHub глобальны. Идентификаторы Apple привязаны к команде разработчиков, а идентификаторы Microsoft к регистрации приложения, поэтому такие связи совпадают только в том случае, если ваша старая платформа использовала ту же команду или ту же регистрацию. Связи с провайдерами, которых вы не настроили, учитываются как
social_unavailableи не импортируются. - Приложения-аутентификаторы (секреты TOTP: SHA-1, 6 цифр, 30 секунд) хранятся в зашифрованном виде. Импортированные люди должны использовать их как второй фактор. Коды восстановления для них не создаются.
- Организации, которых ещё нет, создаются по их слагу.
- Ключи доступа импортировать нельзя. Они привязаны к домену, использовавшемуся для старого входа, поэтому люди добавляют новый ключ доступа после входа через Didit.
Результаты
Каждый пробный запуск, пакет и задача возвращает один и тот жеresult:
Ответы никогда не содержат хешей паролей, солей, секретов аутентификаторов или значений полей.
Перед переключением
Проверьте в своём приложении в песочнице:- вход с каждым импортируемым форматом пароля,
- письмо со ссылкой для установки нового пароля для человека без пригодного хеша,
- вход через соцсети и коды аутентификатора для импортированных людей,
- повторный запуск того же файла.
vendor_data каждого человека совпадает со значением, которое вы используете для его верификаций и транзакций.