Duda rápida sobre permisos de Usuarios

Gente!

He seguido un poco la guía definitiva y otro poco el primer libro de Yii para ayudarme a hacer la autenticación de usuarios con la base de datos.

Ya logré que funcione todo perfectamente, pero ahora mi duda es: todos los usuarios se pueden loguear con sus respectivas cuentas, pero ¿quién es ahora el admin?¿cómo lo doy de alta para poder usar ‘admin’ como permiso en rules dentro de los controladores?

Muchas gracias!

Saludos…

Hola, esto te puede ayudar http://www.yiiframework.com/wiki/120/introduccion-al-control-de-acceso-basado-en-roles-rbac/

Lo leí pero no encontré la solución, además no creo que sea crear tantas tablas y colocar tanto código solo para poder diferenciar al admin de un usuario registrado.

Considero que si las reglas con ‘@’ (usuarios registrados) y ‘*’ (usuarios no registrados) funcionan correctamente y lanzan los errores 403 apropiadamente, poder distinguir a los ‘admin’ no debe ser tan complicado.

Espero que alguno de ustedes pueda ayudarme.

Sugerencias?

No es tan complicado como lo ves, sólo necesitas crear las tres tablas, y si lo único que necesitas diferenciar usuarios registrados de administradores basta con agregar un registro en la tabla authitem que será el del rol administrador. Luego cada vez que creas un usuario, le asignas ese rol si es que corresponde, esto lo haces con estas 2 líneas:


$auth=Yii::app()->authManager;

$auth->assign('administrador',$model->id_usuario); 

suponiendo que ‘administrador’ es el nombre que le diste al registro en la tabla authitem

y para controlar el acceso a las páginas basta con que verifiques si el usuario tiene asignado el rol de administrador en las acciones del controlador :


if (Yii::app()->user->checkAccess("administrador"))

{


}



Espero te sirva mi sugerencia…

Si no deseas implementar RBAC porque es demasiado para tu aplicación puedes definir un campo adicional del tipo smallint llamado "admin" en la tabla de usuarios. Además lo configuras para que no pueda ser null y que por defecto tome el valor 0. Luego agregas un método como el siguiente a tu modelo Usuarios:




public function esAdmin() {

    	if ($this->admin)

        	return true;

    	return false;

	}



Luego las accessRules del controlador quedarían así:




public function accessRules()

	{

      	

		return array(

                	(...)

                	array('allow', // para poder ingresar a las acciones listadas abajo el usuario debe estar logueado y ser admin

                      	'actions' => array('create', 'update', 'admin', 'delete'),

                      	'expression' => '!Yii::app()->user->isGuest && Usuario::model()->findByPk(Yii::app()->user->id)->esAdmin()',

                	),

         			(...)

            	);

	}



Para dar permisos de administración bastaría agregar un input del tipo checkbox para el atributo "admin" en el formulario de usuario. Si el checkbox se marca, el atributo toma el valor 1, por lo que en tal caso el método esAdmin() retornará true.

Muchas gracias por tu respuesta!

Hay alguna desventaja con respecto a RBAC? Es esto completamente seguro?

Las desventajas es que no es tan "atómico" o granular como el RBAC.

Para aclarar, a grandes rasgos RBAC trabaja con "items de autorización", los cuales los divide en 3 grupos: operaciones, tareas y roles. Las operaciones son las más básicas de un sistema, como crear, eliminar, modificar y ver usuarios. Luego esas operaciones las puedes agrupar en tareas, como "administrar usuarios". Finalmente puedes tener un rol "administrador" que agrupe "administrar usuarios" y "administrar posts". La ventaja es que además a un usuario particular puedes asignarle el rol "administrador" y además una operación o tarea específica, que escape a las definidas dentro del rol "administrador". Eso te permite mayor flexibilidad dentro de tu control de acceso y autorización.

Sin embargo, en sistemas simples donde tienes un solo administrador que agrupa todas las tareas y operaciones de administración posibles no es necesario un modelo tan complejo y flexible. En esos casos yo aplico lo que te expliqué en el post anterior.

Ahora, del punto de vista de seguridad no tiene mayor problema, pues en primer lugar la expresión revisa si no es un usuario invitado, y posteriormente carga la instancia de usuario en base a la ID asignada por la aplicación a dicho usuario y no mediante la obtención de un parámetro vía POST o GET, que pudiera haber sido manipulado por un usuario malintencionado.