Este artículo ha sido consultado en 1,455 ocasiones.

othAuth es una solución de manejo de permisos en el framework CakePHP, está desarrollada por Othman ouahbi aka "CraZyLeGs", un chico que (me parece) vive y trabaja en la India.

En el manual de CakePHP se explica el Access Contro List (ACL) la Lista de Control de Acceso. Las ACL se forman de usuarios y grupos de usuarios con diferentes permisos, por ejemplo sólo los usuarios del grupo "admin" pueden ver y modificar la información general de Karamelo. ACL es muy potente y flexible y utiliza conceptos que se usan en los permisos de archivos de Linux.

othAuth implementa la ACL de CakePHP en algunas vistas del programa que se está desarrollando. othAuth se usa tanto en Centauro como en Karamelo. othAuth es muy sencillo de usar y  se conforma de un componente el cual se debe descargar en app/controllers/components/oth_auth.php y de un helper que se coloca en app/views/helpers/oth_auth.php.

Antes que nada debemos recordar que en el archivo app/config/core.php se pueden configurar algunas cosas de CakePHP. En este caso nos interesa la definición de la constante:

define('CAKE_ADMIN', 'admin');

está constante debe estar descomentada para que surga efecto, concretamente lo que esta constante hace es definir la ruta de las pantallas de administración. Generalnmente estas vistas son de acceso restringido y sólo los usuaros logeados (y que pertenecen al grupo correcto) pueden verlas.  Es decir si tenemos un URL como /admin/users/edit significa que tenemos un método admin_edit en el controlador app/controllers/users_controller.php y una vista en app/views/users/admin_edit.thtml.

Es decir, los métodos en el controlador que corresponden a la zona admin tienen el prefijo admin_ : admin_delete(), admin_add(), admin_listing(), etcétera. Estos métodos del controlador son de acceso restringido y othAuth nos ayuda a restringir el paso.

Para usar othAuth necesitamos cuatro tablas: users, groups, permissions, groups_permissions. En la documentación está el SQL para crearlas en MySQL pero nosotros estamos usando PostgreSQL con nuestro propio script. Además nosotros necesitamos algunas columnas extras en la tabla "users". Como sea el resultado es que tenemos las mismas columnas que necesita othAuth.

Las tablas se usan de manera muy simple, creamos la tabla "groups":

Luego agregamos uno o más grupos en la tabla "groups", en el caso de Centauro sólo tenemos dos grupos, "admin" y "users":

INSERT INTO groups ("name", "level", "perm_type", "redirect") VALUES ('admin',   100, 'allow', '/news/view');
INSERT INTO groups ("name", "level", "perm_type", "redirect") VALUES ('users',   200, 'allow', '/news/view');

El campo "redirect" indica donde se debe redireccionar al usuario después de logeado.

Ahora creamos la tabla "users":

El campo group_id indica a que grupos peretence el usuario, en nuestro caso sí³lo puede pertenecer al grupo "admin" (group_id=1) o a "users" (group_id=2). Como señalamos antes, esta tabla tiene más columnas que la que tiene la tabla "users" de la documentación de othAuth porque nosotros necesitamos informacií³n extra. Ahora agregamos un usuario a la tabla users:

-- passwd = "admin"
INSERT INTO users("username", "passwd", "name",
"email",
"group_id",
"active",
"website",
"cv",
"quote",
"name_blog",
"avatar")
VALUES ('webmaster',
'21232f297a57a5a743894a0e4a801fc3',
'John Smith',
'john@site.edu',
1,
1,
'http://www.chipotle-software.com',
'Psychology and art teacher, travel and long walks lover. A life fueled by the magic bean, "Coffee".',
'"Nonviolence is a weapon of the strong", Gandhi',
'The Lost Forest', -- name blog
'HappyShark.jpg' --avatar
);

El usuario "webmaster" pertenece al grupo "admin" y su password en md5 es "admin".

Bien ahora vamos a crear la tabla de permisos, "permissions":

CREATE TABLE permissions (
id serial PRIMARY KEY,
name character varying(50) DEFAULT ''::character varying NOT NULL,
created timestamp(0) with time zone DEFAULT now() NOT NULL,
modified timestamp(0) with time zone DEFAULT now() NOT NULL
);

Agregamos algunos permisos:

--Blog entries
INSERT INTO permissions (id, name) VALUES (13, 'admin/entries/add');
INSERT INTO permissions (id, name) VALUES (14, 'admin/entries/edit');
INSERT INTO permissions (id, name) VALUES (15, 'admin/entries/delete');
INSERT INTO permissions (id, name) VALUES (16, 'admin/entries/listing');
INSERT INTO permissions (id, name) VALUES (17, 'admin/entries/start');

Es decir el URL 'admin/entries/add' tiene el permiso 13, 'admin/entries/edit' el 14, 'admin/entries/delete' el 15, etcétera. Estos permisos existen pero no los posee ningíºn grupo (y por lo tanto ningíºn usuario).

Vincular los permisios con los grupos de usuarios es precisamente lo que hace la tabla "groups_permissions" que creamos así­:

CREATE TABLE groups_permissions (
group_id int REFERENCES groups(id) ON DELETE CASCADE,
permission_id int REFERENCES permissions(id) ON DELETE CASCADE,
PRIMARY KEY (group_id, permission_id)
);

Ahora le damos permisos al grupo 1 (admin) a los URL del 13 al 17:

INSERT INTO groups_permissions (group_id, permission_id) VALUES (1, 13);
INSERT INTO groups_permissions (group_id, permission_id) VALUES (1, 14);
INSERT INTO groups_permissions (group_id, permission_id) VALUES (1, 15);
INSERT INTO groups_permissions (group_id, permission_id) VALUES (1, 16);
INSERT INTO groups_permissions (group_id, permission_id) VALUES (1, 17);

Esto quiere decir que el usuario "webmaster" ahora tiene permisos CRUD (create, read, update and delete) para los métodos admin_add, admin_edit y admin_delete del controlador app/controllers/entries_controller.php. Tiene estos permisos porque pertenece al group_id que es igual a "1". (El URL 'admin/entries/start' es sólo el homepage de la zona admin y no es importante).

Para darle permisos a los usuarios del grupo "users" tendrí­amos que vincular el id del permiso con el id del grupo "users":

INSERT INTO groups_permissions (group_id, permission_id) VALUES (2, 13);
INSERT INTO groups_permissions (group_id, permission_id) VALUES (2, 14);
INSERT INTO groups_permissions (group_id, permission_id) VALUES (2, 15);
INSERT INTO groups_permissions (group_id, permission_id) VALUES (2, 16);
INSERT INTO groups_permissions (group_id, permission_id) VALUES (2, 17);

Sencillo ¿no?, Necesitamos el archivo app/models/group.php para la tabla "groups":

class Group extends AppModel
{
var $name = 'Group';
var $hasMany = 'User';
var $hasAndBelongsToMany = array('Permission' =>
array('className' => 'Permission',
'joinTable' => 'groups_permissions')
);
}
?>

En el archivo app/app_controller.php necesitamos agregar el array público $othAuthRestrictions:

public $othAuthRestrictions = array('admin_add','admin_edit','admin_delete', 'admin_listing', 'admin_start');

Este arregalo le indica a othAuth cuáles métodos en los controladores de nuestro programa deben ser revisados antes de presentarlos, esto  para checar que el usuario realmente tenga permisos.

Dentro del método beforeFilter() de app_controller.php debemos declarar el arreglo $auth_conf, este arreglo configura algunas opciones de ohAuth:

$auth_conf = array(
    'mode' => oth',
    'login_page' => '/users/login',
    'logout_page' => '/users/logout',
    'access_page' => '/news/view',
   'hashkey' => 'mYpERsOn78787ALhaSHkeY',
   'noaccess_page' => '/users/noaccess',
   'strict_gid_check' => true
);

$this->othAuth->controller = &$this; // controlleret
$this->othAuth->init($auth_conf);
$this->othAuth->check();

Al estar en beforeFilter() de app_controller.php, othAuth se ejecuta antes que el método para revisar la seguridad.  Además como se indica en a documnetación, el método unbindAll() se debe colocar en app/app_model.php para que othAth no tenga que lidiar con arreglos demasiado grandes.

Como indicamos en el array$auth_conf, la página donde los usuarios se logean es /users/login, es decir debemos tener un método login en el controlador users_conroller.php :

Este método revisa que el login y la contraseña que el usuario puso en el formulario de logeo  sean los correctos, si es así othAuth inicia una sesión y asigna los permisos definidos en la tabla groups_permissions al usuario que se acaba de logear.

Una vez que el usuario se ha logeado podemos recuperar su información con el componente oth_auth.php, por ejemplo en cualquier controlador podemos pintar la info del usuario:

echo "El id del usuario es "                 . $this->othAuth->user('id')                 . "BR";
echo "El username del usuario es "  . $this->othAuth->user('username')  . "BR";
echo "El grupo del usuario es "          . $this->othAuth->user('group_id')    . "BR";

En las vistas usamos el helper oth_auth.php

echo "Páginas de " . $othAuth->user('username') ;

En necesario indicar que se va a usar la BD para salvar las sesionee en el archivo app/config/core.php.

Ficha del autor:
aarkerio
manuel_ARRROBA_mononeurona.org
Manuel Montoya estudió neuropsicología en la facultad y en el Instituto de Biomédicas de la UNAM. Trabajó en Compaq de México como diseñador de software, tiene diez años de experiencia en Java, PHP y SQL. Le interesan muchas cosas y neciamente le da por escribir sobre todas ellas. Actualmente trabaja en Chipotle Software, desarrollando Karamelo, una herramienta de e-Learning. Jedit.org y WindowMaker son su editor y escritorio favoritos.

The most effective way to restrict democracy is to transfer decision making from the public arena to unaccountable institutions. Chomsky.
Ver todos los articulos de aarkerio

Última actualización: 2007-06-25 12:02:25-05

tonathiu está:
comiendo pastura
11 hours, 16 minutes ago

saidjose está:
Faltan 10 minutos para cerrar el chagarro, eh irme a comer
14 hours, 10 minutes ago

aarkerio está:
Trabajando, yo si trabajo ;-)
16 hours, 39 minutes ago

der_teufel está:
Que felicidad! :'-D
17 hours, 13 minutes ago

der_teufel está:
Solucionado problema del viernes en una WorkStation xw6000 :-D gracias al chntpw!
17 hours, 13 minutes ago

saidjose está:
Escuchando a Raven Crown/Winter wind
18 hours, 16 minutes ago

Que estuvimos haciendo >>

Consultoría y Soporte