Diwall MCP

Español
Descargar v0.0.1

El perfil del operador y la lista de sitios

Un archivo JSON, leído de nuevo en cada llamada: los sitios que el servidor puede leer y en los que puede actuar, aquellos en los que cada cambio le pregunta primero, el navegador y los topes. Nada de lo que contiene puede desactivar una confirmación.

Dónde está

~/.config/mcp-server-diwall-browser/profile.json, o bajo $XDG_CONFIG_HOME cuando está definida, o la ruta absoluta dada en MCP_DIWALL_BROWSER_PROFILE. El archivo lo escribe usted, en modo 600, en un directorio en modo 700; de lo contrario el servidor lo rechaza y su mensaje da el chmod que hay que ejecutar. No contiene ningún secreto. El servidor lo lee de nuevo en cada llamada: un cambio surte efecto sin reiniciar.

Se rechaza una clave ajena al esquema. Una clave que configurara las acciones bloqueadas, como payment o deletion, se rechaza con redlist_in_profile: solo el código decide qué espera su confirmación.

Las tres listas de sitios

"allowed_origins": ["https://account.example.invalid", "https://*.shop.example.invalid"],
"confirm_each_change": ["https://account.example.invalid"],
"local_model_origins": []
  • allowed_origins: los sitios que el servidor lee y en los que actúa, como máximo 200. Con strict, de cualquier otra página el modelo recibe el origen y nada más.
  • confirm_each_change: sitios en los que cada clic, cada relleno, cada elección en una lista, cada pulsación de Intro y cada diálogo aceptado piden su confirmación, y no solo los pagos, las eliminaciones y los cambios de secreto.
  • local_model_origins: orígenes exactos que usted quiere que trate un modelo que se ejecuta en esta máquina. El servidor los enumera en status y nada más, ya que no tiene manera de saber dónde se ejecuta un modelo.

Una entrada es un origen (esquema, host, puerto) o un comodín de subdominio. https://*.shop.example.invalid cubre todos los subdominios de shop.example.invalid, de un nivel de profundidad o más, con el mismo esquema y puerto, y no shop.example.invalid mismo, que necesita una entrada propia. Un comodín solo (*), sin esquema, en un lugar distinto de la primera etiqueta o delante de un nombre de un solo nivel (https://*.test) invalida el perfil. Un comodín amplía la lectura y la acción, nunca la escritura: una credencial se escribe solo en el origen exacto que nombra su archivo (Credenciales). El servidor no guarda ninguna lista de sufijos públicos; evitar un comodín delante de un nombre de dos niveles, como uno que termine en co.uk, le corresponde a usted.

La política de orígenes

La lista de sitios limita lo que el modelo lee y en lo que actúa, nunca adónde navega. La clave origin_policy dice lo que hace el servidor con un origen que la lista no contiene. Usted la elige en el perfil; el servidor la lee de nuevo en cada llamada, y ninguna herramienta del modelo la cambia.

  • strict (el valor por defecto, y lo que hace un perfil sin la clave): el origen se rechaza, y el modelo recibe el origen y nada más.
  • discovery: el servidor le pregunta en una ventana, una vez por origen: Refuser (la respuesta por defecto), Cette séance (se lee hasta que el servidor se detiene, no se escribe nada) o Ajouter à la liste (ese origen exacto se escribe en allowed_origins). Como máximo cinco ventanas por proceso del servidor; un rechazo, o la falta de respuesta en 90 segundos, no se vuelve a preguntar.
  • open: todo sitio público se lee y se actúa en él, y lo que lee el modelo va a su proveedor. Es la política más libre y la más arriesgada, y la elección es suya. localhost, los nombres que terminan en .local y las direcciones no enrutables en Internet siguen en la lista.

En las tres políticas, un pago, una eliminación y un cambio de secreto conservan su ventana de confirmación, y una credencial se escribe solo en el origen exacto que nombra su archivo. Para añadir un origen a mano, póngalo en allowed_origins. El detalle está en la sección 5 de la guía del operador.

El resto del archivo

  • secrets_dir y secrets_crypt_dir: dónde está abierto el directorio cifrado y dónde se guardan sus archivos cifrados. Con el segundo, status distingue un directorio cerrado de uno que nunca se creó.
  • browser: family (chrome, chromium o brave), profile_dir (el --user-data-dir del perfil dedicado) y debug_port (el --remote-debugging-port, 9222 por defecto).
  • limits: por defecto, al menos 250 ms entre dos acciones, 200 acciones y 50 páginas por proceso del servidor. Una acción cuenta cuando empieza, una vez conectado el servidor; reiniciar el cliente vuelve a poner los contadores a cero.
  • declarations: dos afirmaciones suyas, que el modelo del cliente se ejecuta en esta máquina y que el cliente nunca responde por sí mismo a una confirmación. El servidor no puede comprobarlas y las muestra en status tal como están escritas. Solo con la segunda puede pedir una confirmación a través del cliente, cuando no se puede mostrar ninguna ventana.

Un ejemplo completo, que el servidor acepta tal como está escrito, figura en la sección 5 de la guía del operador.

Lo que deja un cambio de las listas

Quien pueda escribir el archivo puede añadirle un sitio, y el servidor no puede impedirlo. Deja un rastro: cuando una de las tres listas, o origin_policy, difiere de lo que el servidor vio en la llamada anterior, o en su primera llamada de lo que guardó la última ejecución, se escribe una línea profile_changed en el diario del directorio cifrado y status lleva el cambio en server.notices:

"notices": ["profile_changed : allowed_origins +https://shop.example.invalid"]

Es una detección a posteriori: no añade ninguna confirmación, y quien tenga una shell bajo su cuenta puede editar también el diario. Tras una sesión en la que estuvo conectado un cliente con shell, lea el diario:

grep profile_changed \
  ~/Vaults/Main/mcp-server-diwall-browser/journal/operations.jsonl