write:authentication (ou de read:authentication pour les lister). Ils n’utilisent jamais un jeton d’utilisateur final ni une clé API de vérification. Dans les exemples, MANAGEMENT_BASE correspond à :
Deux façons d’importer
Importer un fichier
1. Envoi
Chaque commutateur
keep_* vaut true, sauf si vous envoyez false. L’appel renvoie 202 avec une tâche. Une application conserve au maximum 5 fichiers envoyés à la fois.
2. Vérifier la simulation
Chaque envoi lance une simulation. Elle contrôle chaque personne sans rien écrire. InterrogezGET import-jobs/{id}/ :
Une simulation échouée liste ses erreurs. Corrigez le fichier, puis envoyez-le à nouveau.
3. Lancer l’import
POST import-jobs/{id}/start/ importe ce que la simulation a contrôlé et renvoie 202.
- Les personnes sont importées par lots de 1 000. Chaque lot est enregistré séparément.
- Un seul import s’exécute à la fois par application (sinon
import_running). - Un import interrompu reprend après son dernier lot enregistré.
- Les personnes déjà importées sont ignorées, vous pouvez donc relancer le même fichier.
- La personne qui a lancé l’import reçoit un e-mail à la fin ou à l’arrêt de celui-ci.
Importer par lots
Envoyez jusqu’à 1 000 personnes par requête, avec uneidempotency_key de 100 caractères maximum.
- Une simulation renvoie
200avec le résultat et n’écrit rien. - Avec
dry_run: false, un import réussi renvoie201. Un lot comportant une erreur renvoie400et n’importe aucune personne. - Répéter une requête enregistrée avec la même clé renvoie son résultat enregistré. La même clé avec un contenu différent renvoie
400 {"idempotency_key": "different_payload"}. - Les paramètres Firebase vont dans un objet
firebase:{signer_key, salt_separator, rounds, mem_cost}. GET imports/liste les lots enregistrés.
Format du fichier
JSON
Un tableau de personnes, ou un objet dontusers contient le tableau.
CSV
Les mêmes colonnes à valeur unique, plusgoogle_id, apple_id, github_id, microsoft_id, microsoft_tenant_id, organization_slug, organization_name et organization_role. Une personne membre de plusieurs organisations occupe une ligne par organisation.
Doublons et comptes existants
- Les lignes ayant le même e-mail forment une seule personne. Une ligne identique est comptée comme doublon. Une ligne comportant davantage de liens ou d’organisations, ou un authentificateur, est fusionnée.
- Deux hachages de mot de passe, secrets d’application d’authentification ou rôles d’organisation différents pour une même personne sont des erreurs. Il en va de même pour un
external_idou un identifiant de compte chez un fournisseur revendiqué par deux personnes. - Si un compte avec cet e-mail existe déjà et qu’un import précédent l’a créé, la personne est ignorée (
already_imported). Si la personne s’est inscrite d’elle-même, il s’agit d’une erreuridentity_conflict. Un import ne modifie jamais un compte existant.
Mots de passe
Les paramètres Firebase sont stockés chiffrés, et uniquement pour cette application. Tout autre format, ou un coût supérieur à ces limites, impose à la personne de définir un nouveau mot de passe. Après la première connexion réussie d’une personne, Didit enregistre à nouveau son mot de passe dans son propre format.
Personnes sans mot de passe utilisable
Lorsqu’une personne n’a pas de hachage, ou un hachage non pris en charge, une tentative de connexion par mot de passe reçoit la réponse habituelle de mot de passe incorrect. Didit lui envoie aussi un e-mail contenant un lien pour définir un nouveau mot de passe (valable 30 minutes, envoyé au plus une fois par jour). Cela ne se produit que si son e-mail est vérifié, si le compte n’est pas bloqué et si la connexion par mot de passe est activée. Dans le résultat,reset_required compte les personnes sans mot de passe utilisable. reset_emails compte, parmi elles, celles dont l’e-mail est vérifié : seules celles-ci peuvent être jointes de cette manière. Les personnes dont l’e-mail n’est pas vérifié ne peuvent pas se connecter avec un mot de passe. Elles peuvent toutefois se connecter avec un code envoyé par e-mail, si vous activez cette méthode.
Liens sociaux, authentificateurs et organisations
- Les liens sociaux sont conservés pour les fournisseurs que votre application a déjà configurés, sous son ID client actuel. Une connexion ultérieure ne nécessite alors aucune preuve de l’e-mail. Les identifiants (sujets) Google et GitHub sont globaux. Les identifiants Apple dépendent de l’équipe de développement, et ceux de Microsoft de l’enregistrement de l’application : ces liens ne correspondent donc que si votre ancienne plateforme utilisait la même équipe ou le même enregistrement. Les liens vers des fournisseurs que vous n’avez pas configurés sont comptés comme
social_unavailableet ne sont pas importés. - Les applications d’authentification (secrets TOTP : SHA-1, 6 chiffres, 30 secondes) sont stockées chiffrées. Les personnes importées doivent les utiliser comme second facteur. Elles ne reçoivent aucun code de récupération.
- Les organisations qui n’existent pas encore sont créées à partir de leur slug.
- Les clés d’accès ne peuvent pas être importées. Elles appartiennent à votre ancien domaine de connexion ; les personnes en ajoutent donc une nouvelle après s’être connectées avec Didit.
Résultats
Chaque essai à blanc, lot et tâche renvoie le mêmeresult :
Les réponses ne contiennent jamais de hachages de mots de passe, de sels, de secrets d’authentificateur ni de valeurs de champs.
Avant de basculer
Testez dans votre application sandbox :- la connexion avec chaque format de mot de passe que vous importez,
- l’e-mail de définition d’un nouveau mot de passe pour une personne sans hachage utilisable,
- la connexion via les réseaux sociaux et les codes des applications d’authentification pour les personnes importées,
- l’exécution deux fois du même fichier.
vendor_data de chaque personne correspond à la valeur que vous utilisez pour ses vérifications et transactions.