Resumo

  • Cada bloqueio WebDAV recebe um token único gerado pelo servidor. Apresentá-lo no campo If prova o envio daquele identificador, não a identidade do cliente, seu privilégio de escrita ou a continuidade do bloqueio.
  • Uma alteração válida depende de decisões separadas: autenticar o principal, autorizar a operação, resolver todos os recursos afetados, avaliar condições e ETags, verificar bloqueios e criadores e confirmar o estado no instante do commit.
  • Locks compartilhados, coleções com profundidade infinita, COPY/MOVE e timeouts escolhidos pelo servidor impedem que o token seja um arrendamento portátil. Ele é evidência limitada de coordenação.

Um identificador que escapou do seu contexto

Um cliente cria um lock, recebe o token e o registra para diagnóstico. A linha aparece no observability lake, em um ticket e numa ferramenta de suporte. Dias depois, outra sessão apresenta o mesmo valor em uma tentativa de PUT.

Se o servidor faz apenas a comparação textual, o vazamento de um dado de coordenação vira autorização. Se recusa, alguém pode dizer que rejeitou “o dono do lock”. A formulação correta está em RFC 4918: ao modificar um recurso bloqueado, o servidor deve verificar que o principal autenticado corresponde ao criador, além de validar a apresentação do token. O lock também não concede todos os privilégios de modificação. A autorização normal continua obrigatória.

O valor responde “qual lock a requisição conhece?”. Não responde quem está autenticado, qual operação essa pessoa pode fazer, que recursos serão alterados nem se o estado ainda existe. O erro arquitetural começa quando a organização exige que uma só string responda a todas essas perguntas.

Unicidade não é delegação

WebDAV amplia HTTP para autoria remota, propriedades, coleções, operações de namespace e prevenção de colisões. O lock de escrita busca reduzir a perda de atualização causada por autores que sobrescrevem trabalho alheio sem perceber.

Cada lock tem exatamente um token único criado pelo servidor. O cliente não deve interpretar sua estrutura. RFC 4918 exige que a URI seja única entre recursos e ao longo do tempo. Um novo LOCK bem-sucedido devolve o valor no header de resposta Lock-Token e no corpo.

Essa exigência forte protege a referência: o servidor encontra o registro certo. Não cria um direito. A propriedade DAV:lockdiscovery pode tornar locks ativos visíveis, de modo que segurança baseada apenas na obscuridade do token contradiz o próprio modelo.

A especificação recomenda URNs UUID, mantém o esquema permanente opaquelocktoken e admite outra URI única. RFC 9562 recomenda um gerador pseudoaleatório criptograficamente seguro quando a imprevisibilidade é necessária. Aleatoriedade reduz adivinhação; não avalia DAV:write-content, DAV:bind ou qualquer política de negócio.

Há seis conceitos que precisam continuar separados: unicidade distingue locks; imprevisibilidade reduz descoberta; apresentação demonstra conhecimento; autenticação identifica o principal; autorização define a ação permitida; execução transforma o estado atual. O token não deve ocupar os três últimos lugares.

Criar o lock não é possuir o recurso

O criador tem relação especial com seu lock, mas só consegue usá-lo dentro dos privilégios ordinários. O servidor pode permitir que um administrador, o proprietário do recurso ou outro principal privilegiado destrua um lock abandonado.

RFC 3744 detalha o que “escrever” pode significar. DAV:write-content cobre conteúdo existente; DAV:write-properties, propriedades; DAV:bind, a inclusão de membros em coleções; DAV:unlock, o UNLOCK feito por alguém diferente do criador. Um PUT para uma URI ainda não mapeada depende do privilégio de bind na coleção pai.

Assim, ter permissão de escrita não autoriza ignorar o lock de outra pessoa. Ter o token não autoriza ignorar a ACL. E o override administrativo precisa aparecer como exceção autorizada e atribuída, não como posse fictícia.

Na linguagem de Heng Lu, o registro é útil sem se tornar soberano. O token registra uma relação de coordenação criada pelo servidor. A autoridade prática fica com os sistemas capazes de autenticar, avaliar política, resolver namespace, alterar o repositório e recuperar falhas.

O campo If faz dois trabalhos

If carrega condições e também apresenta tokens de estado. Como expressão, uma state list combina suas condições por AND; listas alternativas funcionam por OR; Not nega o item seguinte. Listas sem tag se aplicam à Request-URI, enquanto listas tagged nomeiam o recurso relevante.

Ao mesmo tempo, a mera aparição de um token no campo conta como apresentação ao servidor. Isso permanece verdadeiro ainda que outra lista alternativa seja a que satisfaça a expressão. A distinção permite que uma operação multi-recurso entregue todos os tokens necessários sem transformar a sintaxe em uma única condição linear.

Um gateway que preserva apenas o “ramo vencedor” pode eliminar um token exigido. Um log que guarda só “token presente” pode ocultar o fracasso de um ETag. A telemetria correta registra os tokens apresentados, as listas avaliadas, seus recursos e o resultado.

Os erros também têm significados diferentes. If falso leva a 412 Precondition Failed, após a autorização. Falta do token exigido para um recurso bloqueado afetado leva a 423 Locked com a precondição lock-token-submitted. Um é falha da afirmação de estado; o outro é falta de evidência de lock.

O header Lock-Token é mais estreito: retorna um novo token em resposta a LOCK e identifica o lock removido por UNLOCK. Métodos como PUT, PROPPATCH, COPY, MOVE e DELETE usam If para apresentar os state tokens.

O recurso afetado pode estar fora da tela

Um lock tem raiz, escopo, tipo e profundidade. O lock direto nasce na URL raiz. Um lock depth-infinity numa coleção alcança indiretamente os descendentes e os membros que entram depois.

Logo, um arquivo pode estar sob um lock criado na coleção pai. Consultar apenas a URL exibida pela interface não reproduz a decisão do repositório.

LOCK admite Depth 0 ou infinity e usa infinity por padrão. Se um descendente incompatível impede o lock da hierarquia, o servidor não pode deixar uma árvore parcialmente bloqueada. A operação deve ser integral no escopo, podendo usar Multi-Status para apontar o impedimento.

COPY, MOVE e DELETE ampliam o conjunto. Há origem, destino, coleção pai e, às vezes, um recurso sobrescrito. Os tokens requeridos para todos os recursos que precisam estar desbloqueados devem ser apresentados.

MOVE deixa clara a falta de portabilidade. Um lock direto não acompanha o recurso para a nova URL. O recurso pode sair do escopo indireto da coleção de origem e entrar no lock depth-infinity da coleção de destino. O token antigo não se transforma em direito de seguir o conteúdo.

Uma camada de autorização que recebe apenas um caminho e um token não consegue decidir corretamente uma alteração em várias relações de namespace. O conjunto afetado deve ser calculado antes e revisto no commit.

Compartilhado não significa um token coletivo

Locks compartilhados permitem outros locks compartilhados compatíveis. Cada LOCK bem-sucedido ainda cria um registro e um token próprios. Três colaboradores têm três locks, não uma senha comunitária.

Refresh de um não renova os demais. UNLOCK remove o lock indicado e não garante que o recurso ficou livre: outro lock compartilhado ou herdado pode continuar válido.

O aplicativo define fusão, revisão, ordem e resolução de desacordo. WebDAV define compatibilidade e coordenação. O adjetivo “shared” não cria voto, propriedade coletiva ou um principal grupal.

Uma interface operacional precisa mostrar criador, raiz, profundidade, relação direta ou indireta, escopo, timeout e qual lock cada UNLOCK removeu. O indicador binário locked/unlocked é insuficiente.

Timeout é decisão do servidor

O cliente pode sugerir uma duração em Timeout, mas o servidor escolhe o valor concedido, podendo ignorar ou mudar a sugestão.

O refresh usa LOCK sem corpo e um token em If. O servidor ignora Depth, reinicia o contador se aceitar, não altera locks compartilhados vizinhos e devolve DAV:lockdiscovery atualizado. Não retorna um novo Lock-Token.

Falha no refresh não pode ser tratada como sucesso. O cliente também não deve garantir que o lock vive até o segundo calculado: override, crash ou perda de estado podem removê-lo. E o relógio local passar da expiração não prova que o servidor já fez a limpeza.

Timeout é obrigação de renovação e mecanismo de coleta, não lease rígido. Antes de um commit relevante, o cliente reapresenta o token e o servidor decide contra lock, versão e política atuais.

Uma trilha de decisão verificável

O caminho seguro separa os passos:

  1. autenticar o principal;
  2. autorizar a operação exata;
  3. resolver origem, destino, pais e alvos de overwrite;
  4. descobrir locks diretos, indiretos, exclusivos e compartilhados;
  5. interpretar por inteiro If, tags, ETags, Not e alternativas;
  6. confirmar todos os tokens exigidos;
  7. vincular o principal ao criador ou a override autorizado;
  8. revalidar no commit e executar com a atomicidade prevista;
  9. registrar se falhou identidade, privilégio, condição, token, escopo ou persistência.

O log pode guardar um fingerprint com chave, não o token bruto. Principal, método, recursos, raízes, profundidades, decisão, timeout efetivo, versão final e status formam a evidência mínima.

Os testes precisam combinar fronteiras: token correto com principal diferente; privilégio sem token; token com ETag falso; novo membro herdando lock infinito; lock de árvore falhando sem resíduo parcial; MOVE sem transportar lock direto e respeitando o destino; vários locks compartilhados dos quais apenas um é renovado; override atribuído; caminho alternativo de escrita que não consegue ignorar coordenação e auditoria.

WebDAV reduz uma classe de lost update. Não resolve deadlock de negócio, merge semântico, acesso direto ao storage, administrador comprometido ou transação distribuída. A especificação mínima funciona melhor quando não recebe autoridade que não foi feita para exercer.

Fontes