OpenClaw Gateway Token: diagnosticare l'autore senza filtrarlo

Un token OpenClaw Gateway non è sano solo perché esiste in un file di configurazione o perché il pannello di controllo carica HTML. La prova utile è una catena: il Gateway è raggiungibile, la fonte di credenziali prevista è stata risolta, la stretta di mano WebSocket l'ha accettata, il dispositivo ha gli ambiti richiesti e il Gateway è diventato abbastanza pronto per eseguire l'operazione prevista. Questa distinzione risponde presto alla domanda comune sulla risoluzione dei problemi. Se vedi unauthorized , 1008 , AUTH TOKEN MISMATCH , AUTH SCOPE MISMATCH o pairing required , non iniziare disattivando auth o rotando ogni token. Classifica prima lo strato fallito. Una discrepanza del token condiviso, un dispositivo riconosciuto con scope insufficienti e un nuovo dispositivo non approvato sono diversi incidenti con riparazioni diverse. La soluzione predefinita più sicura è quella di lavorare dall'host Gateway, utilizzare openclaw dashboard per il bootstrap del browser, mantenere l'interfaccia utente di controllo su localhost, Tailscale Serve o un tunnel SSH, e conservare solo le prove senza segreti nei biglietti e nei rapporti di salute. Separare cinque strati che possono fallire in modo indipendente La documentazione attuale di OpenClaw descrive il Gateway come il server WebSocket per canali, nodi, sessioni e ganci. Il suo dashboard è una superficie di amministrazione: può esporre chat, configurazione e approvazioni di esecuzione. Il shell della pagina può arrivare tramite HTTP mentre la connessione WebSocket viene respinta. Ecco perché un browser che visualizza l'interfaccia utente Control non è ancora una sessione autenticata. Utilizzare cinque strati: Strato Interrogazione Prova sicura Cosa non dimostra Trasporti Il cliente può raggiungere l'host, il porto, il tunnel e l'endpoint TLS? classe di destinazione, risultato di connessione, timestamp che l'auth è stato tentato Fonte di credenziali Il token, la password, SecretRef o la modalità di identità si sono risolti? modalità auth, tipo sorgente, presente/assenza che i valori client e server concordano Stretta di mano Il Gateway ha accettato il percorso di auth presentato? risultato normalizzato come ok , token missing o token mismatch che le dimensioni del dispositivo siano sufficienti Autorità del dispositivo Il dispositivo è accoppiato e approvato per gli ambiti richiesti? alias di identificazione del dispositivo, ambiti richiesti, stato di omologazione che i plug in e i canali sono pronti Preparazione Il cliente autenticato può eseguire l'operazione prevista? risultato di preparazione e ricevuta di operazione limitata che un compito di agente separato è stato completato Questo modello impedisce un falso verde familiare: /healthz risponde alla vitalità, mentre /readyz è più rigoroso. L'attuale documentazione di Gateway CLI dice che la prontezza rimane rossa mentre i sidecar del plugin di avvio, i canali o gli ganci configurati si stanno ancora sistemando. Nessun endpoint sostituisce una stretta di mano WebSocket autenticata. Anche l'inverso conta. Una stretta di mano successiva seguita da not ready non è un incidente simbolico. Ruotare il segreto condiviso in questo stato aggiunge la deriva senza riparare la componente di blocco. Raccogliere prove senza raccogliere il token Un utile record di incidenti non ha mai bisogno del valore del token condiviso. Inoltre non richiede un prefisso di token, impronte digitali reversibili, intestazione Authorization , cookie, screenshot di dashboard contenente un frammento o una copia di openclaw.json . Solo registrazione: Questo è sufficiente per indirizzare il caso. Dice che la fonte e' stata risolta e che il server e' vivo, ma un dispositivo riconosciuto non ha l'autorità richiesta. La prossima mossa corretta è l'approvazione del campo di applicazione o il ri accoppiamento non della rotazione del token condiviso. L'attuale contratto del cruscotto contiene diversi dettagli che vale la pena conservare: l'auth viene applicato nel stretto di mano di WebSocket; un token trasmesso al dashboard viene conservato in sessionStorage per la scheda di navigazione corrente e l'URL Gateway selezionato, quindi rimosso dall'URL; openclaw dashboard è il percorso di bootstrap locale raccomandato; un token runtime generato perché non è stato configurato alcun segreto condiviso è effimero e non può essere recuperato con openclaw config get gateway.auth.token ; un token gestito da SecretRef produce deliberatamente un URL del dashboard non tokenizzato; l'interfaccia interfaccia di controllo non deve essere esposta al pubblico. Queste sono regole di gestione, non un invito a incollare il token in un biglietto di supporto. Se la risoluzione dei problemi locale dell'ospite richiede veramente la visualizzazione o la risoluzione di una credenziale, mantenere tale passaggio interattivo e fuori dall'output catturato. Non mandarlo mai attraverso chat, uno screenshot, un registro informativo, un'osservazione di shell, o un'artigliatura di articolo. Quando un comando remoto CLI utilizza un url esplicito, la documentazione attuale di Gateway CLI dice che non ricade alle credenziali di configurazione o ambiente. L'autore deve fornire un'autore esplicita. Questo comportamento può spiegare un fallimento della credenziale mancante anche quando i comandi locali hanno successo. Non giustifica la messa di un token reale direttamente nella documentazione o in una cronologia di comando riutilizzabile. Classificare il guasto prima di scegliere una riparazione L'artefatto costruito per questo articolo accetta i campi privi di segreti sopra e respinge chiavi come token , password , Authorization , cookie , secret , o anche un hash token. Confronterlo con un fascicolo di prove: Per un'inadeguatezza di ambito, la produzione è deliberatamente ristretta: Il dispositivo di accompagnamento comprende otto casi: trasporto irraggiungibile, mancata credenziale, deriva dei token, disadeguamento di ambito, abbinamento richiesto, pronto, autenticato ma non pronto e vivo ma non autenticato. Diversi casi condividono httpLiveness: true . Essi producono ancora verdetti diversi perché la vita non è il confine decisionale. Utilizzare questa tavola di riparazione: Verdicto La prova più forte Riparazione limitata Verifica UNREACHABLE il collegamento alla destinazione prevista non funziona percorso di riparazione, tunnel, bind, TLS, listener o DNS Ripetere il controllo del trasporto prima dell'aut CREDENTIAL MISSING Auth mode richiede un segreto ma la fonte prevista è assente, o mancano rapporti di stretta di mano risolvere la sorgente configurata sul host Gateway nuovo risultato di stretta di mano; nessun segreto di uscita TOKEN DRIFT AUTH TOKEN MISMATCH dopo ogni nuovo tentativo di fiducia documentato identificare quale configurazione di sorgente e quale percorso di client differisce; ruotare solo con autorità stretta di mano autenticata utilizzando la fonte prevista SCOPE REPAIR REQUIRED AUTH SCOPE MISMATCH per un dispositivo riconosciuto approvare la definizione o il riparazione del campo di applicazione richiesto l'operazione richiesta riesce nel quadro di ambiti approvati WAITING FOR PAIRING il server richiede l'approvazione del dispositivo il proprietario autorizzato approva il dispositivo in sospeso la stretta di mano riesce con gli ambiti previsti AUTHENTICATED NOT READY La stretta di mano riesce , ma la preparazione rimane rossa . diagnosi dei componenti di preparazione preparazione più un'operazione prevista READY stretta di mano e passaggio di preparazione Nessuna riparazione conservare il ricevimento con timestamp UNCERTAIN mancano prove o sono contraddittorie raccogliere il prossimo strato mancante riclassificare; non indovinare sano AUTH TOKEN MISMATCH merita cura. L'attuale guida della dashboard dice che un client può eseguire un nuovo tentativo con un token di dispositivo memorizzato quando il Gateway fornisce suggerimenti di nuovo tentativo. Se il nuovo tentativo fallisce, ripara il token a deriva manualmente. Non costruire un ciclo di riconnessione illimitato, e non prendere un vecchio workaround gateway.remote.token da un problema storico come il contratto corrente. AUTH SCOPE MISMATCH è più specifico. La credenziale del dispositivo è stata riconosciuta, ma manca di ambiti richiesti. La rotazione del token condiviso non concede tali scopes. Riparazione o approvazione del nuovo campo di applicazione impostato attraverso un percorso autorizzato. pairing required è uno stato di attesa, non necessariamente un Gateway rotto. Il proprietario deve decidere se il dispositivo e l'autorità richiesta sono legittimi. Trattarlo come un'interruzione incoraggia l'autoprobazione non sicura. Rilancio della prova nell'operazione prevista Il recupero richiede un passo in più di una connessione verde. Dopo il trasporto, la stretta di mano, la portata e la preparazione passano, eseguire un'operazione limitata che rappresenta il fabbisogno effettivo del cliente. Per un osservatore può essere sufficiente uno status di sola lettura o una query di salute. Un cliente amministrativo ha bisogno di una propria ricevuta operativa autorizzata. Non espandere le autorizzazioni solo per far passare la prova. Una ricevuta di recupero compatta può contenere: La ricevuta omette il token e qualsiasi contenuto restituito dall'agente. Essa dimostra che lo strato previsto è stato recuperato senza trasformare il registro dell'incidente in un deposito di credenziali. Ci sono tre confini utili: 1. Non disabilitare l'auth per diagnosticare l'auth. Una connessione riuscita con none dimostra solo che il controllo dell'auth è stato superato. Cambierà anche il modello di minaccia di una superficie di amministrazione. 2. Non ruotare prima di identificare la deriva. La rotazione può invalidare i clienti sani e convertire un problema di risoluzione della sorgente locale in una deriva di token a livello di flotta. 3. Non richiedere il recupero automatico dell'approvazione di coppia o di ambito. Entrambe le autorità di sovvenzione. Essi richiedono una decisione del proprietario e un percorso di revisione. L'artefatto ha una limitazione deliberata: classifica le prove fornite ma non può recuperare, confrontare o convalidare una credenziale reale. Questa è una caratteristica. Il recupero segreto rimane sull'host Gateway con un operatore autorizzato. Il rapporto rimane sicuro da condividere. Il modello di salute pianificato di Sidewisp include disponibilità, accesso agli strumenti, perdita di permesso, stati di attesa e confini di recupero sicuro. Un futuro adattatore OpenClaw potrebbe raccogliere prove di connessione e di disponibilità senza segreti, ma deve distinguere la diagnosi dall'autorità e non deve caricare token, password, richieste o registri grezzi. Sidewisp è attualmente in anteprima privata. Il motore di monitoraggio della produzione, l'adattatore OpenClaw e l'esecutore di recupero non vengono generalmente spediti. Il sito pubblico e il sistema di articoli sono in diretta; unisciti alla preview se vuoi una prima visione sulla salute degli agenti che hai già operato. Fonti: OpenClaw Gateway CLI, OpenClaw Autenticazione della scheda di controllo, Configurazione di gateway OpenClaw e Statuto del prodotto Sidewisp.