Arkus Innovation Studios

Ship Log 003 · Login não é uma página

Uma semana no sistema de acesso da Arkus Suite: redirecionamentos, domínios, sessões, produção e os hábitos que fazem um sistema parecer real.

Nesta semana trabalhamos no sistema de login da Arkus Suite.

Essa frase parece menor do que o trabalho realmente foi.

A tela de login é a parte visível. O sistema real está atrás dela: qual domínio mantém a sessão do membro, qual produto recebe a transferência, quanto tempo o token vive, quais redirecionamentos são permitidos, onde o navegador chega e o que acontece quando a produção pensa de forma diferente da prévia.

A prévia é educada. A produção não é.

O desafio dos domínios

Um domínio de produto deveria encaminhar usuários ao portal central da Arkus. Mas o destino configurado e o domínio atual eram iguais. O middleware via uma URL de produto, tentava enviá-la à versão canônica e a devolvia para si mesma. Outra vez. E outra.

Assim, uma decisão de domínio aparentemente simples vira fluxo de controle.

A correção também foi simples: se o domínio atual e o canônico são iguais, não redirecionar. Prosseguir para a autenticação normal.

A lição é mais importante. Configuração de domínio não é texto; é comportamento da aplicação. Quando o sistema usa domínios para decidir acesso, identidade do produto e transferência de sessão, cada nome de host faz parte do caminho de autenticação.

O desafio da comprovação

Depois da correção, os testes públicos passaram. As páginas de produto redirecionaram uma vez para o login da Arkus. Sem ciclo, destino quebrado ou erro aparente.

Foi útil, mas não completo.

A comprovação real é o caminho autenticado: o membro entra no portal; o portal cria uma transferência de curta duração; o produto a valida; o navegador recebe a sessão; o código não pode ser reutilizado; e a pessoa chega ao produto sem entrar novamente.

Esse é o percurso real.

Um teste público prova que a porta não está mais emperrada. Não prova que a chave funciona.

Por isso registramos um procedimento de fumaça de produção com a sequência exata: emissão no portal, callback do produto, validação do token, criação do cookie, remoção do código, rejeição de repetição, verificação de permissão e chegada final.

É aqui que chamar algo de “concluído” cedo demais fica caro.

O desafio operacional

Houve um segundo desafio, mais evitável.

Adicionamos usuários ao sistema principal de acesso. A provisão funcionou e os níveis estavam corretos. Mas uma implantação intermediária saiu de um checkout local com mudanças não relacionadas, que afetaram brevemente a interface.

A operação de banco estava correta. O limite da implantação precisava ser mais limpo.

Esse problema não exige um novo framework, apenas uma regra: operações de dados não devem viajar com mudanças não relacionadas na aplicação. Se um auxiliar temporário for necessário, isole, remova e implante a partir de um alvo limpo. Melhor ainda, faça a operação sem tocar a superfície da aplicação.

O padrão maior

O restante da semana teve a mesma forma. O Index ficou mais rigoroso ao distinguir evidência recuperada, verificada, inferida ou ausente. O VentureIP avançou de superfície de lançamento para espaço operacional. O Cipher recebeu o caminho de transferência da Suite, ainda sujeito a validação real. O MarketRadar ficou menos preso a uma demonstração e passou a separar claramente o modo seguro de demonstração do modo com modelo ativo.

Repositórios diferentes, mesmo tema: não estávamos acrescentando IA por acrescentar. Estávamos acrescentando limites.

Qual domínio mantém a sessão. Qual produto aceita a transferência. Quais afirmações foram recuperadas. Qual modo é seguro para demonstração. Quais mudanças operacionais podem se aproximar de uma implantação.

Uma demonstração pode sobreviver à ambiguidade. Um sistema de produção não pode.

Até a próxima semana.

Sheldon