Qué es un ámbito y quién lo comprueba
Un permiso dice qué operación; un ámbito dice sobre qué. Quién lo valida, en qué momento, y la distinción entre el ámbito estático de la capability y el que se puede cambiar en ejecución.
Qué es
{ "identifier": "fs:allow-read", "allow": [{ "path": "$APPDATA/proyectos/**" }], "deny": [{ "path": "$APPDATA/proyectos/**/.secreto/**" }]}Un permiso con ámbito es un objeto en vez de una cadena, y el ámbito es la lista de valores sobre los que ese permiso vale. La forma del ámbito la define el plugin: el de ficheros usa rutas, el de red usa URL, el de shell usa nombres de programa con sus argumentos.
De ahí la primera consecuencia práctica: no todos los permisos admiten ámbito. Cerrar una ventana no tiene «sobre qué». Buscar cómo acotarlo es el primer síntoma del nivel 27.1.
Quién lo comprueba
Y aquí está el detalle que cambia cómo se piensa en esto:
La consecuencia es importante y se olvida: la calidad de la comprobación de ámbito depende del plugin, no del framework. Un plugin que normalice mal las rutas deja pasar cosas que su ámbito parecía impedir — y eso es el nivel 30.5.
Y la segunda consecuencia: tus propios comandos no tienen ámbito. El manifiesto del nivel 29 les da permiso, no ámbito. Si tu comando recibe algo que hay que acotar, la comprobación la escribes tú — que es, otra vez, el argumento del nivel 14.4 para que no reciba nada que haya que acotar.
Estático y dinámico
Hay dos formas de que un valor entre en el ámbito:
El caso del ámbito dinámico es concreto y frecuente: el usuario elige un fichero con el diálogo del sistema y a partir de ahí la aplicación debe poder leerlo. Esa ruta no se puede saber al compilar.
// tras el diálogo, ampliar el ámbito para ESA rutause tauri_plugin_fs::FsExt;if let Some(ruta) = elegida { app.fs_scope().allow_file(&ruta)?;}Y las tres reglas que lo hacen seguro:
- Solo para lo que el usuario acaba de elegir, nunca para lo que el frontend pida. Si el frontend puede pedir que se amplíe el ámbito, el ámbito no acota nada.
- Lo más estrecho posible: el fichero, no su directorio; el directorio, no su padre.
- Y se pierde al cerrar, lo cual es correcto: el permiso de leer un fichero no debería sobrevivir a la sesión salvo que lo decidas.
Cuando un permiso no tiene ámbito
Dos situaciones distintas que conviene no confundir:
El permiso no admite ámbito. Cerrar una ventana, vibrar, leer la versión. La operación no actúa sobre nada externo. No hay nada que acotar y está bien así.
El permiso admite ámbito y no se lo pusiste. Aquí depende del plugin: algunos tienen un ámbito por defecto restrictivo —no puedes hacer nada hasta que lo declares— y otros, ninguno, lo que significa todo. Es la diferencia entre un valor por defecto seguro y uno peligroso, y hay que mirarlo plugin a plugin.
La comprobación práctica: concede el permiso sin ámbito y prueba con un valor extremo. Si funciona con una ruta fuera de tu aplicación, el valor por defecto de ese plugin es abierto y hay que escribir el ámbito.