Personificação de Usuário

Alguns bugs só existem para uma pessoa. Um registro que não abre, um item de menu que não está lá, um total que parece errado — tudo depende dos papéis web, permissões de tabela e papéis de segurança do Dataverse ligados a esse contato. A personificação de usuário permite que um administrador interno faça login como esse contato e veja exatamente o que vê, depois saia novamente.

Quando ajuda

A personificação responde a perguntas que uma descrição do problema não consegue.

Usando

A possibilidade está no menu de perfil e aparece apenas para usuários autorizados a usá-la.

  1. Faça login como um usuário interno com a função de administrador, depois abra o menu do perfil e escolha Visualizar como outro usuário.
  2. Digite pelo menos três caracteres para buscar por nome ou endereço de e-mail, ou cole um ID de usuário para uma correspondência exata.
  3. Escolha a pessoa e confirme. O portal recarrega como ela — mesmas funções web, mesmas permissões de tabela, mesmas linhas.
  4. Um banner permanece fixado no topo de cada página enquanto durar. Escolha Parar para retornar à sua própria sessão.

Que pode se passar por

Duas condições são verificadas no servidor para cada chamada, independentemente do que a interface oferece:

O alvo é sempre um contato do portal, resolvido apenas pela tabela de contatos. Fornecer o ID de outro usuário interno simplesmente não resolve — não há caminho daqui para uma segunda conta de funcionário.

A personificação só reduz o acesso

Um usuário interno se torna um contato, nunca o contrário e nunca outro usuário interno. Essa direção é o que mantém o recurso seguro para lançar: a sessão personificada só pode fazer menos do que o administrador poderia, então não há privilégio a ser ganho ao usá-la.

Restringendo quem pode ser personificado

Por padrão, todo contato ativo é um candidato. Implemente IImpersonationTargetFilter para restringir isso — para excluir contatos vinculados a contas de funcionários, registros fora da unidade de negócios do administrador ou qualquer outra coisa que sua organização trate como proibida.

O filtro governa tanto a busca quanto a personificação. Um contato que você rejeita é invisível no seletor, e não apenas não selecionável — caso contrário, a busca silenciosamente se tornaria uma forma de enumerar pessoas que um administrador nunca poderá realmente se tornar.

A trilha de auditoria

Cada largada, parada e tentativa recusada é registrada. Recusas são registradas deliberadamente: uma trilha de sucessos sozinha não pode responder se alguém tentou.

O Dataverse não pode registrar quem estava por trás da sessão

O portal se conecta ao Dataverse como um único usuário de aplicação e expressa a sessão logada se passando pelo alvo. O administrador nunca é transmitido, então, no registro de auditoria do Dataverse, "um administrador atuando como contato" e "esse contato entrando normalmente" são indistinguíveis — e qualquer coisa escrita durante a personificação é atribuída ao contato em createdby e modifiedby. A trilha do portal é o único lugar onde essa informação existe, por isso não é opcional.

De imediato, todo evento é escrito no log da aplicação. Implemente IImpersonationAuditSink para persistir isso onde quer que sua organização mantenha seus registros de auditoria — os sinks são adicionados junto ao embutido, em vez de substituí-los.

Do React

A mesma experiência vem para o React: uma entrada no menu de perfil, o seletor e o banner. As ações subjacentes estão ativadas useAuth() se você preferir construir sua própria interface em torno delas.

Vale a pena saber

  • Se o contato personificado mudar a senha no meio da sessão, a sessão termina e você retorna ao estado de desconectado, em vez de para sua própria conta. Fazer login novamente restaura a conta.
  • Personificação não pode ser aninhada. Pare a sessão atual antes de começar outra.
  • Isso não dura mais do que a sessão do navegador — fechar o navegador encerra o processo.