Resumo

  • A RFC 9865 define um cursor opaco para avançar uma consulta SCIM no mesmo endpoint, com os mesmos parâmetros iniciais.
  • Um cursor organiza a navegação do resultado; ele não concede direito adicional, e a autorização da identidade atual deve valer em cada página.

Há uma diferença importante entre conseguir retomar um processamento e estar autorizado a terminá-lo. Um conector de diretório pode iniciar uma busca de usuários, guardar o nextCursor e voltar mais tarde para a página seguinte. Nesse intervalo, uma pessoa pode ter deixado o grupo administrador, um contrato de acesso pode ter mudado ou a regra de visibilidade pode ter sido corrigida. Se o conector interpreta o cursor como uma permissão armazenada, ele transforma uma otimização de paginação em uma autoridade que a RFC não lhe deu.

O protocolo deixa claro o que continua. A primeira consulta paginada leva cursor vazio ou ausente. Para obter outra página, o cliente usa o mesmo endpoint e preserva todos os parâmetros e valores da consulta inicial, mudando somente o cursor para um valor antes entregue pelo provedor. Esse valor é opaco ao cliente. Todo resultado paginado, salvo o último, deve oferecer nextCursor; previousCursor é opcional e não aparece na primeira página. A norma disciplina a continuidade da mesma pergunta. Ela não congela a resposta nem estabelece que a pessoa que segura o valor tenha a mesma posição de autoridade depois.

O tamanho da lista não corrige essa lacuna. count é um máximo desejado: o provedor não pode excedê-lo, mas pode retornar menos. Com count=0, não retorna recursos, apenas totalResults se houver; e o total pode ser omitido se não for estimável. Uma tela com um total numérico é, portanto, uma observação sobre aquela resposta, não um atestado de completude ou permanência. O provedor pode exigir paginação por cursor como único método. Se também suporta índice, escolhe um método padrão e pode expor isso em sua configuração de serviço.

O limite de confidencialidade é a parte que deveria orientar o desenho. Os resultados precisam permanecer estritamente dentro dos recursos que a identidade atual do ator pode acessar, mesmo se o cursor foi emitido em uma busca de outro ator. As verificações de autorização devem continuar enquanto ele percorre o conjunto. A posse de cursor não pode, em hipótese alguma, criar privilégio suplementar. Não é apenas uma recomendação de interface: é a regra que impede um identificador de estado de passar por cima da política local que decide a visibilidade de cada recurso.

Depois de uma mudança de permissão, o ideal é invalidar logo os cursores daquele ator. Caso sejam mantidos, os metadados da coleção, como contagens, precisam refletir as novas permissões. O serviço também deve detectar cursores forjados e evitar mensagens que revelem se algo existe mas está fora de escopo. Nem um expiredCursor comprova que houve revogação, nem uma página devolvida comprova que o direito antigo ainda vale. Cada sinal responde a uma pergunta menor.

Há também o custo de manter estado. Se cada cursor retiver muitos dados, consultas iniciais em massa podem produzir indisponibilidade. A RFC recomenda autenticar conjuntos grandes, limitar ritmo, definir teto para cursores ou tamanho de página e tornar a invalidação eficiente. A falta de números publicados para timeout, tamanho padrão ou máximo não é evidência de ausência de controle. Política local não se lê pela lacuna de uma configuração pública.

Heng Lu oferece a disciplina adequada: uma especificação comum coordena participantes, mas não substitui decisões que precisam ser tomadas no sistema que está operando. A RFC 9865 torna verificável uma sequência de consulta. A autorização atual, a adoção e a decisão de negócio feita sobre o resultado continuam sendo responsabilidades distintas. O cursor segue a lista. O direito precisa ser decidido de novo.

Sources