Resumo

  • RFC 5397 define uma propriedade protegida e calculada por requisição que retorna um único recurso de principal por HTTP(S), ou o pseudo-principal não autenticado.
  • A URL serve para iniciar novas consultas; não é uma chave humana universal, uma lista completa de representações nem concessão de acesso.
  • Operação robusta separa localização do serviço, autenticação, principal escolhido, validade do cache, descoberta de coleção, privilégio, ação e efeito observado.

O cache preservou uma resposta, não a autoridade

WebDAV ACL já descrevia principais, grupos, listas de controle e os privilégios do usuário atual. Faltava um caminho direto para que o cliente descobrisse qual recurso de principal o servidor associava ao usuário HTTP autenticado. Uma busca DAV:principal-match podia devolver o indivíduo e todos os grupos aos quais ele pertencia.

RFC 5397 criou DAV:current-user-principal. A propriedade contém um DAV:href único ou DAV:unauthenticated. O href deve usar HTTP(S) e ser uma das URLs que o recurso de principal declara. A partir desse ponto o cliente consulta propriedades adicionais e localiza recursos de aplicação.

A resposta bem-sucedida pode ser armazenada para acelerar conexões futuras. RFC 6764 inclusive recomenda guardar os detalhes de descoberta que funcionaram. A recomendação não transforma a cópia local em fonte de autoridade. Falhas persistentes de conexão ou autenticação devem provocar nova busca de serviço e nova descoberta da conta.

O sistema precisa conhecer a procedência da entrada em cache: serviço, momento, autenticação e resposta que a produziram. Sem isso, uma URL antiga pode ser confundida com conta excluída, credencial inválida ou perda de permissão.

Há mais de uma maneira válida de representar o principal

RFC 5397 admite que várias URLs apontem para o mesmo recurso e que vários recursos correspondam ao mesmo principal autenticado. Quando há mais de um candidato, o servidor pode escolher um, embora deva procurar ser consistente.

Essa multiplicidade torna perigoso usar o href como identificador global. Uma reorganização pode trocar o caminho sem trocar a pessoa. Dois serviços podem publicar caminhos iguais para sujeitos diferentes. Um redirecionamento pode preservar acesso sem provar equivalência fora daquela autoridade.

O registro defensável guarda o domínio de autoridade, a solicitação, o resultado de autenticação, a URL, os redirecionamentos e as propriedades lidas depois. A fusão de duas representações exige evidência emitida pelo sistema que governa a identidade. Similaridade textual não basta.

Consistência é um objetivo operacional, não promessa de imobilidade. Alterações inesperadas merecem investigação e correlação com migrações ou versões. Elas não autorizam criação automática de um novo usuário, nem a união silenciosa de históricos.

A propriedade pertence à requisição

O servidor protege a propriedade e a calcula a cada requisição. Por isso ela nunca acompanha COPY ou MOVE. O usuário atual é parte do contexto que observa ou opera o recurso, não uma característica armazenada no documento.

Ferramentas de exportação que serializam essa resposta como metadado congelam uma observação transitória. Depois da migração, outro usuário poderia receber a identidade de quem executou uma requisição antiga. Auditoria de autor de operação e descoberta do principal corrente são registros diferentes.

Esse limite também orienta o monitoramento. A resposta deve ser associada ao pedido e à autenticação que a originaram. Uma tela pode reutilizar informação em cache, mas precisa mostrar quando ela deixou de ser confirmada pelo servidor.

Não autenticado é uma resposta completa

Quando a autenticação não ocorreu ou falhou, o valor deve ser DAV:unauthenticated. Não é um vazio a preencher com a última conta. Preservar essa resposta evita atribuir atividade anônima ou falha ao usuário anterior.

RFC 6764 pede que provedores forcem autenticação em PROPFIND que recupera a propriedade. Assim, a URL corresponde ao solicitante autenticado. Quando a propriedade não é retornada, o cliente talvez tenha de pedir o caminho ao usuário. Ausência abre um fluxo alternativo; não permite inventar o principal com base no nome de login.

Manter o pseudo-principal explícito também melhora a resposta a incidentes. A equipe pode distinguir credencial rejeitada, sessão ausente, propriedade não suportada e recurso de principal indisponível. Um nulo genérico apagaria essas causas.

Descoberta de identidade não decide o ACL

O recurso de principal dá um ponto para conhecer o sujeito. O conjunto de privilégios do usuário atual, definido por RFC 3744, responde o que esse usuário pode fazer sobre um recurso específico. São perguntas ligadas, mas não intercambiáveis.

O usuário pode ler o próprio principal e não escrever numa agenda. Pode pertencer a um grupo sem ter acesso àquele catálogo. Pode possuir privilégio de escrita e falhar numa condição de versão. Um PROPFIND verde não prevê todos os métodos seguintes.

CardDAV ilustra a sequência: descobrir serviço, autenticar, obter principal, localizar o home de catálogos, alcançar o catálogo, aplicar condições, gravar e verificar. Cada transição pode falhar com outro responsável.

O painel útil mostra essa cadeia em vez de “conta conectada”. Uma identidade localizada pode coexistir com home ausente, privilégio negado ou efeito não observado. RFC 5397 nomeia uma etapa, não encerra a operação.

Medir sem copiar dados sensíveis

Não é necessário replicar ACLs e listas de grupos em todos os logs. É necessário manter contexto suficiente: autoridade do serviço, correlação da requisição, classe de autenticação, forma da resposta, identificador limitado da URL, estado do recurso seguinte, decisão de privilégio e resultado.

Dados de identidade e associação precisam de minimização, controle de acesso e retenção. Separar recibos reduz a tentação de armazenar conteúdo completo apenas para compensar um estado agregado que não explica o erro.