Sudo y superadministradores

El kit tiene dos tipos de cuenta poderosa. Un administrador es un usuario con el rol de administrador: un hecho de la base de datos, otorgado desde el panel de administración, con todos los permisos adjuntos. Un superadministrador, sudo para abreviar, es un correo escrito en config/app.php: un hecho committeado, otorgado con un despliegue, que abre las partes del sistema pensadas para quienes operan el código y no el producto. Necesitas esta guía la primera vez que siembras una base de datos y cada vez que alguien entra o sale del equipo que es dueño del servidor.

La lista

// config/app.php
'sudo' => [
    '[email protected]',
],

'default_users' => [
    '[email protected]',
],

sudo es la lista de dueños. default_users es una segunda lista, sembrada de la misma forma, de cuentas comunes sin rol, útil en un servidor de pruebas. Los correos se comparan en minúsculas, así que no importa cómo los escribas.

Sudo contra el rol de administrador

Ser sudo no abre por sí solo el panel de administración: /admin está detrás del rol de administrador, y por eso el seeder le da ese rol a cada sudo. Lo que sudo agrega es la lista corta de abajo, verificada pantalla por pantalla contra el código.

Así que la diferencia es operativa: la DevZone, el registro de actividad completo y la protección contra eliminación. Todo lo que un administrador del producto hace en el día a día funciona con el rol solo, y esa es la cuenta que le das a quienes operan el producto. Las reglas de suplantación y bloqueo están detalladas en Protege las acciones sensibles; la DevZone en La DevZone; los roles en Roles y permisos.

Cómo se verifica sudo en el código

No hay columna, gate ni middleware. El modelo User tiene un atributo calculado sudo, definido en el trait App\Traits\UserBase:

protected function sudo(): Attribute
{
    return Attribute::get(function () {
        return in_array($this->email, array_map('strtolower', config('app.sudo')));
    })->shouldCache();
}

Así que donde tengas un usuario, $user->sudo es true o false, calculado una vez por instancia. Ese es todo el mecanismo, y es el que el propio kit usa:

// Un componente que sólo sudo puede abrir: App\Livewire\Admin\DevZone
public function mount()
{
    if (! auth()->user()->sudo) {
        abort(405);
    }
}

// Una policy: App\Policies\ActivityPolicy
public function viewAny(User $user)
{
    return $user->hasRole(config('app.admin_role')) && $user->sudo;
}

// Un elemento del menú lateral: resources/views/layouts/sidebars/admin.blade.php
['name' => 'Dev Zone', 'url' => '/admin/dev', 'show' => auth()->user()->sudo],

Usa el mismo atributo para cualquier cosa tuya que deba quedarse con los dueños. Verifícalo en mount() para una página completa, en una policy para un recurso y en show para un elemento del menú, de modo que el enlace desaparezca para los demás en lugar de llevar a un error.

Agrega o quita un sudo

Para agregar uno, agrega el correo al arreglo, committea, despliega y corre el seeder de administradores para que la cuenta exista y tenga el rol de administrador:

php artisan db:seed --class=AdminSeeder

El atributo sudo es verdadero desde el momento en que la configuración nueva está en producción, con seeder o sin él, porque lee el archivo. El seeder es lo que crea al usuario cuando no existe y lo que otorga el rol de administrador. Para una cuenta que ya existe sólo asigna el rol y deja la contraseña en paz.

Para quitar uno, borra el correo, despliega y luego quita el rol de administrador a mano desde /admin/users: el seeder agrega roles y nunca los quita. La cuenta conserva los roles que tenga, menos los poderes de sudo, desde la siguiente petición.

Qué hace el seeder

php artisan db:seed corre, en este orden, PermissionSeeder, RoleSeeder, AdminSeeder, UserSeeder y AddOnSeeder. Los dos primeros construyen los permisos y el rol de administrador, y sincronizan todos los permisos a ese rol en cada corrida; RoleSeeder también crea el default_role cuando hay uno configurado y un rol client. Después, por cada correo en sudo, AdminSeeder:

1. Pasa el correo a minúsculas y toma la parte antes de la @ como identificador.
2. Busca al usuario por correo, cuentas eliminadas incluidas, o lo crea con el identificador como nombre en mayúscula inicial, el correo marcado como verificado y el identificador al revés como contraseña. [email protected] recibe el nombre Admin y la contraseña nimda.
3. Si la cuenta todavía tiene esa contraseña sembrada, la marca para un cambio de contraseña forzado, de modo que el primer inicio de sesión va directo a la pantalla de cambio y la contraseña predecible nunca sobrevive una sesión.
4. Asigna el rol de administrador.

UserSeeder hace lo mismo con default_users, sin el rol y sin el cambio forzado. [email protected] inicia sesión, por lo tanto, con tset.

Ambos seeders usan un buscar-o-crear, así que volver a correrlos es seguro: una cuenta existente conserva su contraseña, sus roles y sus datos. Eso también significa que el seeder no puede reparar una contraseña olvidada; para eso usa el enlace de restablecer en la página de inicio de sesión.

Por qué una lista committeada y no una bandera en la base de datos

Una bandera en la tabla de usuarios sería una cosa más que un administrador con el permiso correcto podría activar desde /admin/users, sobre sí mismo o sobre cualquiera. La lista no: promover a alguien a sudo requiere un commit, una revisión y un despliegue, y la historia de quién fue sudo y cuándo está en Git. Una base de datos nueva, en un servidor nuevo o después de un desastre, siembra a los mismos dueños desde el mismo archivo sin que nadie teclee un correo. Y como config/ es de tu proyecto, la lista sobrevive cada merge de la base sin conflicto.

Mantén la lista corta. Un sudo puede reescribir .env y correr comandos de despliegue desde el navegador, lo que lo convierte en operador del servidor, no sólo del producto.