CS Coder
UniGUI

Isolamento de dados no UniGUI: um usuário não pode herdar o estado de outro

Revise variáveis globais, conexões, caches e autorização com um roteiro que diferencia vazamento de sessão e conflito de gravação.

· 4 min de leitura
Objetivo e formato

Detectar estado compartilhado indevido e separar isolamento de autorização

Artigo · análise e investigação · Intermediário
Antes de experimentar

MainModule, ServerModule e noções de acesso a dados

Delphi 11.3 e 13.2 como referência; confirme a versão instalada do UniGUI

Imagine que o usuário A seleciona o cliente 10 e o usuário B seleciona o cliente 20. Se a seleção estiver em uma variável global, a próxima operação de A pode usar o cliente escolhido por B. O problema não está no botão; está no escopo do dado.

Há ainda um problema diferente: dois usuários autorizados podem editar o mesmo registro e sobrescrever alterações. Isolamento de sessão e controle de concorrência no banco são necessidades relacionadas, mas distintas.

Procure os pontos de compartilhamento

A documentação UniGUI alerta para o atendimento de múltiplos usuários no mesmo processo e orienta o uso de MainModule para variáveis de sessão. O ServerModule deve ser tratado como recurso compartilhado; estado mutável exige análise de concorrência. Handling Concurrency.

Procure variáveis declaradas no escopo de unit, objetos estáticos, datasets globais e caches sem chave de usuário ou organização. Classifique cada ocorrência: configuração, recurso compartilhado intencional ou estado que deveria ser particular.

Nem todo recurso compartilhado é errado. Uma configuração imutável pode atender várias sessões. A pergunta é se ele contém dados privados, muda durante uma operação ou depende da identidade atual.

Isole também a consulta

Guardar OrganizacaoID no lugar correto não basta se a consulta ignora essa informação. Uma leitura multiempresa precisa aplicar a fronteira do domínio e validar a identidade no servidor.

text
Receber identificador solicitado
Obter identidade e organização do contexto autenticado
Verificar autorização para a operação
Consultar registro dentro do escopo permitido
Devolver somente os dados necessários

Esse pseudocódigo evita expor uma API de autenticação que não foi definida no seu projeto. Não aceite a organização enviada pela interface como prova de autorização. Um usuário pode modificar uma requisição fora do fluxo normal da tela.

Em uma consulta SQL parametrizada, o filtro de organização deve vir de um contexto confiável. Parâmetros ajudam a separar dados e comando; eles não resolvem uma política de acesso ausente.

Conexão e dataset têm estado

Uma conexão pode carregar transação, configuração e outros estados. Um dataset aberto mantém posição e resultado. Compartilhar esses objetos de forma indiscriminada pode misturar operações mesmo quando o texto SQL está correto.

Defina se a conexão pertence à sessão ou à operação e como o driver trabalha com pooling. Pooling de conexões não significa compartilhar uma mesma instância de dataset entre usuários. Consulte a documentação do componente de dados e teste a estratégia escolhida.

Mantenha as transações limitadas à operação de negócio. Esperar a próxima interação do navegador com uma transação aberta pode ampliar bloqueios e dificultar recuperação.

Um lock não resolve todos os problemas

Proteger uma variável com uma seção crítica pode evitar uma corrida dentro de um processo. Isso não torna um dado de usuário global adequado, nem sincroniza vários processos ou servidores automaticamente.

Para o conflito entre duas edições, considere uma versão do registro ou outra política definida na persistência. Se a versão mudou desde a leitura, a aplicação precisa informar o conflito, não sobrescrever silenciosamente. A implementação depende do banco e da regra de negócio.

Faça um ensaio reproduzível

Use duas sessões independentes em uma base de testes. Execute seleções e leituras alternadas. Depois tente acessar um identificador fora do escopo permitido e confirme a rejeição no servidor.

Em seguida, leia o mesmo registro nas duas sessões, grave uma mudança em A e tente gravar em B. Anote a resposta esperada para conflito antes de observar a implementação.

Registre contexto de operação suficiente para diagnóstico, sem senhas, tokens ou conteúdo pessoal. Um identificador de correlação pode ajudar a seguir uma requisição sem copiar toda a carga de dados.

Desafio e próxima leitura

Escolha um cache existente. Sua chave inclui todas as dimensões que influenciam o resultado, como organização, idioma ou permissões? Defina também validade e invalidação; dados bem isolados ainda podem ficar desatualizados.

Este roteiro não foi executado em UniGUI aqui. Continue em Organizando formulários UniGUI para reduzir o acoplamento dos eventos.

Plano de duas sessões sintéticas

  1. Prepare contextos A/B; identidade vem da sessão autorizada, não da UI.
  2. A seleciona A1 e B seleciona B1; trocar aba de A não muda B.
  3. Documente escopo da chave de cache e teste pedido de A pelo recurso de B.
  4. Diferencie autorização recusada de conflito de gravação; lock não corrige autorização.

Registro: sessão, usuário fictício, recurso, dono, esperado e observado. Projeto integrado e persistência adiados por decisão do responsável; nenhum banco alternativo criado. Desenho de escopo não recebe selo de integração.