- Navios
- 26 de agosto de 2026 às 05:10 UTC
- Autor
- kamo
- Enviar
- 7c4c7bc
Abra KamoCRM em uma aba e outra organização em um segundo, refresque a primeira, e ela renderizado como o segundo. Feche a aba, refresque novamente, e ele voltou. Reportado como sessão dados a sangrar entre tabs, e foi isso que foi. O ID da sessão é per-tab em sessãoStorage, mas o layout root resolveu o inquilino do encaminhado *** COOKIE, e um cookie é por-ORIGINA. Cada organização sem um domínio da sua possui agora compartilha interna.<platform>, então todas as suas abas compartilham um pote de cookie, e /api/session/extend re-planta esse cookie da última página atualizada. A concha. escolhido foi o último escritor — branding, e o registro que carrega suas características. O cookie não pode ir: o EventSources do universo/ksem envia com Credenciais, não pode definir cabeçalhos e não tem outro portador. Então, o consumidor mudou. O inquilino agora vem de ?org=, a única coisa per-tab que uma solicitação de documento carrega — middleware coloca onde um layout pode ler já que os layouts do roteador de aplicativos não recebem nenhum searchParams; /validate nomes do org que ele apenas inseriu assim a primeira pintura já está certa; e OrgUrlSync a coloca de volta após as navegações do cliente, que soltar a consulta, então uma atualização de três páginas profundas ainda identifica o inquilino certo. É uma REFERÊNCIA, não uma credencial: seleciona a marca pública, o mesmo registro /org/público serve a qualquer um. Os dados e os direitos permanecem bloqueados pelo token per-tab nas chamadas do próprio cliente, então um O valor desenhado à mão obtém o logótipo de alguém e não tem acesso. O middleware define sempre o cabeçalho, vazio incluído, então um chamador não pode forjá-lo. Também aqui: os ativos do tema são servidos do ápice sendo navegado em vez do próprio org, que pode ainda não resolver, e o assistente de criação espera para o provisionamento terminar em vez de abrir o novo espaço de trabalho para um tema que não foi escrito.