Seguretat i autorització

Arrel decideix l'accés al servidor, a cada endpoint. El frontend amaga els botons que no pots fer servir, però això és comoditat: la protecció real és que l'API els refusa.

Capes d'una petició

Una petició a l'API d'un Resource passa, en aquest ordre, per:

1. El middleware de config('arrel.middleware') (per exemple, identificar el tenant).
2. La sessió de Sanctum (auth:sanctum).
3. La verificació del correu i el segon factor, si estan activats (vegeu Autenticació).
4. El middleware de config('arrel.authenticated_middleware').
5. L'autorització del Resource, de la pàgina o de l'acció.

Resources

Els cinc mètodes canViewAny(), canView(), canCreate(), canEdit() i canDelete() deleguen a la Policy del model, o es poden sobreescriure (vegeu Resources).

Un Resource per al qual canViewAny() és fals queda tancat a tots els endpoints: el llistat, però també l'esquema, la creació, l'edició, l'esborrat, les accions, les opcions dels camps i les relacions responen 403. Sense aquesta regla, un model sense Policy deixaria canCreate() o canEdit() oberts de manera independent.

Això vol dir que, per a un model sense Policy, tot queda permès per a qualsevol usuari autenticat. Si el Resource ha de ser restringit, defineix una Policy o sobreescriu canViewAny().

Accions

• Una acció amb authorize() fa servir aquest closure, amb els mateixos arguments que handle().
• Una acció sense authorize() exigeix canEdit() sobre el registre, o canCreate() si és standalone(). Declara authorize() a les accions que han de quedar obertes a més usuaris.
• Les accions incloses segueixen la seva habilitat: ViewAction demana canView(), EditAction i RestoreAction demanen canEdit(), DeleteAction i ForceDeleteAction demanen canDelete().
• Les opcions que una acció ofereix als seus camps de relació només es serveixen als usuaris que poden executar-la.

Relacions

Si un camp Relation declara query(), l'abast també s'aplica en desar: un registre que l'abast amaga del desplegable és refusat amb un error de validació, encara que algú n'enviï l'identificador a mà. Passa igual als formularis d'un Resource, d'un Relation manager i d'una acció.

Relation::make('author_id')
    ->related(User::class)
    ->query(fn (Builder $query): Builder => $query->where('team_id', auth()->user()->team_id))

Al closure de query() d'un camp d'un Relation manager o d'una acció, el registre pare arriba com a tercer argument.

Pujades de fitxers

• Les pujades estan limitades a 60 per minut i usuari.
• En desar un registre, només es mouen els fitxers que realment s'han pujat al directori temporal (arrel-temp). Un valor que no correspon a una pujada real no es mou.
• El contingut dels camps RichEditor es sanititza al servidor en cada desat.

Límits d'intents

Què	Límit
Inici de sessió	5 intents fallits per correu i adreça IP
Segon factor d'un inici de sessió pendent	5 codis incorrectes, i caduca als 5 minuts
Enviament del correu de verificació	3 per minut
Confirmar o desactivar el segon factor	10 per minut
Pujades de fitxers	60 per minut i usuari

Pàgines

Page::canView() decideix si una pàgina és visible i accessible. Una pàgina que no es pot veure surt de la navegació i respon 403 a l'API. Per a una CustomPage, visible() controla l'entrada de navegació; l'autorització de les dades que la pàgina carrega l'has de fer als endpoints de la teva aplicació, que són codi teu.

Llista de comprovació

• Cada model exposat té una Policy, o el Resource sobreescriu els can...().
• Les accions que no han de ser només per a editors declaren authorize().
• Els camps Relation que mostren registres d'altri tenen query().
• sanctum.stateful conté només els dominis del teu panell.
• El segon factor és obligatori (isRequiredFor()) per als rols amb més privilegis.