OpenClaw Token de entrada: Diagnóstico de autor sin filtrarlo

Un token OpenClaw Gateway no es saludable simplemente porque existe en un archivo de configuración o porque el panel de control carga HTML. La prueba útil es una cadena: la puerta de entrada es accesible, la fuente de credenciales prevista se resuelve, el apretón de manos de WebSocket la acepta, el dispositivo tiene los escopes requeridos y la puerta de entrada se ha preparado lo suficiente para realizar la operación prevista. Esa distinción responde temprano a la pregunta común de resolución de problemas. Si ves unauthorized , 1008 , AUTH TOKEN MISMATCH , AUTH SCOPE MISMATCH , o pairing required , no empieces desactivando o girando cada token. Clasifique la capa fallida primero. Una incompatibilidad de tokens compartidos, un dispositivo reconocido con escopo insuficiente y un nuevo dispositivo no aprobado son diferentes incidentes con diferentes reparaciones. La opción predeterminada más segura es trabajar desde el host de Gateway, usar openclaw dashboard para arrancar el navegador, mantener la interfaz de usuario de control en localhost, Tailscale Serve o un túnel SSH, y conservar solo evidencia libre de secretos en boletos e informes de salud. Separar cinco capas que pueden fallar de forma independiente La documentación actual de OpenClaw describe al Gateway como el servidor WebSocket para canales, nodos, sesiones y ganchos. Su panel de control es una superficie de administración: puede exponer el chat, la configuración y las aprobaciones de ejecución. El caparazón de página puede llegar a través de HTTP mientras se rechaza la conexión WebSocket. Es por eso que un navegador que muestre la interfaz de usuario de control aún no es una sesión autenticada. Utilice cinco capas: Capa Pregunta de la Comisión Pruebas seguras Lo que no demuestra Transporte ¿Puede el cliente llegar al host, puerto, túnel y punto final TLS? clase de destino, resultado de conexión, timestamp que el autor fue intentado Fuente de credenciales ¿Se ha resuelto el token, contraseña, SecretRef o modo de identidad? modo auth, tipo de fuente, presente o ausente que los valores del cliente y del servidor coinciden Apoderarse de la mano ¿Acceptó la puerta el camino presentado? resultado normalizado como ok , token missing o token mismatch que el alcance del dispositivo sea suficiente Autoridad del dispositivo ¿Está el dispositivo emparejado y aprobado para los ámbitos solicitados? alias de identificación del dispositivo, alcance solicitado, estado de aprobación que los plugins y canales están listos Preparación ¿Puede el cliente autenticado realizar la operación prevista? Resultado de preparación y un recibo de operación limitada que se haya completado una tarea de agente separado Este modelo evita un falso verde familiar: /healthz responde a la vitalidad, mientras que /readyz es más estricto. La documentación actual de Gateway CLI dice que la preparación sigue siendo roja mientras los sidecars, canales o ganchos configurados del plugin de inicio aún se establecen. Ninguno de los puntos finales sustituye a un apretón de manos de WebSocket autenticado. Lo contrario también importa. Un apretón de manos exitoso seguido de not ready no es un incidente simbólico. Rotar el secreto compartido en ese estado añade la deriva sin reparar el componente bloqueador. Recoger evidencia sin recoger el token Un registro de incidentes útil nunca necesita el valor compartido del token. Tampoco necesita un prefijo de token, huella digital reversible, encabezado Authorization , cookie, captura de pantalla del tablero que contenga un fragmento o una copia de openclaw.json . Sólo para registros: Esto es suficiente para dirigir el caso. Dice que la fuente se resolvió y el servidor estaba en vivo, pero un dispositivo reconocido no llevaba la autoridad solicitada. El siguiente movimiento correcto es la aprobación del alcance o el reajuste de la rotación de tokens no compartidos. El actual contrato del tablero de instrumentos tiene varios detalles que vale la pena conservar: Auth se aplica en el apretón de manos de WebSocket; un token transmitido al panel de control se guarda en sessionStorage para la pestaña del navegador actual y la URL de Gateway seleccionada, luego se elimina de la URL; openclaw dashboard es la ruta de arranque local recomendada; un token de tiempo de ejecución generado porque no se configuró ningún secreto compartido es efímero y no se puede recuperar con openclaw config get gateway.auth.token ; un token administrado por SecretRef produce deliberadamente una URL del panel de control no tokenizado; la interfaz de control no debe ser expuesta públicamente. Esas son reglas de manejo, no una invitación para pegar el token en un boleto de apoyo. Si la resolución de problemas en el host local realmente requiere ver o resolver una credencial, mantenga ese paso interactivo y fuera de la salida capturada. Nunca lo envíes a través de chat, una captura de pantalla, registro de datos informativos, rastreo de proyectiles o fijación de artículos. Cuando un comando remoto CLI utiliza una url explícita, la documentación actual de Gateway CLI dice que no vuelve a las credenciales de configuración o entorno. El solicitante debe proporcionar un autor explícito. Ese comportamiento puede explicar un fracaso de credenciales faltantes incluso cuando los comandos locales tienen éxito. No justifica poner un token real directamente en la documentación o en un historial de comandos reutilizable. Clasificar el fallo antes de elegir una reparación El artefacto construido para este artículo acepta los campos libres de secretos anteriores y rechaza claves como token , password , Authorization , cookie , secret , o incluso un hash de token. Controlarlo contra un archivo de pruebas: En caso de desajuste de alcance, la salida es deliberadamente estrecha: El dispositivo de acompañamiento cubre ocho casos: transporte inaccesible, falta de credenciales, deriva de tokens, falta de coincidencia de alcance, emparejamiento requerido, listo, autenticado pero no listo y vivo pero no autenticado. Varios casos comparten httpLiveness: true . Todavía producen veredictos diferentes porque la vitalidad no es el límite de la decisión. Utilice esta tabla de reparación: El veredicto La evidencia más fuerte Reparación limitada Verificación UNREACHABLE fallas en la conexión con el destino previsto ruta de reparación, túnel, enlace, TLS, oyente o DNS Repetir el control de transporte antes de la CREDENTIAL MISSING El modo auth requiere un secreto pero la fuente prevista está ausente, o los informes de apretón de manos faltan Resolver la fuente configurada en el host Gateway Nuevo resultado de apretón de manos; no hay secreto en la salida TOKEN DRIFT AUTH TOKEN MISMATCH después de cualquier nuevo ensayo de confianza documentado Identificar cuál es la fuente configurada y cuál es la ruta del cliente que difieren; girar solo con autoridad apretón de manos autenticado utilizando la fuente prevista SCOPE REPAIR REQUIRED AUTH SCOPE MISMATCH para un dispositivo reconocido aprobar el conjunto o el reparto de alcance requerido la operación solicitada tiene éxito en los ámbitos aprobados WAITING FOR PAIRING el servidor solicita la aprobación del dispositivo el propietario autorizado aprueba el dispositivo pendiente el apretón de manos tiene éxito con los límites esperados AUTHENTICATED NOT READY el apretón de manos tiene éxito pero la preparación sigue siendo roja diagnóstico de los componentes de preparación preparación más una operación prevista READY apretón de manos y pase de preparación No hay reparación conservar el recibo con sello de tiempo UNCERTAIN falta de pruebas o contradicciones recoger la siguiente capa que falta reclasificar; no adivinar saludable AUTH TOKEN MISMATCH merece cuidado. La guía actual del tablero de control dice que un cliente puede realizar una nueva prueba con un token de dispositivo almacenado en caché cuando el Gateway suministra sugerencias de prueba de nuevo. Si el nuevo intento falla, reparar el token deriva manualmente. No construya un bucle de reconexión ilimitado, y no tome una vieja solución de gateway.remote.token de un problema histórico como el contrato actual. AUTH SCOPE MISMATCH es más específico. La credencial del dispositivo fue reconocida, pero carece de los ámbitos solicitados. La rotación del token compartido no otorga esos ámbitos. Repare o apruebe el nuevo alcance establecido a través de un camino autorizado. pairing required es un estado de espera, no necesariamente una puerta de entrada rota. El propietario deberá decidir si el dispositivo y la autoridad requerida son legítimos. Tratarlo como una interrupción fomenta una autoaprobación insegura. Recuperación de pruebas en la operación prevista La recuperación necesita un paso más que una conexión verde. Después del pase de transporte, apretón de manos, alcance y preparación, realice una operación limitada que represente las necesidades reales del cliente. Una consulta de estado o de salud de lectura única puede ser suficiente para un observador. Un cliente administrativo necesita su propio recibo de operación autorizado. No expanda los permisos sólo para hacer que la prueba pase. Un recibo de recuperación compacto puede contener: El recibo omite el token y cualquier contenido devuelto por el agente. Demuestra que la capa prevista se recuperó sin convertir el registro de incidentes en una tienda de credenciales. Hay tres límites útiles: 1. No deshable el auth para diagnosticar el auth. Una conexión exitosa bajo none sólo prueba que se ha omitido la verificación del auth. También cambia el modelo de amenaza de una superficie de administración. 2. No gire antes de identificar la deriva. La rotación puede invalidar a los clientes sanos y convertir un problema local de resolución de la fuente en una deriva de tokens de toda la flota. 3. No solicite la recuperación automática de la aprobación de parejas o de alcance. Ambos organismos otorgan subvenciones. Requieren una decisión del propietario y un rastro de auditoría. El artefacto tiene una limitación deliberada: clasifica la evidencia suministrada pero no puede recuperar, comparar o validar una credencial real. Eso es una característica. La extracción secreta permanece en el host Gateway con un operador autorizado. El informe sigue siendo seguro para compartir. El modelo de salud planeado de Sidewisp incluye disponibilidad, acceso a herramientas, pérdida de permisos, estados de espera y límites de recuperación seguros. Un futuro adaptador OpenClaw podría recopilar pruebas de conexión y preparación sin secretos, pero debe distinguir el diagnóstico de la autoridad y no debe subir fichas, contraseñas, instrucciones o registros en bruto. Sidewisp se encuentra actualmente en versión preliminar privada. El motor de monitoreo de producción, el adaptador OpenClaw y el ejecutor de recuperación generalmente no se envían. El sitio público y el sistema de artículos están en vivo. Únete a la vista previa si quieres una vista de la salud de la evidencia en torno a los agentes que ya operas. Fuentes: OpenClaw Puerta de entrada CLI, Autenticación del panel de control OpenClaw, Configuración de la puerta de entrada OpenClaw y Estado del producto Sidewisp.