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. Constrict, 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 enstatusy 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) oAjouter à la liste(ese origen exacto se escribe enallowed_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.localy 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_dirysecrets_crypt_dir: dónde está abierto el directorio cifrado y dónde se guardan sus archivos cifrados. Con el segundo,statusdistingue un directorio cerrado de uno que nunca se creó.browser:family(chrome,chromiumobrave),profile_dir(el--user-data-dirdel perfil dedicado) ydebug_port(el--remote-debugging-port,9222por 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 enstatustal 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