Skip to content

Author: jahepi

Canvas Tetris

Let me share with you my latest addition to my gaming list projects, i have been playing a lot Puyo Puyo Tetris lately which is an awesome game for Nintendo Switch, i was thinking, hey!, i love this game so much, why not create a Tetris clone using HTML5 Canvas and ECMAScript 6 language?, so i started implementing the game a few days ago, i reused some classes from my previous game projects so the development was lighting fast.

The music played in the game is from a group known as PowerGlove, if you have not heard of them, go ahead and look for this incredible group and listen some of their recordings.  

I do not know if i could be committing some copyright infraction here, but i am planning to record my own Tetris metal theme song on my electric guitar soon but meanwhile i am using the PowerGlove version for now, i hope there would be no problems.

Regarding the mechanics of the game, each minute the speed of the game increments, you have to clear 10 lines to avoid the speed increase or if you clear 10 lines the speed reduces, therefore your mission is to clear as many lines as you can to prevent the game to end.

As usual, here is the link to the code repository:

And the link to the playable version (use arrow keys to move tetriminos):

1 Comment

Drip Drop Puzzle Game

I am proud to share Drip Drop Puzzle Game with you, for it is the first time that I created the graphics and sound by myself. It is also the second time that I implemented a web browser game with ECMAScript 6 and HTML5 Canvas.

Although development took about 3 weeks; I was satisfied the whole time and I had a awesome time creating this game for you all even though I had to work 3 times harder than normal. I even started thinking of ways to share this proud experience with you.

My particular objective was to publish my game at Newgrounds which it is a site for an indie developers to show their creations, all content must be done by yourself so this was a great opportunity to share my game and receive some feedback, i am not going to lie, i was scared, i like my own creations but when other people comes into play, there would be some mixed opinions about it, some bad, some good, so i was afraid i could not take the bits of the bad ones, in any case i did it, and i am glad of the decision, at end a received a regular score from the community which is a great start for someone who likes making games as a hobby.

The objective of the game is to extinguish the torch flames with the drips and drops of water from melting ice cube, game instructions are presented while advancing through levels.


  • Mouse


  • 10 Levels, from easy to hard.
  • Leaderboard, top 10 from best times.

Link to the game:

Source code:

Newgrounds link:

Any feedback would be appreciated.
Hope you enjoy it.


HTML5 game demo from scratch

It was a while since I posted my last entry because for 2 months, I was crafting a web game using the programming language Javascript and the HTML5 Canvas element. It was a incredible success and satisfyingly fun!

In this entry I will share with you the details of my latest creation – “Jahepi’s Dungeon”.

Before we begin, I want you to know that I created this 2d scroller game to test my programming skills with Javascript and the HTML5 Canvas element. I did not however design the graphics. With that being said, I would like to thank the gamedevmarket community at and the opengameart community at for providing me with the paid-for and the free graphics and assets that I used on Jahepi’s Dungeon.

Jahepi’s Dungeon Overview:

The Demo I created has a total of 3 levels that each has a set amount of gold coins you need to collect and a boss you need to defeat before passing the level. There are checkpoints in each level that will ease the frustration and agony you endure after falling into lavapits and getting slaughtered by each of the bosses. But do not be too scared! Our main character is a special kind of character that has unlimited lives. So even if you die a few hundred times, you are sure to beat the demo on the 501st try.

After you load the game, you will be familiar with the layout. As a gamer, I am sure you have seen this type of layout a thousand times. The controller is a simple Left, Right, Up, Down, A, B. It is located at the bottom left of the screen so you can play with  a mobile device. You can however use your keys on a keyboard if you are using a PC. Feel free to leave a comment if you have any ideas for a better layout on this sweet 2d scroller.

Demo –

Source Code –



Leave a Comment

Multiplayer Space Deathmatch for Android

This is a game i made for Android devices in 2016, it took about 3 months of development, i am really happy with the final result.

Thanks to Joseph Miraglia for writing such an amazing description.

Description of the game:

Play your Family and Friends, whenever and wherever, in a Local Multiplayer Space Shooter Deathmatch Arcade.

Jahepi presents Multiplayer Space Deathmatch; a 2016 Local Multiplayer Arcade offered free in the Google Play Store for Family and Friends to interact while battling each other in a free for all Space Deathmatch, on Smart Phones, Tablets, and even Computers. And just because it is free, does not mean you are limited from having an amazing time with your Family and Friends.

Strap on your Space Suit and get ready for intense, thrilling, and exciting Space Deathmatch Battles with your Family and Friends!

• Five Spaceships : Columbia, Challenger, Discovery, Atlantis, Endeavour, each with their own diversity.

• Four Battle Locations: Andromeda, Centaurus, Pegaso, Sculptor, each with different twists and turns for unique battles.

• Power Pick Ups: Bigger Missiles, Huge Lasers, Repair Kits, Shrink Rays, but avoid picking up the Slowness!

• Multiplayer Lan Support: One, Two, Three, and Four Players can play!

• English • Spanish

Ultimate LAN Support:
The Ultimate LAN Support allows up to four of any Mobile Devices and Computers to connect and pair with each other, through (A. a Router / B. a Device with Hotspot Tether), for Local Multiplayer Gaming. Ultimate Lan Support does not require an active Internet connection, but does require WiFi.


Play Store:


Leave a Comment

Dog Smash Pumpkins for Android

This is a game i made for Android devices in 2016, the mechanics of the game are really simple, you just have to  kill as many pumpkins as you can to get the most points.

Thanks to Joseph Miraglia for writing such an amazing description.

Description of the game:

The New World is here and for some strange trendy reason, Humans now prefer Pumpkins as Pets, instead of Dogs.

Dogs have been relegated and forgotten by their owners all over the World, and replaced with Pumpkins, but a Dog named Pancho is not satisfied with its owner having Pumpkins as Pets. Pancho the Dog is seeking revenge on all the Pumpkins of the World and knocking them out one by one.

Help Pancho the Dog finish its mission of saving Dogs from their Pet Owners prefering Pumpkins as Pets!

• Knock out the Pumpkins one by one by hopping on top of the them and then smashing the Pumpkins weak spot.

Pancho is not the only Dog risking its life to save humanity from Pumpkin Loving Pet Pumpkin Owners! Destroy more Pumpkins than all the other Dogs in the World, and prove to Panchos Owners that Pancho is the only Pet Worthy Pet ever!

You will not only reunite Pancho with its Owners, but you will go down in history as the best Dog to Smash Pumpkins on the WorldWide List of Dogs to Smash Pumpkin!

Be part of the top 10 worldwide list of dogs, help them to reestablish their life with humans to normal.

Play Store:


Leave a Comment

Nano MVC Framework PHP

Nano framework es un marco de trabajo muy pequeñito en PHP totalmente en español que utiliza el patrón MVC (Modelo, Vista, Controlador) para la separación de código por responsabilidades en los proyectos.

El marco de trabajo cuenta con:

  • Soporte de namespaces.
  • Integración con DBAL (Capa de Abstracción de Base de Datos) de Doctrine, soporte de los motores más populares como MySQL y Postgres.
  • Auto-completado total al integrarse con algún IDE como NetBeans o Eclipse.


./controlador: Contiene las clases controladoras.
./libreria: Contiene las clases de terceros.
./modelo: Clases de la capa de negocio, responsables de la recuperación y guardado de información en un medio persistente (Base de datos, XMLS, TXTS, etc.), envío de
correos, servicios web, etc.
./recursos: Contiene las carpetas CSS y JS para almacenar los archivos CSS y scripts
en Javascript.
./sistema: Clases necesarias para el funcionamiento del framework.
./vista: Almacena los archivos PHP que pintan las páginas (código html).


  • Apache
  • PHP 5.3+


El primer paso es habilitar el módulo mod_rewrite de Apache, hay muchas guías disponibles en Google.

Lo siguiente es editar el archivo config.php que se encuentra en la carpeta sistema:

La primera constante DIRECCION es la ruta de nuestro proyecto, la constante MOSTRAR_ERRORES es una bandera para activar o desactivar los errores en el proyecto y por último la variable $conexiones, arreglo asociativo con el listado de conexiones a la base de datos, bd1 es la llave con la que podremos recuperar la referencia de conexión desde código, y los datos de conexión mysql://root:1234@localhost/test, donde mysql es el motor a utilizar, root es el usuario, 1234 es el password, localhost el dominio o IP del servidor y test el nombre de la base de datos, se pueden agregar las conexiones que se deseen y hacer referencia desde código usando la llave que se asignó.


Los controladores se crean en la carpeta controlador, ejemplo de implementación:

Por defecto se crea una instancia del controlador Index y se llama a su método index si se entra a la dirección del proyecto sin indicar ningún parámetro, las siguientes direcciones imprimirían Hola Mundo!:

  • http://localhost/nano
  • http://localhost/nano/Index/index

No estamos limitados a crear los controladores en la carpeta controlador, también podemos crear subcarpetas dentro de esta y organizar nuestros controladores de una mejor manera, para ello también hay que indicar el namespace en el controlador ya que el nombre del namespace se traduce a la ruta de carpetas del proyecto, por ejemplo:

El controlador estará ubicado en la ruta controlador/modulo1, ve además como el namespace está declarado: namespace controlador\modulo1;

Para llamar al método index de este controlador llamamos la siguiente dirección desde nuestro navegador de preferencia:


Con el guión bajo separamos el namespace de la clase desde la dirección a invocar, por lo que el guión bajo no debería se utilizado como parte del nombre de las clases.

Nota: Recuerda que los controladores sólo tienen como responsabilidad manejar los eventos del sistema.


Las clases del modelo van en la carpeta de modelo, al igual que los controladores podemos organizar las clases en carpetas y sólo definir el namespace de acuerdo a la ruta de la carpeta donde se encuentra ubicada, es importante recalcar que en esta capa del modelo va la lógica principal de nuestra aplicación por lo que además de incluir los servicios de recuperación y guardado de datos a algún medio persistente, también podemos hacer uso de otros servicios como el envío de correo, la validación de datos, etc.

La clases definitivas en el modelo, quedan a nuestro criterio el cómo crearlas, tenemos la libertad de hacer nuestro modelado de clases, coloco ejemplo de implementación de una clase llamada Usuario que viene en la demostración:

El namespace de esta clase es modelo\com\jahepi, por lo que la clase se encuentra en la siguiente ruta de carpetas modelo/com/jahepi.

Otro punto importante es la siguiente instrucción:

Con la cual podemos hacer referencia a la conexión de la base de datos que definimos en el archivo config.php en el apartado de configuración.


Las vistas o los archivos que tienen los elementos visuales se deben guardar en la carpeta vista, desde nuestro controlador podemos cargar un vista de la siguiente forma:

Donde bienvenida.php es nuestro archivo vista que se encuentra ubicado en vistas/bienvenida.php:

Sólo el controlador tiene que regresar una instancia de tipo Respuesta donde tenga como salida el contenido de bienvenida.php.


Nano framework viene con una demostración de un login de acceso básico junto con un ABC o CRUD de usuarios.

Para descargar Nano Framework clic aqui.

Para ver demostración en línea clic aquí.


Leave a Comment

Active Record, Data Mapper, ORM, SQL Wrapper

Un ORM o Mapeo Relacional de Objetos es la capa responsable de analizar la información de las tablas de las bases de datos convirtiendo esos datos en objetos, así en un catálogo de usuarios cada registro de esa tabla se traduciría a instancias u objetos de tipo Usuario y los campos de la tabla serían los atributos de nuestra instancia (aunque no necesariamente un campo de una tabla se traduciría a un atributo de una instancia), el ORM se encarga además de hacer el proceso inverso ya sea cuando se guarda o actualiza la instancia, donde el objeto es persistido en la base de datos y para ello se necesita que sea analizado, generando las consultas necesarias para guardarlo en la tabla de la base de datos.

Un ORM puede ser implementado comúnmente utilizando el patrón Active Record o también el patrón Data Mapper.

Active Record

Definición de la wiki:

Active record es un enfoque para aceso de datos en una base de datos. Una tabla de la base de dados o vista (view) está envuelta en una clase. Por lo tanto, una instancia de un objeto está ligada a un único registro (tupla) en la tabla. Después de crear y grabar un objeto, un nuevo registro es adicionado a la tabla. Cualquier objeto cargado obtiene su información a partir de la base de datos. Cuando un objeto es actualizado, un registro correspondiente en la tabla también es actualizado. Una clase de envoltura implementa los métodos de acceso (setter e getter) o propiedades para cada columna en la tabla o vista

Un ejemplo de Active Record:

Cabe mencionar que cuando es implementado este patrón de diseño, la entidad del dominio es responsable de persistirse en la base de datos, esto conlleva que dicha entidad tenga además de tener reglas de la capa de dominio (Método esMayorDeEdad), también quede acoplada a la capa de persistencia (Métodos guardar y obtener), esto trae una gran desventaja, si queremos en un futuro cambiar la forma de persistencia, que ahora en lugar de guardarse en una base de datos se guarde en archivos de texto plano (lo sé, es una locura), habría que hacer una refactorización de código inmensa, pero para proyectos donde la capa de persistencia se tiene por sentado que no cambiará es una forma buena de abstraer el cómo se gestionan las entidades de nuestros sistemas.

La forma en que utilizaríamos la clase:

Data Mapper

Definición de la wiki:

Data Mapper es una capa de acceso a los datos que realiza una transferencia bidireccional de la información entre la persistencia (frecuentemente una base de datos relacional) y los datos que se encuentran en memoria (La capa del dominio). El objetivo de este patrón es mantener la capa del domino y de la persistencia independientes

Como vimos hace rato, Data Mapper ataca el punto débil de Active Record donde la capa de persistencia queda acoplada a la capa de dominio, su objetivo es mantener las dos capas independientes, es por ello que este patrón de diseño es ideal para sistemas donde las entidades del dominio son persistidas en diferentes medios, haciendo uso de este patrón no habría mayor problema si en un futuro se cambia la persistencia, que podría ser una base de datos a una fuente de información distinta.

Ejemplo de Implementación:

Como vemos, nuestra entidad del dominio usuario ya no tiene conocimiento de la capa de persistencia.

Ahora vamos a implementar la capa de abstracción responsable de guardar las entidades del dominio desde cualquier fuente de información:

Implementamos el Data Mapper en caso de que nuestra persistencia sea una base de datos:

O si en un futuro cambia el sistema para que la fuente de datos sean documentos XMLs:

Ahora nuestro sistema dependería de una abstracción, y el modo de persistir los datos puede ser cambiado de base de datos a documentos XML, o inclusive otras fuentes:

Como conclusión, el patrón DataMapper las entidades como es la de Usuario son independientes, estas no conocen como persistirse en la base de datos, el que tiene la responsabilidad de hacer esto es otra clase que llamamos manejador (mapeador), la gran ventaja de esto es que nuestros objetos del dominio quedan totalmente desacoplados, el manejador se encarga de guardar las instancias en una base de datos, en un archivo de texto, en memoria, etc. Al final no importa dónde, el manejador hace lo necesario para que esa entidad sea persistida.

SQL Wrapper

Un SQL Wrapper es un envoltorio para generar consultas de una forma orientada a objetos, utilizando los métodos del wrapper o envoltorio se construyen las consultas dinámicamente, un ejemplo de cómo implementarlo vale más que mil palabras:

La forma en que utilizaríamos la clase:


Eso es todo por hoy, saludos :)

Leave a Comment


Hace muchos años vimos el nacimiento de una plataforma que abrió un abanico de posibilidades en el mundo de Internet, la plataforma de desarrollo conocida como Flash, en un principio creada por Macromedia para más tarde ser adoptada por Adobe permitió realizar cosas que antes nunca habíamos visto en la web, sitios con animaciones espectaculares, juegos que jamás llegamos a imaginar que pudiera ser posible ejecutarlos desde un navegador, en fin; grandes cosas surgieron en ese periodo.
Tengo un gran cariño a esta tecnología porque fue uno de los catalizadores que hicieron que me interesara en la programación y en el desarrollo de aplicaciones, Actionscript lenguaje nativo de Flash fue uno de los primeros lenguajes que aprendí, programé muchas cosas utilizándolo, me atrevo a decir que ha sido el lenguaje que más he disfrutado ya que me permitió hacer cosas que no creí posibles en aquella época.

La popularidad de Flash ha ido disminuyendo con el tiempo, todo esto por el advenimiento de HTML5, además que el plugin de Flash no es soportado en ciertos dispositivos, ¿alguien mencionó Apple? , Steve Jobs rechazó el uso de esta tecnología; pero a pesar de todo lo negativo estos últimos años, Flash sigue, no tan fuerte como antes pero aún es una gran herramienta para el desarrollo de aplicaciones.

Este es el motivo de esta entrada en el blog, quería ver las virtudes que HTML5 ofrece para el desarrollo de aplicaciones, compararla con Flash y dar mis conclusiones. Así que me vi en la tarea de hacer un pequeño juego usando el elemento Canvas y Javascript; cabe mencionar que este es mi primer intento de hacer un juego con HTML5, los juegos que llegué a desarrollar siempre fueron en Flash así que hice esto para tener un panorama más claro de lo que es HTML5 y porque está desplazando a Flash.
Dejo el código completo, tiene algunos errores en la detección de colisiones, no pude identificarlo hasta el momento pero si alguien lo encuentra o tiene algún comentario sobre el fuente estoy ansioso por escuchar sus comentarios.


Las teclas con las fechas hacía abajo y arriba rotan el personaje y las flechas izquierda y derecha lo mueven sobre el eje X y Y, con la tecla A disparan, el objetivo es destruir las rocas que salen volando, no tiene niveles, ni jefes, sólo es un juego sencillo a modo de aprendizaje.

Enlace al juego:

No voy a decir la verdad absoluta, el siguiente comentario está basado en la corta experiencia que tuve implementando esta demo.
HTML5 es una tecnología que no ha alcanzado el nivel de madurez que tiene Flash, no hay duda que trae grandes cosas, pero al final se me ha hecho más difícil programar y depurar el código, además que Javascript le faltan algunos detalles para llegar a ser un lenguaje 100% orientado a objetos como lo es Java o ActionScript 3, me hubiera gustado manejar mi clases en paquetes o indicar el tipo de dato en las variables, extrañe el uso de movieclips, sprites y todas las bondades que tiene Flash para facilitar el desarrollo pero aun así considero que como todo en la vida nos adaptamos a los cambios, en un futuro no tengo la menor duda que HTML5 junto con Javascript marcarán la web como Flash lo hizo en su día.

Leave a Comment

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:

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