Skip to content

Month: March 2015

Autentificación con MySQL Symfony 2 Parte 1

Después de luchar durante horas finalmente pude integrar el bundle de seguridad de Symfony para realizar el proceso de autentificación de usuarios, documenté todo para poder consultarlo si llegara a olvidar algo y también puede que sea útil para otros.

Primero montamos nuestro proyecto Symfony y además generamos un bundle, para este escenario creé un bundle llamado “LoginBundle”.

Damos de alta un catálogo de nombre “user” en la base de datos MySQL con los campos: id, username, password y isActive. Este almacenará todos los usuarios que serán autentificados desde el sistema.

SQL del catálogo user:

Ya que hayamos dado de alta el catálogo, procedemos a generar el XML donde se mapea la información de la tabla y después ese archivo lo utilizaremos para generar la entidad User en Symfony.

Generamos el XML de mapeo con el siguiente comando de Doctrine:

Le estamos diciendo que genere la entidad User del bundle LoginBundle, internamente Doctrine (ORM usado por Symfony) busca la tabla user en la base de datos y crea el XML con la información necesaria para generar dicha entidad.

Ahora con el siguiente comando generamos la entidad User con el XML recién generado localizado en: LoginBundle/Resources/config/doctrine/User.orm.xml

Con esto se crea la entidad User en la carpeta Entity de nuestro bundle.

Por defecto vamos a tener la entidad User con los atributos: id, username, password, isactive junto con sus getters y setters, se puede ver en LoginBundle/Entity/User.php.

Para activar la autentificación de usuarios desde la base de datos en Symfony la entidad usuario debe implementar 3 interfaces: UserInterface, Serializable y AdvancedUserInterface, así que abrimos el archivo de la entidad y procedemos a editarlo pero antes una explicación sobre las interfaces.

Entre las tres mencionadas UserInterface es la más importante ya que cuenta con los métodos: getRoles(), getPassword(), getSalt(), getUsername(), eraseCredentials().

Los métodos getPassword y getUsername no es necesario implementarlos ya que se crearon en la entidad User con el comando que vimos anteriormente, con respecto a los métodos restantes habrá que implementarlos.

Aunado a esto la interfaz serializable tiene dos métodos, serialize y unserialize, se implementan para que la entidad User sea serilizada en la sesión.

Por último la interfaz AdvancedUserInterface tiene los siguientes métodos: isAccountNonExpired(), isAccountNonLocked(), isCredentialsNonExpired(), isEnabled().

En esta caso se utilizó esta interfaz para indicar cuales usuarios están inactivos o activos por medio del método isEnabled, que lo vamos a saber usando el atributo isactive de nuestra entidad User.

La entidad User quedaría de la siguiente forma:

Explicación de algunos métodos importantes:

El método getRoles() por el momento tenemos el código en duro, regresa un arreglo con la cadena ROLE_ADMIN, todos los usuarios van a tener ese rol asignado, lo mejor sería que esos roles también los obtuviera de un catálogo de la base de datos pero esto lo dejaré pendiente para otra entrada.

El método getSalt() regresa un valor nulo, este método es utilizado para codificar la contraseña un nivel más, lo que hace internamente es agregar el valor “salt” a la cadena del password, codificando estos dos elementos da como resultado que sea mucho más difícil  descifrar cual es la contraseña si alguien llegara a tener acceso a estas, en este escenario no añaderimos ningún “salt” por eso regresamos valor nulo, pero es recomendable hoy en día agregar el salt a la contraseña por cuestiones de seguridad.

Estos dos métodos son de la interfaz Serializable, el atributo id es el valor más importante que se serializa porque hay un método interno en Symfony llamado refreshUser() responsable de cargar el usuario en cada petición usando el id.

El método isEnabled() lo encontramos en la interfaz AdvancedUserInterface, este método es utilizado por Symfony para saber que usuarios están activos o inactivos, para ello sólo vamos a regresar el valor del atributo isactive, es un valor booleano que viene del catálogo user de nuestra base de datos.

Vamos a generar el controlador responsable de verificar el acceso del usuario sea correcto:

Lo siguiente es crear en LoginBundle/Resources/views la carpeta Security, y dentro la plantilla:  login.html.twig

El código de esa plantilla es:

Los campos de texto de la contraseña y el usuario deben de tener como nombre _username y _ password, esto es debido a que internamente Symfony agarra esos nombres por defecto al hacer la validación, se pueden cambiar si asi se requiere desde la configuración de seguridad, la ruta login_check que se llama dentro de la función path esta declarada en el archivo de configuración de las rutas que veremos enseguida.

El archivos de configuración de la rutas se encuentra en LoginBundle/Resources/config/routing.yml, definiremos las siguientes rutas:

El siguiente paso es habilitar en la configuración de seguridad la validación de la entidad User que esta vinculada a la tabla “user” de nuestra base de datos para restringir los accesos al sistema, vamos abrir el archivo app/config/security.yml, pero antes crea una copia de este archivo para su respaldo.

El contenido del archivo security.yml es:

Esta parte es la que me causó más quebraderos de cabeza, considero muy importante comprender cada una de estas partes para que todo funcione sin problemas, así que pasaré a explicar cada una de las secciones del archivo de configuración.

Sección Codificadores:

En esta sección definimos el codificador que se va a utilizar para que la contraseña de nuestro usuario sea cifrada, en la línea 2 se especifica la ruta (namespace) de la entidad User que será utilizada para este proceso, en la línea 3 asignamos el algoritmo de codificación, en este ejemplo es sha1 pero puedes utilizar otros si lo requieres, en la línea 4 es una bandera que indica si la contraseña también además de utilizar el algoritmo sha1 se utilizará la codificación base 64, lo deje en falso para este ejemplo y por último en la línea 5 es el número de iteraciones que será codificada la contraseña de usuario, sólo haremos el cifrado sha1 una sola vez, pero puedes indicar cualquier número de iteraciones para ofuscar más la contraseña.

Sección Jerarquía de Roles:

En la jerarquía de roles se pueden especificar qué otros roles entran o son válidos en determinado rol, es como una relación padre e hijo, estas restricciones de que partes del sitio son accedidas dependiendo del rol se declaran en la sección access_control que veremos más adelante.

En el ejemplo anterior vemos que el rol “ROLE_ADMIN” también tiene asignado el rol “ROLE_USER”, esto quiere decir que si hay ciertas rutas restrigidas donde sólo usuarios con el rol “ROLE_USER” pueden entrar, significa que también podran acceder los usuarios que tenga el rol “ROLE_ADMIN”.

Sección de Proveedores:

Le sección del proveedor (providers), declara el proveedor user_db, un proveedor de usuarios es la fuente de dónde se cargan los usuarios en el proceso de autentificación, estos pueden venir de un texto plano, xml, memoria, base de datos, etc. la fuente puede ser cualquiera, en este ejemplo la fuente es nuestra entidad vinculada al catálogo de nuestra base de datos. Dentro de la configuración en el atributo entity se especifica la entidad User que generamos anteriormente y la propiedad username es el criterio de búsqueda, esto quiere decir que Symfony buscará la entidad en la base de datos por su atributo username.

Seccion Firewall:

En el firewall el apartado login, tiene dos atributos pattern y security, en el pattern especificamos con una expresión regular que rutas serán descartadas en el proceso de autentificación, vemos que tiene el valor ^/admin/login$, así la ruta /admin/login será omitida del proceso de autentificación ya que el parámetro security tiene valor falso para que salte el  proceso de validación. (esta ruta es la que muestra el formulario de login).

Ahora iremos al apartado de secure_area donde pattern es otra expresión regular (^/admin) que dice que todas las rutas que empiecen con /admin estarán protegidas, no podrán ser accedidas hasta que el usuario se autentifique.

Vamos a la parte de form_login, donde check_path apunta a la ruta que definimos en el achivo de configuración y tiene como valor /admin/login_check, esta ruta dispara un proceso interno de Symfony responsable de la validación del usuario y ver si la autentificación se ha hecho corréctamente, aquí no es necesario implementar nada más que definir la ruta en el archivo de configuración de rutas que vimos anteriormente.

El login_path tiene como valor /admin/login, es la ruta que apunta a nuestro controlador que pinta la vista del formulario de login y verifica que el usuario se haya autentificado correctamente, es el controlador SecurityController que creamos anteriormente donde se ejecuta el método loginAction del controlador SecurityController.

El atributo default_target_path, es la ruta donde nos redireccionará la autentificación en caso de ser exitosa, en este ejemplo nos redirecciona a la ruta /admin, esta ruta llama al método loggedAction del controlador SecurityController.

Por último vamos al apartado de logout, el atributo path es la ruta que hace el proceso de salir de la sesión, esto también es interno de Symfony no se tiene que implementar nada más que definir la ruta en la configuración al igual que el parámetro check_path anterior.

Para finalizar el atributo target solo es la ruta a donde nos redirigirá Symfony cuando el usuario sale de la sesión.

Más info: http://symfony.com/doc/current/reference/configuration/security.html

Sección Control de Acceso:

En esta parte definimos la rutas y que roles tendrán acceso a esas rutas, el path es una expresión regular de la ruta y el atributo roles, qué roles tienen acceso a esta ruta.

Con esto finalizamos la primera parte de la autentificación, deberíamos tener la funcionalidad básica para que los usuarios puedan iniciar sesión.

En la siguiente entrada vamos a ver la parte de roles para que no estén en código duro y los tome de una catálogo de la base de datos.

Leave a Comment

Montar Proyecto Symfony con Git en servidor Centos

Vamos a dar de alta el proyecto Symfony con composer en nuestra carpeta /var/www/html de nuestro servidor, por defecto apache la coloca ahí pero pudiera darse el caso de tenerla en otra ubicación.

Para instalar composer ejecutamos las siguientes instrucciones:

Con esto deberiamos tener activo el comando composer, ahora creamos el proyecto symfony en la capeta www:

De esa manera empezará la instalación y pedirá algunas opciones de configuración, al finalizar deberías tener la carpeta proyecto_prueba con todos los archivos descargados.

Vamos a pasar nuestro proyecto como repositorio Git, para esto debemos tener Git instalado en el servidor, si no es así sólo ejecuta:

Una vez instalado vamos a inicializar nuestro repositorio desde la capeta del proyecto:

Antes de inicializar el repositorio vamos a renombrar un archivo que es .gitignore, y lo puedes ver en el listado de archivos de proyecto, el parámetro -a es para vel los archivos ocultos:

Ese archivo lo vamos a renombrar a .gitignore_copy, esto es porque cuando creamos el repositorio omite los archivos que vienen en el contenido de .gitignore y no queremos eso, lo que se pretende es hacer el repositorio del proyecto completo:

Ahora si, inicializamos nuestro repositorio, dentro del proyecto ejecutamos:

Luego añadimos todos los archivos al repositorio:

Hacemos el commit para mandar los archivos agregados y el mensaje con la descripción del commit con el parámetro -m.

Con esto tenemos el repositorio listo, pero hay un detalle, este repositorio no lo podemos clonar, para ellos necesitamos un repositorio conocido como “repositorio bare”, este es el que nos va a permitir hacer esto, y se crea a partir del repositorio que acabamos de inicialzar, entonces con el repositorio recien creado ejecutamos:

El repositorio proyecto_prueba.git lo creamos en la raiz del servidor, además es buena practica que el repositorio bare tenga la terminación “.git” para identificarlo más facilmente, si exploramos esta carpeta veremos archivos y carpetas como: branches, hooks, info, objects. Más adelante haremos uso de una de estas carpetas para poder identificar los cambios que se hagan en el repositorio.

Con esto finalizamos la creación del repositorio, podremos clonarlo desde cualquier equipo cliente en un entorno de desarrollo como Eclipse o NetBeans, internamente estos IDE´s ejecutan el comando:

Muchas veces cuando se trabajo en un ambiente web, se requiere que los cambios hechos en el repositorio también se vean reflejados en el servidor donde se encuentra el proyecto en la www, para ello hay que clonar el repositorio bare en la www e indicar en los hooks del repositorio bare que cuando haya cambios los replique al repositorio que se encuentra en la www.

Para ello debemos clonar el repositorio bare en nuestra carpeta www, pero antes vamos a borrar la carpeta original donde inicializamos nuestro primer repositorio del cual generamos el bare.

Los parámetros -rf son para que el borrado sea recursivo y la “f” para forzarlo.

Ahora si clonamos el repositorio en la www:

El siguiente paso es detectar los cambios que se hacen en el repositorio bare para mandarlos al nuevo repositorio que esta en la www, lo que se tiene que hacer es ir a la carpeta del repositorio proyecto_prueba.git y dentro hay una carpeta llamada hooks, en esa carpeta vamos a crear un archivo que se llamara post-update:

Si no tienes nano lo puedes instalar con la instrucción:

Escribe el siguiente contenido en el archivo post-update:

Una breve explicación del archivo, se declara una constante WEB_DIR con la ruta del proyecto en la www, GIT_DIR ahora hará referencia a esta carpeta, pushd nos coloca sobre el directorio del repositorio y se hace el pull para bajar los últimos cambios del repositorio bare, al finalizar quitamos de la pila el $WEB_DIR del pushd anterior.

Guardamos el archivo “control+x” si estás en windows y asignamos permisos de ejecución al archivo:

Con estos pasos se deberían reflejar los cambios cada vez que se hacen modificaciones en el repositorio bare, el script post-update se ejecutara actualizando los archivos en el repositorio que esta en la www, así las personas que tengan el repositorio clonado en cada una de sus máquinas cuando manden sus cambios al repositorio con push también el repositorio que se encuentra en la www será actualizado.

Leave a Comment