Oriente.Acessos.Client

Liga um app .NET ao AcessoService, o registro central de acessos da Oriente Farma. É um data provider do Audit.NET: quem captura url, corpo, status, exceção, IP e usuário é o Audit.WebApi — este pacote só entrega isso ao serviço.

Você não escreve DTO, HttpClient nem filtro. Se estiver escrevendo, parou de usar o pacote.

Instalar

dotnet add package Oriente.Acessos.Client
dotnet add package Audit.WebApi.Core

Ligar

appsettings.json — a URL pode ficar aqui, a chave não:

{
  "Acessos": {
    "Url": "http://servicos_acessoservice:8080",
    "TimeoutSegundos": 5
  }
}

App no Easypanel usa o nome interno do serviço — o tráfego não sai da rede e o AcessoService não precisa de domínio nem de DNS público. Fora do Easypanel, use o domínio com https: o pacote recusa http quando o host tem ponto, porque aí a X-Api-Key e o corpo ainda não redigido trafegariam em claro.

A chave vai em env var (Acessos__ApiKey) ou user-secrets. Ela identifica a plataforma: idplataforma e plataforma saem dela, no servidor — o app não escolhe em nome de quem grava.

Program.cs:

builder.Services.AddAcessosAudit(builder.Configuration);

Para a falha de envio cair no log do app em vez de no Trace:

builder.Services.AddAcessosAudit(builder.Configuration,
    aoFalhar: ex => Log.Warning(ex, "Falha ao registrar acesso"));

E o filtro, em AddControllers:

builder.Services.AddControllers(o => o.AddAcessosAuditFilter());

Pronto — duas linhas no Program.cs, e nenhum [AuditApi] em controller nenhum.

O que o filtro liga, e o que não liga

• Todas as actions, sem [AuditApi] em lugar nenhum.
• Corpo da resposta: capturado sempre, mas descartado no caminho feliz — em 2xx/3xx a mensagemerro vira nula e o corpo nem chega a ser serializado. O filtro de action lê context.Result, então capturar custa uma referência ao objeto, não uma cópia da resposta.
• Corpo da requisição: desligado por padrão. Ligue por rota, com AddAcessosAuditFilter(incluirCorpoDaRequisicao: true) ou [AuditApi(IncludeRequestBody = true)] no controller onde o corpo realmente responde "o que o usuário fez".

Por que o corpo da requisição não vem ligado

Não é desempenho, é LGPD. Ligado globalmente, o corpo de toda action de todo app passa a ser enviado — e o serviço mascara credencial, não CPF, nome nem dado de saúde. Num grupo farmacêutico isso concentra dado pessoal sensível numa tabela sem endpoint de leitura, sem cifra e sem controle de acesso próprio.

Ligue onde o corpo é o dado da auditoria. Deixe desligado onde ele é só o formulário do usuário.

O que vai parar em mensagemerro

Só quando a chamada falha. E não é a exceção crua: o pacote a reduz ao que serve numa trilha.

System.InvalidOperationException: Pedido 123 sem itens
 ---> System.ArgumentException: quantidade deve ser maior que zero
   at Oriente.Pedidos.Domain.Pedido.Validar(Int32 quantidade)
   at Oriente.Pedidos.Application.CriarPedidoHandler.Handle(CriarPedido cmd)
   --- End of stack trace from previous location ---
   at Microsoft.AspNetCore.Mvc.Infrastructure.ActionMethodExecutor.Execute()

vira

System.InvalidOperationException: Pedido 123 sem itens | System.ArgumentException: quantidade deve ser maior que zero

A cadeia de causas fica; o stack trace sai. Stack trace responde "onde no código" — pergunta do log da sua aplicação, não da trilha de auditoria — e gasta milhares de caracteres para isso. A trilha responde "o que aconteceu com este usuário nesta rota".

Teto de 2000 caracteres, com ... no corte. E o serviço ainda mascara credencial por cima: mensagem de exceção carrega valor com a mesma facilidade que corpo de requisição.

Marque o que não pode ser registrado

[HttpPost("login")]
public IActionResult Login([AuditIgnore] LoginRequest requisicao) { ... }

O serviço mascara antes de gravar — em url, requisicao e mensagemerro:

• credencial: senha, password, token, authorization, bearer, jwt, apiKey, secret, cookie, sessao, pin, cartao, cvv
• documento de pessoa: cpf, cnpj

A máscara olha o nome do campo, não o formato do valor. Casar 11 dígitos pegaria código de produto e número de nota junto. Por isso /api/clientes/12345678900 — CPF no caminho da rota, sem nome de campo — não é alcançado: a saída aí é o app não pôr documento em rota.

O que ele não pega: segredo em prosa. "usuário X com senha Y não encontrado" não é mascarado, porque a máscara casa chave: valor e chave=valor, não texto corrido. Se a sua exceção monta frase com o valor dentro, o [AuditIgnore] é a defesa, não a redação — mas isso é rede de proteção, não desculpa. O que o [AuditIgnore] cobre nem sai da sua aplicação.

O que esperar

• Não derruba nem segura o app. O envio sai do caminho da resposta e falha em silêncio, com timeout curto. Auditoria indisponível não vira app indisponível.
• Perde evento se o serviço cair. Não há fila durável nesta versão. Se algum dia não puder perder nenhum registro, o lugar de resolver é aqui, não no app consumidor.
• mac fica nulo em app web — navegador não entrega MAC. A coluna espera pelos apps que têm essa informação.
• Requisição anônima é registrada como (anonimo). Login que falhou é o registro mais útil da trilha; descartar por falta de usuário jogaria fora justamente ele.