write:authentication (ou read:authentication para as listar). Nunca utilizam um token de utilizador final nem uma chave de API de verificação. Nos exemplos, MANAGEMENT_BASE é:
Duas formas de importar
Importar um ficheiro
1. Carregar
Cada opção
keep_* é true, salvo se enviar false. A chamada devolve 202 com uma tarefa. Uma aplicação mantém no máximo 5 ficheiros carregados em simultâneo.
2. Verificar a simulação
Cada carregamento inicia uma simulação. Esta verifica todas as pessoas e não grava nada. Consulte periodicamenteGET import-jobs/{id}/:
Uma simulação falhada lista os seus erros. Corrija o ficheiro e carregue-o novamente.
3. Iniciar a importação
POST import-jobs/{id}/start/ importa o que a simulação verificou e devolve 202.
- As pessoas são importadas em lotes de 1000. Cada lote é gravado de forma independente.
- Apenas uma importação é executada de cada vez por aplicação (caso contrário, devolve
import_running). - Uma importação interrompida retoma a partir do último lote gravado.
- As pessoas já importadas são ignoradas, por isso pode executar novamente o mesmo ficheiro.
- A pessoa que iniciou a importação recebe um e-mail quando esta termina ou para.
Importar em lotes
Envie até 1000 pessoas por pedido, com umaidempotency_key de até 100 caracteres.
- Uma simulação devolve
200com o resultado e não grava nada. - Com
dry_run: false, uma importação bem-sucedida devolve201. Um lote com qualquer erro devolve400e não importa ninguém. - Repetir um pedido já gravado com a mesma chave devolve o resultado registado. A mesma chave com conteúdo diferente devolve
400 {"idempotency_key": "different_payload"}. - Os parâmetros do Firebase vão num objeto
firebase:{signer_key, salt_separator, rounds, mem_cost}. GET imports/lista os lotes gravados.
Formato do ficheiro
JSON
Uma matriz de pessoas, ou um objeto cujousers contém essa matriz.
CSV
As mesmas colunas de valor único, maisgoogle_id, apple_id, github_id, microsoft_id, microsoft_tenant_id, organization_slug, organization_name e organization_role. Uma pessoa em várias organizações ocupa uma linha por organização.
Duplicados e contas existentes
- As linhas com o mesmo e-mail tornam-se uma só pessoa. Uma linha idêntica é contada como duplicado. Uma linha com mais ligações, organizações ou uma aplicação de autenticação é fundida com a pessoa.
- Dois hashes de palavras-passe diferentes, dois segredos de autenticação diferentes ou duas funções diferentes nas organizações para a mesma pessoa são erros. Também é erro um
external_idou um identificador de fornecedor reivindicado por duas pessoas. - Se já existir uma conta com esse e-mail e uma importação anterior a tiver criado, a pessoa é ignorada (
already_imported). Se a pessoa se tiver registado por conta própria, é um erroidentity_conflict. Uma importação nunca altera uma conta existente.
Palavras-passe
Os parâmetros do Firebase são guardados encriptados, apenas para esta aplicação. Qualquer outro formato, ou um custo acima destes limites, significa que a pessoa precisa de uma nova palavra-passe. Depois do primeiro início de sessão bem-sucedido de uma pessoa, a Didit volta a guardar a palavra-passe dela no seu próprio formato.
Pessoas sem palavra-passe utilizável
Quando uma pessoa não tem hash, ou tem um hash não suportado, uma tentativa de início de sessão com palavra-passe recebe a resposta normal de palavra-passe incorreta. A Didit também lhe envia por e-mail uma ligação para definir uma nova palavra-passe (válida durante 30 minutos, no máximo uma vez por dia). Isto acontece apenas quando o e-mail da pessoa está verificado, a conta não está bloqueada e o início de sessão com palavra-passe está ativado. No resultado,reset_required conta as pessoas sem palavra-passe utilizável. reset_emails conta, entre elas, as que têm um e-mail verificado: só estas podem ser contactadas desta forma. As pessoas com um e-mail não verificado não podem iniciar sessão com palavra-passe. Podem continuar a iniciar sessão com um código enviado por e-mail, se ativar esse método.
Ligações sociais, aplicações de autenticação e organizações
- Ligações sociais são mantidas para os fornecedores que a sua aplicação já configurou, com o ID de cliente atual. Um início de sessão posterior não precisa então de prova de e-mail. Os identificadores do Google e do GitHub são globais. Os identificadores da Apple são por equipa de programadores e os da Microsoft são por registo de aplicação, pelo que essas ligações só correspondem se a sua plataforma antiga usava a mesma equipa ou o mesmo registo. As ligações a fornecedores que não configurou são contadas como
social_unavailablee não são importadas. - Aplicações de autenticação (segredos TOTP: SHA-1, 6 dígitos, 30 segundos) são guardadas encriptadas. As pessoas importadas têm de as usar como segundo fator. Não recebem códigos de recuperação.
- Organizações que ainda não existem são criadas a partir do respetivo slug.
- Chaves de acesso não podem ser importadas. Pertencem ao seu antigo domínio de início de sessão, pelo que as pessoas adicionam uma nova chave de acesso depois de iniciarem sessão com a Didit.
Resultados
Cada simulação, lote e tarefa devolve o mesmoresult:
As respostas nunca contêm hashes de palavras-passe, salts, segredos de aplicações de autenticação nem valores de campos.
Antes de fazer a transição
Teste na sua aplicação de sandbox:- o início de sessão com cada formato de palavra-passe que importar,
- o e-mail para definir uma nova palavra-passe de uma pessoa sem hash utilizável,
- o início de sessão social e os códigos das aplicações de autenticação das pessoas importadas,
- a execução do mesmo ficheiro duas vezes.
vendor_data de cada pessoa corresponde ao valor que usa para as suas verificações e transações.