Diseñar los permisos del plugin
La pieza que decide si tu plugin se puede usar con seguridad: cómo se declaran, cómo se agrupan, y el conjunto por omisión que casi todo el mundo pone mal.
Qué se declara
Cada comando produce dos permisos automáticos —permitirlo y denegarlo— y encima de eso se definen conjuntos:
# permissions/leer.toml[[permission]]identifier = "leer-proyectos"description = "Permite leer la lista de proyectos y su detalle."commands.allow = ["listar_proyectos", "detalle_proyecto"]Y la descripción importa más de lo que parece: es lo que quien use tu plugin va a leer para decidir si concederlo. Una descripción vaga produce concesiones a ciegas.
Cómo agrupar
Y la regla que sale: agrupa por lo que alguien querría conceder por separado, no por cómo está organizado tu código.
El conjunto por omisión
La decisión más consecuente, y merece cuidado: es lo que se concede cuando alguien añade tu plugin sin pensarlo.
Y el equilibrio entre 1 y 2 es lo difícil: un conjunto por omisión demasiado restrictivo empuja a la gente a conceder todo, y uno demasiado amplio concede de más a quien no miró. La respuesta razonable es lo que un uso típico y de solo lectura necesite.
Los ámbitos
Si tu plugin toca ficheros, red o procesos, necesita ámbitos — nivel 28 — y hay que diseñarlos:
- Qué se puede acotar: rutas, dominios, nombres de programa, identificadores.
- Qué forma tiene la declaración: lo que quien use el plugin va a escribir en su capability.
- Y el comportamiento por omisión: sin ámbito, nada. Un ámbito vacío que permite todo es el error del nivel 45.1, y aquí lo estás imponiendo a otros.
Y merece ofrecer validadores útiles, no solo comodines: si un argumento es una ruta, que se pueda acotar como ruta.