OpenClaw Gateway Token: Diagnóstico de Autoria sem vazamento

Um token OpenClaw Gateway não é saudável apenas porque existe em um arquivo de configuração ou porque o painel de controle carrega HTML. A prova útil é uma cadeia: o Gateway é acessível, a fonte de credenciais pretendida resolvida, o aperto de mão do WebSocket aceitou, o dispositivo tem os escopoes necessários, e o Gateway ficou pronto o suficiente para executar a operação pretendida. Essa distinção responde cedo à pergunta comum de solução de problemas. Se você ver unauthorized , 1008 , AUTH TOKEN MISMATCH , AUTH SCOPE MISMATCH , ou pairing required , não comece desativando auth ou rotando cada token. Classifica a camada falhada primeiro. Um desajuste de tokens compartilhados, um dispositivo reconhecido com escopo insuficiente e um novo dispositivo não aprovado são incidentes diferentes com reparações diferentes. O padrão mais seguro é trabalhar a partir do host Gateway, usar openclaw dashboard para bootstrap do navegador, manter a interface de controle no localhost, Tailscale Serve ou um túnel SSH, e preservar apenas evidências sem segredo em ingressos e relatórios de saúde. Separar cinco camadas que podem falhar de forma independente A documentação atual do OpenClaw descreve o Gateway como o servidor WebSocket para canais, nós, sessões e ganchos. Seu painel é uma superfície de administrador: ele pode expor bate papo, configuração e aprovações de execução. O shell da página pode chegar através do HTTP enquanto a conexão WebSocket é rejeitada. É por isso que um navegador que exibe a interface de controle ainda não é uma sessão autenticada. Usar cinco camadas: Capa Pergunta Evidências seguras O que não prova Transportes O cliente pode chegar ao host, porto, túnel e ponto final do TLS? classe de destino, resultado de conexão, timestamp que o auth foi tentado Fonte de credenciais O token, a senha, o SecretRef ou o modo de identidade resolvidos? modo auth, tipo de fonte, presente/ausente que os valores do cliente e do servidor concordam Apertar a mão O Gateway aceitou o caminho apresentado? Resultados normalizados, tais como ok , token missing ou token mismatch que os escopo do dispositivo sejam suficientes Autoridade do dispositivo O dispositivo está emparelhado e aprovado para os escopoes solicitados? alias de identificação do dispositivo, escopo solicitado, estado de aprovação que os plugins e canais estão prontos Preparação O cliente autenticado pode executar a operação prevista? Resultado de prontidão e um recibo de operação limitada que uma tarefa de agente separado foi concluída Este modelo impede um falso verde familiar: /healthz responde à vivacidade, enquanto /readyz é mais rigoroso. A documentação atual do Gateway CLI diz que a prontidão permanece vermelha enquanto os sidecars do plugin de inicialização, canais ou ganchos configurados ainda estão se estabelecendo. Nenhum dos pontos terminais substitui um aperto de mão WebSocket autenticado. O contrário também importa. Um aperto de mão bem sucedido seguido por not ready não é um incidente simbólico. A rotação do segredo compartilhado nesse estado adiciona a deriva sem reparar o componente bloqueador. Coletar provas sem coletar o token Um registro útil de incidentes nunca precisa do valor do token compartilhado. Também não precisa de um prefixo de token, impressão digital reversível, cabeçalho Authorization , cookie, captura de tela do painel que contenha um fragmento ou uma cópia do openclaw.json . Só registos: Isto é suficiente para encaminhar o caso. Diz que a fonte foi resolvida e o servidor estava vivo, mas um dispositivo reconhecido não tinha a autoridade solicitada. O próximo passo correto é a aprovação do escopo ou o re parelamento da rotação de tokens não compartilhados. O actual contrato do painel tem vários detalhes que vale a pena preservar: Auth é aplicado no aperto de mão do WebSocket; Um token passado para o painel de instrumentos é mantido no sessionStorage para a guia do navegador atual e o URL Gateway selecionado, e depois retirado do URL; O openclaw dashboard é o caminho local recomendado de arranque; Um token de tempo de execução gerado porque nenhum segredo compartilhado foi configurado é efêmero e não pode ser recuperado com openclaw config get gateway.auth.token ; Um token gerenciado pelo SecretRef produz deliberadamente uma URL do painel de controle não tokenizada; A interface de controlo não deve ser exposta ao público. São regras de manipulação, não um convite para colar o token num bilhete de apoio. Se a solução de problemas local do host realmente exigir a visualização ou resolução de uma credencial, mantenha esse passo interativo e fora da saída capturada. Nunca o envie através do chat, de uma captura de tela, de um registo de dados, de um rastreamento de shell ou de um artigo. Quando um comando CLI remoto usa um url explícito, a documentação atual do Gateway CLI diz que não se relaciona com as credenciais de configuração ou ambiente. O telefonista deve fornecer autorização explícita. Esse comportamento pode explicar a falta de credenciais, mesmo quando os comandos locais têm sucesso. Não justifica a colocação de um token real diretamente na documentação ou num histórico de comandos reutilizável. Classificar a falha antes de escolher uma reparação O artefato construído para este artigo aceita os campos livres de segredos acima e rejeita chaves como token , password , Authorization , cookie , secret , ou mesmo um hash de token. Compare o com um arquivo de provas: Para um desajuste de âmbito, a saída é deliberadamente limitada: O equipamento de acompanhamento abrange oito casos: transporte inacessível, falta de credenciais, deriva de tokens, descoincidência de alcance, acoplamento necessário, pronto, autenticado, mas não pronto e vivo, mas não autenticado. Vários casos compartilham a httpLiveness: true . Eles ainda produzem veredictos diferentes porque a vida não é o limite de decisão. Use esta tabela de reparação: O veredicto Prova mais forte Reparação limitada Verificação UNREACHABLE Falha a ligação ao destino previsto rota de reparação, túnel, ligação, TLS, ouvinte ou DNS Repetir a verificação do transporte antes do CREDENTIAL MISSING O modo auth requer uma fonte secreta, mas a fonte pretendida está ausente, ou os relatórios de aperto de mão faltam. Resolver a fonte configurada no host Gateway Novo resultado de aperto de mão; sem segredo de saída TOKEN DRIFT AUTH TOKEN MISMATCH após qualquer nova tentativa de confiança documentada Identificar quais são as diferenças entre a fonte configurada e o caminho do cliente; girar apenas com autoridade aperto de mão autenticado utilizando a fonte prevista SCOPE REPAIR REQUIRED AUTH SCOPE MISMATCH para um dispositivo reconhecido aprovar o conjunto ou reparo de âmbito de aplicação exigido A operação solicitada é bem sucedida no âmbito dos domínios aprovados WAITING FOR PAIRING O servidor solicita a aprovação do dispositivo O proprietário autorizado aprova o dispositivo pendente aperto de mão é bem sucedido com os escopo esperado AUTHENTICATED NOT READY Apertar a mão é bem sucedido , mas a preparação continua vermelha . Diagnóstico dos componentes de prontidão Preparação mais uma operação prevista READY aperto de mão e passagem de preparação Não há reparação Preservar o recibo com marcação de tempo UNCERTAIN Falta ou contradiz a evidência. recolher a próxima camada faltante reclassificar; não adivinhar saudável O AUTH TOKEN MISMATCH merece cuidados. A orientação atual do painel de controle diz que um cliente pode realizar uma nova tentativa confiável com um token de dispositivo em cache quando o Gateway fornece sugestões de nova tentativa. Se a nova tentativa falhar, reparar o token deriva manualmente. Não construa um ciclo de reconexão ilimitado, e não tome uma solução antiga gateway.remote.token de um problema histórico como o contrato atual. O AUTH SCOPE MISMATCH é mais específico. A credencial do dispositivo foi reconhecida, mas não tem os escopo solicitados. A rotação do token compartilhado não concede esses escopo. Reparação ou aprovação do novo âmbito estabelecido através de um caminho autorizado. O pairing required é um estado de espera, não necessariamente um Gateway quebrado. O proprietário deve decidir se o dispositivo e a autoridade requerida são legítimos. Tratá lo como uma interrupção encoraja a auto aprovação insegura. Recuperação de provas na operação prevista A recuperação precisa de mais um passo do que uma ligação verde. Após o transporte, aperto de mão, alcance e prontidão passar, executar uma operação limitada que representa a necessidade real do cliente. Uma consulta de estado ou de saúde apenas para leitura pode ser suficiente para um observador. Um cliente administrativo precisa de seu próprio recibo de operação autorizado. Não expandir as permissões apenas para fazer passar o teste. Um recibo de recuperação compacto pode conter: O recibo omite o token e qualquer conteúdo devolvido pelo agente. Prova que a camada pretendida foi recuperada sem transformar o registro do incidente numa loja de credenciais. Há três limites úteis: 1. Não desativar o auth para diagnosticar o auth. Uma conexão bem sucedida sob o none só prova que a verificação do auth foi ignorada. Também muda o modelo de ameaça de uma superfície de administração. 2. Não rotear antes de identificar a deriva. Rotação pode invalidar clientes saudáveis e converter um problema local de resolução da fonte em uma deriva de tokens para toda a frota. 3. Não solicite a recuperação automática da homologação de acoplamento ou de âmbito. Ambas as autoridades de concessão. Requerem uma decisão do proprietário e um rastro de auditoria. O artefato tem uma limitação deliberada: classifica evidências fornecidas, mas não pode recuperar, comparar ou validar uma credencial real. Isso é uma característica. A recuperação secreta fica no host do Gateway com um operador autorizado. O relatório permanece seguro para compartilhar. O modelo de saúde planejado da Sidewisp inclui disponibilidade, acesso a ferramentas, perda de permissão, estados de espera e limites de recuperação segura. Um futuro adaptador OpenClaw poderia coletar evidências de conexão sem segredo e prontidão, mas deve distinguir o diagnóstico da autoridade e não deve carregar tokens, senhas, instruções ou registros brutos. A Sidewisp está atualmente em prévia privada. O motor de monitorização da produção, o adaptador OpenClaw e o executor de recuperação não são geralmente enviados. O site público e o sistema de artigos estão em directo; junte se à pré visualização se quiser uma visão de saúde em primeiro lugar sobre agentes que já operam. Fontes: OpenClaw Porta de entrada CLI, OpenClaw Autenticação do painel de comando, Configuração do gateway OpenClaw e Estatuto do produto Sidewisp.