Segurança
Nenhum desenvolvedor precisa lembrar de filtrar uma consulta por organização. Um escopo global faz isso automaticamente, em todo modelo que precisa, então um id antigo ou adivinhado para os dados de outra empresa resolve em nada, não em um vazamento.
Cada uma fecha uma forma diferente de uma plataforma multi-tenant vazar, silenciosamente, até alguém ir procurar.
Um escopo global filtra toda consulta pela organização no momento em que um modelo é carregado, sem nada para um desenvolvedor lembrar e nenhuma consulta capaz de esquecer, incluindo as que estão por trás dos links de rota.
O acesso administrativo é verificado a cada requisição, não só no login, então suspender uma organização bloqueia sua equipe já no próximo clique. Seus produtos deixam de estar acessíveis publicamente no mesmo instante.
Anular um ingresso ou cancelar um pedido exige sua permissão específica reverificada no exato momento da ação, independente de qual permissão levou alguém até aquela tela.
Custo e margem nunca são escritos em uma resposta de loja ou de leitura de QR. Não é algo escondido atrás de uma flag que poderia ser mal configurada depois: o campo simplesmente não existe no que é retornado.
Cinco mecanismos, cada um fechando uma forma diferente de o isolamento quebrar no uso real.
Um escopo global adiciona o filtro de organização a toda consulta feita em um modelo que o carrega, aplicado no momento em que o modelo é carregado, sem filtro para lembrar e sem forma de uma única consulta escapar dele.
Os links de rota dependem desse mesmo escopo, então um link para o registro de outra organização resolve em um simples 404 antes mesmo de qualquer código de tratamento rodar, nunca em um erro de permissão que confirmaria que o registro existe.
O escopo sozinho protege leituras e exclusões, mas não uma escrita direta em um id estrangeiro, então um id que entra em uma tabela pivô ou em uma coluna de chave estrangeira é reresolvido primeiro pela consulta escopada do seu próprio destino.
Toda ação sensível roda de novo uma verificação de permissão ao vivo no banco de dados quando ela realmente acontece, não uma vez no carregamento da página, então uma permissão revogada no meio da sessão para de funcionar já no próximo clique, não no próximo login.
Excluir um produto, opção ou categoria de ingresso com vendas reais é recusado duas vezes: a camada de aplicação explica o motivo antes mesmo de tentar, e a própria chave estrangeira do banco de dados é declarada para bloquear essa mesma exclusão, então um caminho que pulasse a verificação ainda assim falharia.
A resposta que um leitor vê é uma lista escrita à mão com exatamente o que a equipe do portão precisa. Custo, preço líquido e margem nunca foram adicionados a ela, então não há nada para expor por acidente depois.
{
"returned_to_gate_staff": {
"ticket_code": "AB12CD34EF",
"status": "redeemed",
"product_name": "City Food Tour",
"buyer_name": "Jane Buyer",
"position": 2,
"quantity": 3
},
"never_included": [
"cost_amount",
"net_amount",
"margin"
]
}Uma auditoria encontrou oito modelos acessíveis ao adivinhar um id de outra organização: seis regendo regras de preço e disponibilidade, dois regendo atribuições de imposto. Nenhum carregava seu próprio filtro de organização; cada um herdava um de uma relação pai que uma busca direta por um id fornecido pelo cliente simplesmente ignorava. Cada um deles agora carrega seu próprio id de organização, fechando exatamente essa classe de falha de vez, e uma suíte de testes dedicada mantém isso fechado tentando exatamente esse mesmo palpite, em cada um dos oito, toda vez que a suíte roda.
Não. Todo modelo que precisa carrega um escopo global que filtra automaticamente pela organização, o que também protege os links de rota: um id antigo ou adivinhado para o registro de outra organização resolve em um 404, nunca em um erro de permissão que confirmaria que o registro existe.
Sua equipe administrativa perde acesso ao painel já na próxima requisição, não só no próximo login, e seus produtos deixam de estar acessíveis pela API pública no mesmo instante. A suspensão é aplicada, não apenas registrada.
Sim. Toda ação sensível reverifica a permissão ao vivo no banco de dados no momento em que roda, não uma função guardada em cache quando a página carregou pela primeira vez. O próximo clique depois da revogação já é bloqueado.
Não, duas vezes. A camada de aplicação recusa a exclusão com uma explicação clara antes mesmo de tentar, e a própria chave estrangeira do banco de dados é declarada para restringir essa mesma exclusão, então até um caminho que pulasse a verificação da aplicação ainda assim falharia.
Não. Essas respostas são escritas à mão para incluir só o que o destinatário realmente precisa. O campo nunca é escrito na resposta: não é algo escondido atrás de uma flag que poderia ser mal configurada.
A Tiqory mantém disponibilidade, preços, pagamentos e acesso a trabalhar juntos enquanto a sua operação cresce. Conte-nos para onde vai; mostramos como chegar lá sem recomeçar.