Issue machine tokens with limited permissions and an expiry
A token acts as the person who made it, within the permissions it was given and those they still hold, checked on every request. Permission checks now go through one gate rule, since spatie's answered first and never asked the token. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
29
README.md
29
README.md
@@ -1348,6 +1348,31 @@ cliente en vez de comprobar nombres de rol.
|
||||
|
||||
Quien no tenga `pages.publish` solo ve páginas publicadas en el listado.
|
||||
|
||||
### Tokens para máquinas
|
||||
|
||||
```
|
||||
GET /api/v1/tokens mis tokens (all=1 para un super_admin)
|
||||
POST /api/v1/tokens {name, abilities, expires_at?} → el token, una vez
|
||||
DELETE /api/v1/tokens/{id} revocar
|
||||
```
|
||||
|
||||
Para scripts, CI o integraciones que no deberían usar la contraseña de nadie.
|
||||
Una persona lo crea con los permisos que le da (`pages.update`, o `pages.*`
|
||||
para todo lo de páginas) y nunca más de los que ella tiene; caduca a los 90
|
||||
días si no se dice otra cosa, y como mucho al año. Se guarda solo su hash, y el
|
||||
token en claro (`pmt_…`) sale una única vez, en la respuesta que lo crea.
|
||||
|
||||
Actúa como esa persona **dentro** de sus permisos, y se comprueba en cada
|
||||
petición, así que quitarle un rol recorta sus tokens al momento; desactivarla
|
||||
los apaga. El guard lo reconoce por el prefijo y **no lo manda nunca al
|
||||
servidor de identidad**. Un token no puede crear ni revocar tokens: si no, uno
|
||||
filtrado sería una forma de no caducar nunca.
|
||||
|
||||
Para que eso funcione, la comprobación de permisos es ahora una sola regla en
|
||||
`AuthServiceProvider` y la de spatie está apagada
|
||||
(`register_permission_check_method => false`): la de spatie respondía antes y
|
||||
concedía el permiso sin preguntar al token.
|
||||
|
||||
### Lotes e importación
|
||||
|
||||
```
|
||||
@@ -1555,7 +1580,9 @@ variables, porque quien lo lanza es quien inicia sesión:
|
||||
LANDING_URL raíz de la aplicación (por defecto http://localhost:8000)
|
||||
LANDING_USERNAME credenciales de Pireon para la API de administración;
|
||||
LANDING_PASSWORD el token se pide y se refresca solo
|
||||
LANDING_TOKEN o un bearer token fijo en vez de credenciales
|
||||
LANDING_TOKEN o un bearer token fijo en vez de credenciales —
|
||||
lo natural es un token de máquina (pmt_…) con
|
||||
solo los permisos que el MCP necesita
|
||||
LANDING_PREVIEW_TOKEN opcional: las herramientas públicas ven borradores
|
||||
LANDING_OPENAPI opcional: ruta o URL de la especificación
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user