OpenClaw Token de passerelle: diagnostiquer l'auteur sans le fuir

Un jeton OpenClaw Gateway n'est pas sain simplement parce qu'il existe dans un fichier de configuration ou parce que le tableau de bord HTML se charge. La preuve utile est une chaîne: la passerelle est accessible, la source de crédits prévue est résolue, la poignée de main de WebSocket l'a acceptée, l'appareil a les champs requis, et la passerelle est devenue suffisamment prête pour effectuer l'opération prévue. Cette distinction répond tôt à la question commune de résolution des problèmes. Si vous voyez unauthorized , 1008 , AUTH TOKEN MISMATCH , AUTH SCOPE MISMATCH ou pairing required , ne commencez pas par désactiver auth ou roter chaque jeton. Classifiez d'abord la couche ratée. Un déséquilibre de jeton partagé, un dispositif reconnu avec une portée insuffisante et un nouvel appareil non approuvé sont des incidents différents avec des réparations différentes. La méthode par défaut la plus sûre est de travailler depuis l'hôte Gateway, d'utiliser openclaw dashboard pour le démarrage du navigateur, de conserver l'interface utilisateur de contrôle sur localhost, Tailscale Serve ou un tunnel SSH, et de conserver uniquement des preuves sans secret dans les billets et les rapports de santé. Séparer cinq couches qui peuvent échouer indépendamment La documentation actuelle de OpenClaw décrit le Gateway comme le serveur WebSocket pour les canaux, les nœuds, les sessions et les crochets. Son tableau de bord est une surface d'administration: il peut exposer le chat, la configuration et les approbations d'exécution. La coque de page peut arriver via HTTP alors que la connexion WebSocket est rejetée. C'est pourquoi un navigateur affichant l'interface utilisateur du contrôle n'est pas encore une session authentifiée. Utilisez cinq couches: Couche La question est posée Des preuves sûres Ce qu'il ne prouve pas Transports Le client peut il atteindre l'hôte, le port, le tunnel et le terminal TLS ? classe de destination, résultat de connexion, timestamp que l'auth a été tenté Sources de crédits Le jeton, le mot de passe, SecretRef ou le mode d'identité ont ils résolu ? mode auth, type source, présent/absent que les valeurs client et serveur sont d'accord Une poignée de main La passerelle a t elle accepté le chemin présenté ? résultat normalisé tel que ok , token missing ou token mismatch que les champs d'application du dispositif sont suffisants Autorisation de l'appareil L'appareil est il associé et approuvé pour les champs d'application demandés? alias identifiant le dispositif, champs d'application demandés, état d'homologation que les plugins et les canaux sont prêts La préparation Le client authentifié peut il effectuer l'opération prévue? résultat de préparation et un reçu d'opération limité qu'une tâche d'agent séparé a été accomplie Ce modèle empêche un faux vert familier: /healthz répond à la vivacité, tandis que /readyz est plus strict. La documentation actuelle de Gateway CLI indique que la préparation reste rouge tandis que les sidecars, les canaux ou les crochets configurés du plugin de démarrage sont toujours en train de s'installer. Aucun des deux terminaux ne remplace une poignée de main WebSocket authentifiée. L'inverse compte aussi. Une poignée de main réussie suivie par not ready n'est pas un incident symbolique. La rotation du secret partagé dans cet état ajoute à la dérive sans réparer le composant bloquant. Ramasser des preuves sans le jeton Un enregistrement d'incident utile n'a jamais besoin de la valeur de jeton partagée. Il n'a pas non plus besoin d'un préfixe de jeton, d'une empreinte digitale réversible, d'une en tête Authorization , d'un cookie, d'une capture d'écran du tableau de bord contenant un fragment ou d'une copie de openclaw.json . Enregistrement uniquement: C'est suffisant pour parcourir l'affaire. Il dit que la source a été résolue et que le serveur était en ligne, mais un appareil reconnu ne portait pas l'autorité demandée. La prochaine étape correcte est l'approbation de la portée ou le re partage de la rotation du jeton non partagé. Le contrat de tableau de bord actuel contient plusieurs détails qui méritent d'être conservés: l'auth est appliqué lors de la poignée de main de WebSocket; un jeton transmis au tableau de bord est conservé dans sessionStorage pour l'onglet navigateur actuel et l'URL Gateway sélectionnée, puis retiré de l'URL; openclaw dashboard est le chemin de démarrage local recommandé; un jeton de temps d'exécution généré parce qu'aucun secret partagé n'a été configuré est éphémère et ne peut pas être récupéré avec openclaw config get gateway.auth.token ; un jeton géré par SecretRef produit délibérément une URL non tokenized du tableau de bord; l'interface utilisateur de contrôle ne doit pas être exposée au public. Ce sont des règles de gestion, pas une invitation à coller le jeton dans un ticket de soutien. Si le dépannage local de l'hôte nécessite réellement l'affichage ou la résolution d'une carte d'identité, gardez cette étape interactive et hors de la sortie capturée. Ne l'envoyez jamais à travers le chat, une capture d'écran, un journal de l'informatique, une trace de coquille ou un article fixe. Lorsqu'une commande distante CLI utilise une url explicite, la documentation actuelle de Gateway CLI indique qu'elle ne revient pas aux identifiants de configuration ou de l'environnement. L'appelant doit fournir une autorisation explicite. Ce comportement peut expliquer un échec de crédit manquant même lorsque les commandes locales réussissent. Il ne justifie pas de mettre un véritable jeton directement dans la documentation ou dans un historique de commandes réutilisable. Classifier la défaillance avant de choisir une réparation L'artefact construit pour cet article accepte les champs sans secret ci dessus et rejette des clés telles que token , password , Authorization , cookie , secret , ou même un hash de jeton. Faites le comparer à un dossier de preuves: Pour un déséquilibre de portée, la sortie est délibérément étroite: Le dispositif complémentaire couvre huit cas: transport inaccessible, manque de carte d'identité, dérive des jetons, déséquilibre de portée, pairing requis, prêt, authentifié mais pas prêt, et vivant mais pas authentifié. Plusieurs cas partagent httpLiveness: true . Ils produisent toujours des verdicts différents parce que la vie n'est pas la limite de décision. Utilisez ce tableau de réparation: Le verdict Les preuves les plus solides Réparation limitée Vérification UNREACHABLE la connexion à la destination prévue ne fonctionne pas route de réparation, tunnel, liaison, TLS, auditeur ou DNS répéter la vérification du transport avant l'auth CREDENTIAL MISSING Auth mode nécessite une source secrète mais la source prévue est absente, ou les rapports de poignée de main manquent résoudre la source configurée sur l'hôte Gateway nouveau résultat de serrage de main; aucun secret de sortie TOKEN DRIFT AUTH TOKEN MISMATCH après toute nouvelle tentative de confiance documentée identifier les sources configurées et le parcours client qui diffèrent; tourner uniquement avec autorisation Une poignée de main authentifiée à l'aide de la source prévue SCOPE REPAIR REQUIRED AUTH SCOPE MISMATCH pour un dispositif reconnu approuver la définition ou le repérage de portée requise l'opération demandée réussit dans les domaines approuvés WAITING FOR PAIRING le serveur demande l'approbation de l'appareil le propriétaire autorisé approuve le dispositif en attente la poignée de main réussit avec les champs attendus AUTHENTICATED NOT READY La poignée de main réussit mais la préparation reste rouge diagnostiquer les composants de préparation préparation plus une opération prévue READY la poignée de main et le passe de préparation aucune réparation auth conserver le reçu marqué à l'heure UNCERTAIN les preuves manquent ou sont contradictoires recueillir la couche suivante manquante ne pas deviner saine AUTH TOKEN MISMATCH mérite des soins. Les directives actuelles du tableau de bord indiquent qu'un client peut effectuer une nouvelle tentative de confiance avec un jeton de périphérique caché lorsque le Gateway fournit des indices de réessayer. Si la nouvelle tentative échoue, dérive manuellement le jeton de réparation. Ne construisez pas une boucle de reconnexion illimitée, et ne prenez pas une vieille solution gateway.remote.token d'un problème historique comme contrat en cours. AUTH SCOPE MISMATCH est plus précis. L'identité de l'appareil a été reconnue, mais il manque de champs de champs demandés. La rotation du jeton partagé n'accorde pas ces champs d'application. Réparer ou approuver le nouveau champ d'application fixé par un chemin autorisé. pairing required est un état d'attente, pas nécessairement une passerelle cassée. Le propriétaire doit décider si le dispositif et l'autorité requise sont légitimes. Le traiter comme une panne encourage l'autodétermination dangereuse. Récupération des preuves lors de l'opération prévue La récupération a besoin d'une étape de plus qu'une connexion verte. Après le transport, la poignée de main, la portée et la préparation, effectuez une opération limitée qui représente le besoin réel du client. Une requête d'état ou de santé en lecture seule peut suffire à un observateur. Un client administratif a besoin de son propre reçu d'exploitation autorisé. N'élargissez pas les autorisations simplement pour réussir le test. Un reçu de récupération compact peut contenir: Le reçu omet le jeton et tout contenu retourné par l'agent. Il prouve que la couche prévue a été récupérée sans transformer le journal d'incident en un magasin d'accréditations. Il y a trois limites utiles: 1. Ne pas désactiver auth pour diagnostiquer auth. Une connexion réussie sous none ne prouve que le contrôle auth a été contourné. Il modifie également le modèle de menace d'une surface d'administration. 2. Ne tournez pas avant d'identifier la dérive. La rotation peut invalider les clients en bonne santé et convertir un problème de résolution de source locale en dérive de jetons à l'échelle de la flotte. 3. Ne demandez pas de récupération automatique de l'approbation de l'accouplement ou de la portée. Les deux autorités de subvention. Ils exigent une décision du propriétaire et une piste d'audit. L'artefact a une limitation délibérée: il classifie les preuves fournies mais ne peut pas récupérer, comparer ou valider une véritable carte d'identité. C'est une caractéristique. La récupération secrète reste sur l'hôte Gateway avec un opérateur autorisé. Le rapport reste à partager. Le modèle de santé planifié de Sidewisp comprend la disponibilité, l'accès aux outils, la perte de permis, les états d'attente et les limites de récupération sûres. Un futur adaptateur OpenClaw pourrait recueillir des preuves de connexion et de préparation sans secrets, mais il doit distinguer le diagnostic de l'autorité et ne doit pas télécharger de jetons, de mots de passe, de requêtes ou de journaux bruts. Sidewisp est actuellement en préversion privée. Le moteur de surveillance de la production, l'adaptateur OpenClaw et l'exécuteur de récupération ne sont généralement pas expédiés. Le site public et le système d'articles sont en direct; rejoignez l'aperçu si vous voulez une vue de la santé des agents que vous opérez déjà. Les sources: OpenClaw Porte de connexion CLI, Autentification du tableau de bord OpenClaw, Configuration de la passerelle OpenClaw et Statut du produit Sidewisp.