Cambios de comportamiento

Esta página recoge los cambios que pueden afectar a una aplicación que ya usa Arrel. Las notas de cada versión están en Releases.

1.0.0-rc.1

Estos cambios refuerzan la seguridad del panel. Si actualizas desde una versión anterior, revísalos uno a uno.

Un Resource que el usuario no puede listar queda cerrado

Antes, un modelo sin Policy dejaba canCreate(), canEdit() y canDelete() abiertos, y se podían alcanzar por separado. Ahora, si canViewAny() es falso, el Resource responde 403 en todos los endpoints.

Qué hacer: nada, si todos tus modelos tienen Policy con viewAny. Si un Resource no tenía Policy y querías que fuera accesible, sigue siéndolo. Si querías que no lo fuera, define una Policy.

Las acciones sin authorize() exigen permiso de edición

Una acción a medida que no declara authorize() ahora exige canEdit() sobre el registro, o canCreate() si es standalone(). Antes, cualquier usuario que viera el Resource podía ejecutarla.

Qué hacer: declara authorize() en las acciones que deben quedar abiertas a más usuarios que los que pueden editar.

Action::make('export')
    ->authorize(fn (): bool => auth()->user()->can('posts.export'))

Las opciones de las acciones solo se sirven a quien las puede ejecutar

Las opciones que una acción ofrece a sus campos de relación ahora solo se sirven a los usuarios que pueden ejecutar la acción.

El alcance de un campo Relation se aplica al guardar

Un campo Relation con query() ahora rechaza al guardar un registro que el alcance oculta, con un error de validación. Esto vale para los formularios de un Resource, de un Relation manager y de una acción.

Qué hacer: comprueba que ningún formulario envía identificadores que query() excluye, por ejemplo porque el valor viene de otra fuente.

Límites de intentos

• El inicio de sesión admite cinco intentos fallidos por correo y dirección. Hay una nueva clave de traducción, arrel::auth.throttle, con el mensaje.
• Un inicio de sesión que espera el segundo factor termina tras cinco códigos incorrectos.
• Las subidas de archivos están limitadas a 60 por minuto y usuario.

Firmas

Action::validationRules() y validationRules() del trait de schema aceptan el registro propietario como último argumento opcional. Si sobrescribes alguno de estos métodos, añádele el parámetro.

Correcciones que pueden cambiar un comportamiento

• canEdit() comprueba la habilidad update de la Policy, no edit.
• Un modelo que bloquea su propio borrado (con una RuntimeException en deleting) responde 422 en lugar de fallar.
• Al guardar un registro, solo se mueven los archivos que realmente se han subido al directorio temporal.