Cuándo no vale la pena
Los cuatro casos en que el trabajo de esta fase rinde poco, la trampa de configurar permisos alrededor de un comando mal diseñado, y el orden correcto: primero los comandos, después los permisos.
Los cuatro casos
La trampa: la cerradura en la puerta que no cierra
El primer caso merece el desarrollo porque es el más común y el más caro.
// Un comando así, con la mejor configuración de permisos del mundo:#[tauri::command]async fn leer_fichero(ruta: String) -> Result<String, ErrorPayload> { … }// …y una capability impecable{ "identifier": "principal", "description": "Solo la ventana principal, solo en escritorio, solo este comando", "windows": ["main"], "platforms": ["macOS", "windows", "linux"], "permissions": ["core:default", "allow-leer-fichero"]}Todo el trabajo de la fase V está hecho, y la superficie es el disco entero. El permiso está acotado a una ventana, a tres plataformas y a un comando, y ese comando concede leer cualquier fichero que el usuario pueda leer.
La configuración no puede arreglar eso, porque el permiso acota quién invoca, no qué hace el comando. Es exactamente el límite del nivel 26.4, primera fila: tu propio código no está cubierto por nada.
Y el remedio no está en esta fase:
// La misma funcionalidad, con la superficie acotada por el DISEÑO#[tauri::command]async fn cargar_proyecto(app: AppHandle, id: ProyectoId) -> Result<Proyecto, ErrorPayload> { … }Ahora, aunque la capability fuera ancha, el frontend no puede pedir nada imprevisto: el core resuelve la ruta desde su propio directorio y desde un identificador que es un tipo propio.
El orden correcto
De ahí sale el orden que este track recomienda, y que contradice el instinto de configurar primero:
Los tres primeros son la mayor parte del beneficio y ninguno es de configuración. Un proyecto que hace los tres y deja la capability global tiene más acotada la superficie real que uno con permisos primorosos y comandos que aceptan rutas.
Dónde invertir con tiempo limitado
Si solo hay una tarde:
- Media hora: cerrar la política de contenido.
- Una hora: revisar la lista de comandos y renombrar o rediseñar los que sean mecanismos.
- Diez minutos: nombrar las ventanas en la capability global.
- El resto: cambiar los conjuntos por defecto de los plugins por permisos finos.
Esos cuatro dan más que cualquier reparto elaborado montado sobre comandos mal diseñados.