write:authentication (o read:authentication per llistar-les). Mai no utilitzen un token d’usuari final ni una clau d’API de verificació. En els exemples, MANAGEMENT_BASE és:
Dues maneres d’importar
Importar un fitxer
1. Pujada
Cada interruptor
keep_* és true tret que enviïs false. La crida retorna 202 amb una tasca. Una aplicació pot tenir com a màxim 5 fitxers pujats alhora.
2. Comprova la simulació
Cada pujada inicia una simulació. La simulació revisa cada persona i no escriu res. ConsultaGET import-jobs/{id}/:
Una simulació fallida enumera els seus errors. Corregeix el fitxer i torna a pujar-lo.
3. Inicia la importació
POST import-jobs/{id}/start/ importa el que va revisar la simulació i retorna 202.
- Les persones s’importen en lots de 1.000. Cada lot es confirma per separat.
- Només s’executa una importació alhora per aplicació (en cas contrari,
import_running). - Una importació interrompuda es reprèn després de l’últim lot confirmat.
- Les persones ja importades s’ometen, de manera que pots executar el mateix fitxer una altra vegada.
- La persona que ha iniciat la importació rep un correu electrònic quan acaba o s’atura.
Importar per lots
Envia fins a 1.000 persones per sol·licitud, amb unaidempotency_key de fins a 100 caràcters.
- Una simulació retorna
200amb el resultat i no escriu res. - Amb
dry_run: false, una importació correcta retorna201. Un lot amb qualsevol error retorna400i no importa ningú. - Si repeteixes una sol·licitud confirmada amb la mateixa clau, es retorna el resultat registrat. La mateixa clau amb un contingut diferent retorna
400 {"idempotency_key": "different_payload"}. - Els paràmetres de Firebase van en un objecte
firebase:{signer_key, salt_separator, rounds, mem_cost}. GET imports/llista els lots confirmats.
Format del fitxer
JSON
Una matriu de persones, o un objecte amb la matriu dins deusers.
CSV
Les mateixes columnes de valor únic, mésgoogle_id, apple_id, github_id, microsoft_id, microsoft_tenant_id, organization_slug, organization_name i organization_role. Una persona en diverses organitzacions ocupa una línia per organització.
Duplicats i comptes existents
- Les línies amb el mateix correu electrònic es converteixen en una sola persona. Una línia idèntica es compta com a duplicat. Una línia amb més enllaços, organitzacions o una aplicació d’autenticació es fusiona.
- Dos hashes de contrasenya, secrets d’autenticació o rols d’organització diferents per a una mateixa persona són errors. També ho és un
external_ido un subjecte del proveïdor que reclamin dues persones diferents. - Si ja existeix un compte amb aquest correu electrònic i una importació anterior l’ha creat, la persona s’omet (
already_imported). Si la persona es va registrar per si mateixa, es produeix un erroridentity_conflict. Una importació mai no modifica un compte existent.
Contrasenyes
Els paràmetres de Firebase s’emmagatzemen xifrats, només per a aquesta aplicació. Qualsevol altre format, o un cost per sobre d’aquests límits, vol dir que la persona necessita una contrasenya nova. Després del primer inici de sessió satisfactori d’una persona, Didit torna a emmagatzemar la seva contrasenya en el seu propi format.
Persones sense una contrasenya utilitzable
Quan una persona no té hash, o en té un que no és compatible, un intent d’inici de sessió amb contrasenya rep la resposta habitual d’error de contrasenya. Didit també li envia per correu un enllaç per establir una contrasenya nova (vàlid durant 30 minuts, com a màxim un cop al dia). Això només passa quan el seu correu està verificat, el compte no està bloquejat i l’inici de sessió amb contrasenya està activat. Al resultat,reset_required compta les persones sense una contrasenya utilitzable. reset_emails compta les que tenen un correu verificat entre elles: només aquestes es poden contactar d’aquesta manera. Les persones amb un correu no verificat no poden iniciar sessió amb contrasenya. Encara poden iniciar sessió amb un codi per correu si actives aquest mètode.
Vincles socials, autenticadors i organitzacions
- Vincles socials es conserven per als proveïdors que la teva aplicació ja té configurats, amb el seu ID de client actual. Un inici de sessió posterior no necessita llavors cap prova del correu. Els subjectes de Google i GitHub són globals. Els subjectes d’Apple són per equip de desenvolupament i els de Microsoft per registre d’aplicació, de manera que aquests vincles només coincideixen si la teva plataforma antiga feia servir el mateix equip o registre. Els vincles amb proveïdors que no has configurat es compten com a
social_unavailablei no s’importen. - Aplicacions d’autenticació (secrets TOTP: SHA-1, 6 dígits, 30 segons): els seus secrets s’emmagatzemen xifrats. Les persones importades han de fer-les servir com a segon factor. No reben codis de recuperació.
- Organitzacions que encara no existeixen es creen a partir del seu slug.
- Claus d’accés no es poden importar. Pertanyen al teu antic domini d’inici de sessió, de manera que les persones n’afegeixen una de nova després d’iniciar sessió amb Didit.
Resultats
Cada execució de prova, lot i tasca retorna el mateixresult:
Les respostes no contenen mai hashes de contrasenyes, sals, secrets d’autenticadors ni valors de camps.
Abans de fer el canvi
Prova a la teva aplicació de sandbox:- l’inici de sessió amb cada format de contrasenya que importes,
- el correu per establir una contrasenya nova per a una persona sense hash utilitzable,
- l’inici de sessió social i els codis d’autenticador per a les persones importades,
- l’execució del mateix fitxer dues vegades.
vendor_data de cada persona coincideix amb el valor que fas servir per a les seves verificacions i transaccions.