Inizia
Integrazione / SDK
Verifica degli utenti
Verifica aziendale
Monitoraggio delle transazioni
Changelogwrite:authentication (o read:authentication per elencarle). Non usano mai un token dell’utente finale né una chiave API di verifica. Negli esempi, MANAGEMENT_BASE è:
Due modi per importare
Importare un file
1. Caricamento
Ogni interruttore
keep_* è true a meno che tu non invii false. La chiamata restituisce 202 con un processo. Un’applicazione può avere al massimo 5 file caricati alla volta.
2. Verifica dell’esecuzione di prova
Ogni caricamento avvia un’esecuzione di prova. Controlla ogni persona e non scrive nulla. InterrogaGET import-jobs/{id}/:
Un’esecuzione di prova fallita elenca i propri errori. Correggi il file e caricalo di nuovo.
3. Avvia l’importazione
POST import-jobs/{id}/start/ importa ciò che l’esecuzione di prova ha verificato e restituisce 202.
- Le persone vengono importate in batch da 1.000. Per ogni batch viene eseguito il commit separatamente.
- Per applicazione può essere in esecuzione una sola importazione alla volta (altrimenti
import_running). - Un’importazione interrotta riprende dopo l’ultimo batch confermato.
- Le persone già importate vengono saltate, quindi puoi eseguire di nuovo lo stesso file.
- Chi ha avviato l’importazione riceve un’email quando questa termina o si ferma.
Importare in batch
Invia fino a 1.000 persone per richiesta, con unidempotency_key di massimo 100 caratteri.
- Un’esecuzione di prova restituisce
200con il risultato e non scrive nulla. - Con
dry_run: false, un’importazione riuscita restituisce201. Un batch con anche un solo errore restituisce400e non importa nessuno. - Ripetere una richiesta già confermata con la stessa chiave restituisce il suo risultato registrato. La stessa chiave con contenuto diverso restituisce
400 {"idempotency_key": "different_payload"}. - I parametri Firebase vanno in un oggetto
firebase:{signer_key, salt_separator, rounds, mem_cost}. GET imports/elenca i batch confermati.
Formato del file
JSON
Un array di persone, oppure un oggetto il cui campousers contiene l’array.
CSV
Le stesse colonne con un solo valore, piùgoogle_id, apple_id, github_id, microsoft_id, microsoft_tenant_id, organization_slug, organization_name e organization_role. Una persona in più organizzazioni occupa una riga per ogni organizzazione.
Duplicati e account esistenti
- Le righe con la stessa email diventano una sola persona. Una riga identica viene contata come duplicato. Una riga con più collegamenti, organizzazioni o un autenticatore viene unita.
- Due hash di password, segreti di autenticazione o ruoli nelle organizzazioni diversi per una stessa persona sono errori. Lo è anche un
external_ido un subject di un provider rivendicato da due persone. - Se esiste già un account con quell’email e un’importazione precedente lo ha creato, la persona viene saltata (
already_imported). Se la persona si era registrata da sola, si tratta di un erroreidentity_conflict. Un’importazione non modifica mai un account esistente.
Password
I parametri Firebase sono memorizzati cifrati, e solo per quella applicazione. Qualsiasi altro formato, o un costo superiore a questi limiti, significa che la persona deve impostare una nuova password. Dopo il primo accesso riuscito di una persona, Didit memorizza di nuovo la sua password nel proprio formato.
Persone senza una password utilizzabile
Quando una persona non ha un hash, o ne ha uno non supportato, un tentativo di accesso con password riceve la normale risposta relativa a una password errata. Didit le invia inoltre via email un link per impostare una nuova password (valido 30 minuti, al massimo una volta al giorno). Ciò avviene solo se la sua email è verificata, l’account non è bloccato e l’accesso con password è attivo. Nel risultato,reset_required conta le persone senza una password utilizzabile. reset_emails conta quelle tra loro con un’email verificata: solo loro possono essere raggiunte in questo modo. Le persone con un’email non verificata non possono accedere con una password. Possono comunque accedere con un codice via email, se abiliti questo metodo.
Link social, app di autenticazione e organizzazioni
- I link social vengono mantenuti per i provider che la tua applicazione ha già configurato, con il client ID attuale. Un accesso successivo non richiede quindi una prova via email. I subject di Google e GitHub sono globali. I subject di Apple sono per team di sviluppatori e quelli di Microsoft per la registrazione dell’app, quindi questi link corrispondono solo se la vecchia piattaforma usava lo stesso team o la stessa registrazione. I link verso provider non configurati sono conteggiati come
social_unavailablee non vengono importati. - Le app di autenticazione (segreti TOTP: SHA-1, 6 cifre, 30 secondi): i segreti sono memorizzati cifrati. Le persone importate devono usarle come secondo fattore. Non ricevono codici di recupero.
- Le organizzazioni che non esistono ancora vengono create a partire dal loro slug.
- Le passkey non possono essere importate. Appartengono al vecchio dominio di accesso, quindi le persone aggiungono una nuova passkey dopo aver effettuato l’accesso con Didit.
Risultati
Ogni simulazione, batch e job restituisce lo stessoresult:
Le risposte non contengono mai hash delle password, salt, segreti degli autenticatori o valori dei campi.
Prima di passare al nuovo sistema
Testa nella tua applicazione sandbox:- l’accesso con ciascun formato di password che importi,
- l’email per impostare una nuova password per una persona senza un hash utilizzabile,
- l’accesso social e i codici degli autenticatori per le persone importate,
- l’esecuzione dello stesso file due volte.
vendor_data di ciascuna persona corrisponda al valore che usi per le sue verifiche e transazioni.