Proyecto PWA HIRALITE

 La importancia de la Resiliencia 

Cuando terminé el grado en ingeniería multimedia, tenia claro que mi TFG quería enfocarlo en alguna solución orientada a la empresa en la que trabajo. Arcelormittal. Además ya que una de las últimas asignaturas optativas que cursé me introdujo en VueJS, un increíble Framework progresivo con un alto nivel de desacoplamiento lo que te permite como desarrollador crear interfaces, SPA o como en mi caso PWA, de una forma muy flexible y ágil. 

El primer intento 

Mi primera idea que además fue mi TFG, era crear una “red social” orientada al negocio de la empresa, es decir  una app que cubriera todas las necesidades de comunicación internas de forma vertical, desde la dirección a los empleados pasando por los mandos intermedios de forma cualquier evento o información importante se transmitiera de manera ágil y fácil. 

Me centré en tres tipos de aplicación:

- compartir imágenes en un muro en tiempo real 

- creación de chat en tiempo real 

- compartir documentos en tiempo real 

Con estar 3 premisas podría construir una “red social” orientada a la comunicación dentro de la empresa , por supuesto con sistema de autenticación y perfil de usuario. Así que empecé con cada una una de estas características haciendo clones de aplicaciones ya existentes con Vuejs. 

Primero clone instagram, luego clone WhatsApp. Cuando tenia dos PWA que funcionaban bien me dispuse a integrarlas en una sola App, con un backend no-sql montado en Firebase la app funcionaba muy bien aún en beta. 

Por aquellos días había superado ya el TFG con buena nota y me había graduado, por lo que tenia tiempo para dedicarme íntegramente al estudio y al desarrollo de mi app mientras lo compaginaba con el trabajo. 

Contexto

Acciones puntuales no programadas

Hojas HIRALITE

Cuando se realizan tareas de mantenimiento puntuales o programadas tenemos implementado un sistema de seguridad llamado HIRALITE, por sus siglas en inglés “Hazard Identfication and Risk Assesment”.

Básicamente, la idea es que el actor que va a realizar la tarea, debe identificar los riesgos asociados a la misma cumplimentando una hoja de análisis preliminar de riesgos. El formulario es un catálogo de posibles riesgos y el trabajador debe marcar las casillas de los eventuales riesgos que se prevén, así como las medidas de seguridad para mitigar dichos riesgos.

Órdenes de trabajo

Las hojas HIRALITE van siempre asociadas a las órdenes de trabajo. Aunque son cosas distintas están íntimamente relacionadas y ambas conforman la documentación de la que se debe disponer si se quiere realizar un trabajo en las líneas ya sea en turnos de parada o productivas. Las órdenes de trabajo son algo más complejas ya que involucran a más actores que intervienen en su composición. Éstos son:

• Jefe de turno / responsable de línea • Mantenimientos

• Contratistas

El proceso es el siguiente:

Cuando se quiere iniciar una tarea, el jefe de turno que es el responsable último en la línea. Rellena una orden de trabajo con sus datos, en esa hoja autoriza a los mantenimientos a iniciar las consignaciones de las máquinas y sistemas.

Cuando los mantenimientos han finalizado las consignaciones, de forma que las máquinas estén debidamente desenergizadas y posicionadas para permitir la entrada de trabajadores de forma segura, los mantenimientos firman esta hoja indicando que las consignaciones han finalizado.

En este momento el jefe de turno autoriza el inicio de los trabajos. Trabajos que deben ir acompañados siempre de una HIRALITE.

Los trabajadores, en el momento de acceder a la línea para empezar sus labores, guardan en unos cajetines metálicos la orden de trabajo y cierran el cajetín con un candado personal identificado (uno por trabajador) a dicho cajetín.

No se puede iniciar ninguna desconsignación o puesta en marcha de ningún sistema hasta que no se haya retirado hasta el último de esos candados por su dueño.

Una vez que los trabajos han terminado, cada trabajador retira su candado, se saca del cajetín la orden de trabajo. Para iniciar desconsignaciones y puesta en marcha de los sistemas el proceso es el mismo de inicio pero al contrario.

Problemática

En actuaciones puntuales, la creación de las órdenes de trabajo e HIRALITES generan una gran cantidad de papel impreso con el correspondiente consumo asociado tanto en papel como en tinta y energía. A demás todas esas órdenes terminan apiladas en cajas hasta que trascurrido el tiempo estimado que deben ser guardadas, deben ser destruidas y recicladas.

Por otra parte, a demás de los inconvenientes del uso de papel como soporte, estas órdenes impresas poseen una gran cantidad de datos que no estamos aprovechando; como ejemplo podríamos citar:

• Medias de tiempo reales de duración de trabajos y reparaciones basadas en datos

• Frecuencia de tipos de incidencias y averías

• Tiempos de reacción ante averías puntuales

Todas estas informaciones y más están presentes en el soporte de papel que acaba siendo reciclado. Mediante la digitalización de este proceso, podemos ir creando una base de datos de en la que guardar y consultar estos datos que pueden resultar muy beneficiosos al incrementar nuestro conocimiento de todos los aspectos de los diferentes tipos de reparación, su frecuencia, su tiempo de resolución, etc. Esto puede devenir incluso en una mejor organización en las actuaciones programadas ya que se dispone de más información a la hora de por ejemplo establecer la duración de una parada programada.

Por otra parte, centralizar el ciclo de vida de una orden de trabajo desde que se solicita hasta que se da por finalizada, agiliza de forma significativa el proceso ya que el responsable de la instalación tiene en la interfaz de su PC o Smartphone todos los trabajos activos, pudiendo ver en tiempo real cual es el estado de cada uno de los trabajos, firmando autorizaciones, etc. También el mismo solicitante de la orden ve agilizado el proceso de solicitudes y autorizaciones, ya que no necesitará ir buscando a los responsables de instalación o mantenimientos para las firmas, que es algo que inevitablemente ocurre sobre todo en instalaciones grandes como las nuestras.

Propuesta

La App HIRALITE, soluciona en gran medida la mayoría de las problemáticas anteriormente expuestas. La app agiliza estos procesos, recopila datos de los trabajos guardándolos en la base de datos, facilita la comunicación de los actores implicados, evita la impresión de documentos con el consiguiente ahorro.

Beneficios

Gracias a su desarrollo basado en programación progresiva y reactiva multiplataforma, se pueden realizar cambios en la app de forma muy ágil y dinámica, por lo que se convierte en una herramienta viva en constante proceso de adaptación a las eventuales nuevas necesidades.

• Ubicuidad y tiempo real: HIRALITE es una App con un procesado en tiempo real y trabaja con una base de datos también en tiempo real, esto le ofrece mucha flexibilidad y dinamismo. La creación de órdenes de trabajo, así como sus HIRALITE asociados, se crean en cuestión de minutos e inmediatamente, están disponibles de forma ubicua y muy visual, tanto para los supervisores de seguridad, como para los responsables de línea a los que les basta con una mirada a la aplicación obtener una fotografía del estado de los trabajos, así como de toda la información relativa a los mismos.

• Ecofriendly: Gracias a la digitalización del proceso, el único papel que será necesario imprimir será el de la pegatina con el código QR para el trabajador. Esto supone un gran ahorro tanto de papel como de tinta ya que, al cabo de pocas semanas, se acumulan un gran número de órdenes de trabajo e HiraLItes impresas, que al final terminan en reciclado. Si se tiene en cuenta este ahorro, no sólo para la empresa sino también para el medio ambiente, se puede decir si dudar que HIRALITE es una App ecofriendly.

• Persistencia de datos: Tanto las órdenes de trabajo como sus HIRALITE, se guardan en la base de datos, se puede establecer si se desea una fecha límite de persistencia, a partir de la cuál esos documentos serán eliminados de forma automática.

• Modularidad y escalabilidad: La app se basa en las últimas tecnologías PWA, Firebase, Vuejs, lo que nos ofrece la posibilidad de escalar la aplicación, o añadirle nuevos módulos.

• Multiplataforma y CrossBrowser: Gracias a su tecnología de última generación, no se requieren desarrollos distintos, para iOS, Android, Windows, etc. Un solo desarrollo basta para que la App funciones de forma nativa en absolutamente cualquier tipo de dispositivo con conexión y sin conexión, incluidos los SmartTV, independientemente del sistema operativo que presenten.

• Es por ello, que cualquier cambio o actualización se puede lanzar de una sola vez y en muy poco tiempo para todos los usuarios.

• Industria 4.0: El avance de la digitalización es un hecho, la industria y sus procesos deben adaptarse a ellos de forma eficaz, esta aplicación es una solución a una problemática concreta y puede suponer el inicio de un proceso de análisis y ejecución de soluciones a otros procesos que también sean susceptibles de ser digitalizados, además sería una aplicación creada por y para Arcelormittal Sagunto.

Contras

• La App en su versión actual, es una herramienta de campo, es decir los datos recopilados se guardan en una base de datos Firebase de Google en tiempo real pensada para el trabajo dinámico y no para la persistencia de datos. Por tanto, los datos deben ser descargados antes de que la orden sea eliminada si se quiere disponer de esos datos en una base de datos propia y persistente. Esto está contempla do desde el principio en el diseño de la app que en este momento es completamente funcional, pero ya estoy trabajando en el desarrollo de una interfaz para la descarga de datos a una base de datos propia, también estoy estudiando la posibilidad de que la interfaz pueda generar gráficas y medias con los datos descargados.

• Firebase de Google, es una plataforma en la nube para el desarrollo de aplicaciones móviles. Los servicios cloud de esta plataforma no son gratuitos, pero si muy generosos, su forma de facturar es por operaciones de lectura / escritura en sus servidores, por ejemplo, en la base de datos que usa HIRALITE se deberían superar 600.000 operaciones de lectura / escritura al día para incurrir en gastos, por lo que se puede decir que para el uso en nuestra planta el coste es de 0€.

Podemos encontrar toda la información relativa al uso de los servicios de Google Cloud en el siguiente enlace:

https://firebase.google.com/pricing?hl=es-419

Este servicio se usa para el trabajo en tiempo real, aunque entre sus servicios disponemos de autentificación y analíticas entre otros, una vez descargados los datos de los servidores de Google a una base de datos propia esos datos son ya exclusivamente de nuestra propiedad.

• La integración de estas tecnologías con SAP es posible, si por ejemplo se quisiera llevar más allá de las actuaciones puntuales y enlazar con SAP PM en WCM. En estos momentos no poseo conocimientos de alto nivel en SAP ya que no es mi especialidad, pero me estoy formando por iniciativa propia.

Conclusión

HIRALITE, es una herramienta para el trabajo del día a día en las instalaciones, agiliza el trabajo y la comunicación en las tareas comunes. Puede suponer una primera aproximación a lo que se ha denominado como industria 4.0 y pretende poner de manifiesto que estas tecnologías son aplicables a cualquier campo donde se requiera una automatización de procesos. En este caso, se integra en la red de seguridad con la creación de HIRALITE y órdenes de trabajo, pero este tipo de tecnologías progresivas son aplicables allí donde exista un procedimiento en diferentes ámbitos susceptible de ser digitalizado.

Palabras clave

Industria 4.0, automatización de procesos de seguridad y calidad, comunicación, App multiplataforma.

 

El auge de la IA

El mundo está apunto de cambiar “otra vez”.  

OpenAI, empezó como una organización sin ánimo de lucro creada por (adivina quien) Elon Musk y Sam Altman. La idea era promover un desarrollo justo de la IA, democratizarla para beneficio de toda la humanidad. 

En 2019 Musk abandona el cargo en OpenAI y ese modelo “sin ánimo de lucro” deriva en un modelo mixto capaz de poder financiar su supervivencia, OpenAI abre una ronda de inversiones y aparece Microsoft que invierte mil millones de dólares.  Desde luego una inversión arriesgada por parte de Microsoft si se considera que aún en 2019, los modelos generativos de imagen y texto como ChatGPT aún eran ciencia ficción pero estamos hablando de Microsoft. 

El 30 de noviembre de 2022 es la fecha de lanzamiento de ChatGPT. Se trata de un modelo conversacional basado en un modelo anterior (GPT-3.5), que es capaz de interactuar con un humano respondiendo preguntas en cualquier idioma incluso es capaz de generar código de forma de forma tan eficaz como lo haría un humano, tanto que asusta un poco. De repente esta forma de IA ya no es sci-fi y aquí viene la jugada maestra de Microsoft, parte de esos mil millones invertidos en OpenAI están en créditos de uso de su plataforma Cloud Azure. ¿Por qué? Porque en el campo de la inteligencia artificial uno de los mayores problemas para efectuar desarrollo e investigación es la gran potencia de computación necesaria para entrenar modelos, así que OpenAi se garantiza desde el principio poseer poder crear computación ilimitada. 

Mientras que Microsoft, que ha dado otra vez en el clavo, va perfilando su modelo de negocio para rentabilizar la gran inversión realizada. Va a haber miles de empresas que querrán crear servicios basados en ChatGPT y la gran malloría querrán un modelo funcional, estarán dispuestas a pagar por el acceso a una API que les devuelva directamente los resultados de consultas a la IA que, además funciona en Microsoft Azure.

De mientras, hay otro actor en esta apasionante historia que aún no se ha pronunciado, hablamos claro está de Google. El gigante con su proyecto DeepMind, no se va a quedar de brazos cruzados viendo a Microsoft comerse todo el pastel. Google tiene tanto poder de computación Cloud como Microsoft (o más) y estos días ha sido noticia que Google ha convocado a sus creadores  Larry Page y Sergey Brin para que vuelvan a primera línea en la batalla por la posición predominante en el campo de la IA. 

Todo esto no es más que la punta de iceberg de todo lo que se nos viene encima. Vivimos sin duda un tiempo tan excitante como cuando apareció la primera internet o el iPhone probablemente mucho más, un tiempo que está apunto de cambiar para siempre nuestra forma de vida. 

 

Todo no es de color de rosa 

 

“El éxito en la creación de la inteligencia artificial podrá ser el evento más grande en la historia de la humanidad. Desafortunadamente también sería el último, a menos de que aprendamos cómo evitar los riesgos”.

 

Esta frase fue publicada por Stephen Hawking en un artículo para The Independent en 2014. El famoso físico también publicó un artículo en conjunto con los expertos Stuart Russell, especialista en computación, y los físicos Max Tegmark y Frank Wilczek en el que se advertía de los pocos estudios serios que se habían realizado más allá de el Machine Intelligence Research Institute y el Future of Life Institute" advirtiendo que que la comunidad científica aún no se estaba preocupando lo suficiente por mantener bajo control un eventual sistema de inteligencia artificial autónoma el día en que se descubriera.

 

¿Qué es la inteligencia artificial?

 

En 1950, el matemático Alan Turing se hizo una pregunta: “ ¿Pueden pensar las máquinas?”. Esta simple pregunta transformaría el mundo. El artículo de Alan Turing «Computing Machinery and Intelligence» y el consiguiente «Test de Turing» sentaron las bases de la inteligencia artificial, su visión y sus objetivos.

 

El objetivo de la inteligencia artificial pretende responder afirmativamente a la pregunta de Alan Turing, es decir pretende replicar o simular la inteligencia humana en las máquinas. Este ambicioso objetivo plantea muchos interrogantes y suscita el debate. Por ello, aún no existe una definición única de inteligencia artificial. 

En un intento de remediar este problema, Stuart Russell y Peter Norvig publicaron el libro «Artificial Intelligence: A Modern Approach».

 

En el  libro, los dos expertos unifican sus trabajos sobre el tema de los agentes inteligentes en las máquinas. Según ellos, «la IA es el estudio de los agentes que reciben percepciones del entorno y realizan acciones».

 

Otra definición moderna describe la IA como «máquinas que responden a simulaciones como los humanos, con capacidad de contemplación, juicio e intención». Estos sistemas son capaces de «tomar decisiones que normalmente requieren un nivel humano de conocimiento». Tienen tres cualidades que constituyen la esencia de la inteligencia artificial: intencionalidad, inteligencia y adaptabilidad.

Estas diferentes definiciones pueden parecer abstractas y complejas. Sin embargo, ayudan a establecer la inteligencia artificial como una ciencia informática. 

Dejo algunas capturas de mi primer contacto con ChatGPT

Aquí le pido que me escriba un programa en PHP que imprima por pantalla 4 veces el texto “Hola mundo”. No solo me lo escribe perfectamente funcional si no que me lo explica al detalle;

 

CRUD POO PHP MVC (PROYECTO STAR CRUD PARTE 2) Login y Sesiones

 

Vista login.php

Ahora que podemos registrar usuarios ha llegado el momento de permitir que nuestros usuarios usuario puedan logearse en nuestro CRUD. Para ello vamos a crear una nueva vista que llamaremos login.php y que será muy parecida a register.php, pero en este caso solo necesitaremos dos inputs en el form, user y password, vamos a ello:

CREANDO LA VISTA LOGIN

Vamos a nuestra carpeta views y creamos el archivo login.php:

Copiaremos y pegaremos la vista de register, pero haremos algunos cambios al formulario.

• -        Eliminaremos el input para el user name
• -        Cambiaremos el nombre al botón submit
• -        Cambiaremos el name a los inputs email y password

 

·        En el action del form seguimos mandando la data al controlador gestionvista (en rojo)

• ·        Al input para el email lo llamaremos login_email_txt (en verde)
• ·        Al input para el passwor lo llamaremos login_password_txt (en violeta)
• ·        Al botón submit lo llamaremos login_btn (en azul)

<!-- Hero form -->
<!-- Hero -->
<div class="p-5 text-center rounded-3">
  <div class="mask">
    <div class="d-flex justify-content-center align-items-center">
      <!--Form-->
      <form class="myform" name="login_frm" action="../controllers/gestionvista.php" method="post" enctype="multipart/form-data">
      <h2>Login</h2>
      <br>  
       <div class="mb-3">
         <label for="exampleInputEmail1" class="form-label">Email address</label>
         <input type="email" name="login_email_txt" class="form-control" id="exampleInputEmail1" aria-describedby="emailHelp">
         <div id="emailHelp" class="form-text cuote">We'll never share your email with anyone else.</div>
       </div>
       <div class="mb-3">
         <label for="exampleInputPassword1" class="form-label">Password</label>
         <input type="password" name="login_password_txt" class="form-control" id="exampleInputPassword1">
       </div>
         <button type="submit" name="login_btn" class="btn btn-dark">Submit</button>
      </form>    
      <!--End form-->
    </div>
  </div>
</div>
<!-- Hero -->

Recogiendo los datos de login en el controlador gestionvista.php

Vamos a crear un nuevo método en nuestro controlador gestionvista que se encarge de recoger los datos del formularo de login que estamos enviando desde la vista de logín, del mismo modo que lo hacíamos con register y solo para asegurarnos de que recibimos bien el mail y el pass los imprimimos por pantalla:

//Recogemos los datos del formulario login por el nombre del botón de submit, en este caso lo hemos llamado login_btn
if(isset($_POST["login_btn"]))
{
    //recojemos los datos en variables podemos llamar a las variables como en la función register ya que estas viven solo en este scope.
    $u_email = $_POST["login_email_text"];
    $u_password = $_POST["login_password_txt"];
    echo "Email: ".$u_email." password: ".$u_password." ";

Si hacemos clic en el submit y mandamos los datos a gestiónvista.php podemos ver la salida en pantalla:

Ahora que sabemos que estamos recibiendo correctamente estos datos, es momento de crear nuestros métodos para hacer login y vamos a ir hacia atrás, es decir desde el modelo tusers.phpàtcontrol.phpà hasta gestionvista.php.

Nos ocuparemos primero de crear el método login en el modelo tusers.php

   public function login()
   {
       //No es necesario comprobar previamente si el usuario existe ya que lo que queremos es hacer login si existe.
       $res = false;
 
       //Realizamos la consulta sql buscando el mail y el pass recibido,  para comprobar las credenciales del usuario usando el método consult_SQL del modelo dbaccess.
       if($this->dba->consult_SQL(" SELECT *  FROM users WHERE email = '". $this->email."' "))
       {
           //Si la consulta ha tenido éxito accedemos a la fila de resultados usando el método de dbaccess consult_row
           if(this->dba->consult_row() > 0){
             //Si hemos encontrado una fila de resultados de momento vamos a sólo a imprimirla para ver si funciona.
             $res = $this->dba->consult_row();
             echo $res;
           }
       }
   }

Es importante que a variable $this->email, vaya entre doble comillado para que en la consylta se lea sua valor como cadena de texto, de lo contrario no funcionará.

Ya tenemos preparado el método login en el modelo tuser.php vamos ahora a nuestro controlador principal tcontrol.php y crearemos un método que podemos llamará userLogin para seguir con la nomencaltura de los métodos:

En este caso sólo necesitamos como payload el mail y el password pero para la instancia le pasamos todo el payload que necesita la clase:

public function userLogin($u_mail, $u_password)
{
  //Creamos una instancia de la clase Tusers y aunqye no necesitamos el u_name lo incluimos en el payload del método.
  $u_login = new Tuser($u_name, $u_email, $u_password, $this->host, $this->user, $this->password, $this->db);
  {
    //Invocamos el método login d ela clase Tuser y lo guardamos en la variable de res.
    $res = $u_login->login();
    return $res;
  }
}

Por último, regresamos a gestionvista, donde vamos a crear una instancia de la case Tcontrol y a invocar el método que acabamos de crear userLogin, pasándole en el payload los datos de conexión, el mail y el pass recibidos y el username lo dejaremos en null.

//Recogemos los datos del formulario login por el nombre del botón de submit, en este caso lo hemos llamado login_btn
if(isset($_POST["login_btn"]))
{
    //recojemos los datos en variables podemos llamar a las variables como en la función register ya que estas viven solo en este scope.
    $u_email = $_POST["login_email_txt"];
    $u_password = $_POST["login_password_txt"];
 
   // echo "Email: ".$u_email." password: ".$u_password." ";
 
    //Creamo un objeto de la clase Tcontrol
    $u_l = new Tcontrol();
    //Invocamos el método userLogin pasando en el payload lo que necesita menos el username que lo enviaremos en null.
    $login_user = $u_l->userLogin("", $u_email, $u_password);
    echo $login_user;
}

 Ya podemos probar nuestro sistema de login, estamos registrados con el mail y el password que tu hayas usado para registrate.

Vamos a hacer login con las credenciales correctas a ver si se nos muestra nuestro mensaje de extio

Si introducimos el mail y la contraseña correctos el mensaje de éxito se muestra:

Si introducimos alguna credencial no válida:

Todo está funcionando correctamente, debemos ahora pasar a iniciar sesión de usuario

 

Creando la sesión de usuario logeado.

Vamos a ver qué es lo que tenemos hasta ahora:

Como podemos ver en el esquema, la secuencia es la siguiente:

1.      En login.php (vista) el usuario introduce su user y password, que previamente a registrado, el formulario envía estos datos vía POST a gestionvista.php.

2.     gestionvista.php (controladores) hemos incluido el archivo tcontrol.php, creamos un objeto de la clase Tcontrol, que llamamos $u_l para poder acceder al método userLogin() de la clase Tcontrol y le pasamos el payload que necesita, retornamos la respuesta del método login() de la clase Tcontrol.

3.    tcontrol.php (controladores)  incluimos el archivo tusers.php, creamos un objeto de la clase Tuser() que llamamos $u_login para poder acceder al método de la clase Tuser login(), usamos el método user_exists de la clase Tcontrol para asegurarnos que el usuario existe.

4.    tusers.php en tusers (modelos) recibimos como payload, todo lo que necesitamos saber, user, password, y credenciales de la base de datos, además sabemos ya que el usuario si existe en nuestra base de datos. Y esta clase se encarga de todo lo relacionado con la base de datos.

Respuestas encadenadas.

Si el loggeo ha tenido éxito, las respuestas se desencadenan de un método a otro desde los modelos a los controladores, del siguiente modo:

 

gestionvista.phpßtcontrol.phpßtusers.phpàdbaccess.php

Al final la respuesta iniciada a en tusers.php se traslada hasta el controlador gestionvista.php que se encargará de mostrar la vista que allí le indiquemos, ahora mimo solo hemos lanzado la información del usuario que se ha logeado, y por tanto se nos muestra esa información en gestionvista.php:

   public function login()
   {
       //No es necesario comprobar previamente si el usuario existe ya que lo que queremos es hacer login si existe.
       $res = false;
       //Realizamos la consulta sql buscando el mail y el pass recibido,  para comprobar las credenciales del usuario usando el método consult_SQL del modelo dbaccess.
       if($this->dba->consult_SQL(" SELECT * FROM users WHERE email = '".$this->email."' AND password = '".$this->password."'  "))
       {
           //La consulta la realiza con éxito el usuario existe.
           if(($this->dba->consult_row()))  
           {
               //Accedemos a los datos del usuario logeado
               if ($this->dba->consult_data('email'))
               {
                  $logged_user_name = ($this->dba->consult_data('username'));
                  $logged_user_email = ($this->dba->consult_data('email'));
                  $res = "El usuario : ".$logged_user_name." con email: ".$logged_user_email." ,Ha hecho login ";
               }
           }
           else
           {
             $res = true;  //Hacemos true la respuesta
           }
      }
      return $res;
  }

 

Lo que queremos hacer es que una vez el usuario se ha logeado lo queremos enviar a una página donde ya se pueda crear, editar o eliminar un registro y queremos que esa página esté protegida con sesiones de PHP. Por tanto, vanos a crear esa página protegida.

Lo primero será crear en el método login() de la clase tusers las variables de sesión en el array global $_SESSION[] y abriremos una sesión con el id del usuario, esta sesión será usada en la página del CRUD crud.php que vamos a proteger, además tendremos que crear un nuevo método púnlico aquí en tusers, para que el usuario pueda cerrar la sesión. Vamos a ver cómo:

   public function login()
   {
       //No es necesario comprobar previamente si el usuario existe ya que lo que queremos es hacer login si existe.
       $res = false;
       //Realizamos la consulta sql buscando el mail y el pass recibido,  para comprobar las credenciales del usuario usando el método consult_SQL del modelo dbaccess.
       if($this->dba->consult_SQL(" SELECT * FROM users WHERE email = '".$this->email."' AND password = '".$this->password."'  "))
       {
           //La consulta la realiza con éxito el usuario existe.
           if(($this->dba->consult_row()))  
           {
               //Accedemos a los datos del usuario logeado
               if ($this->dba->consult_data('email'))
               {
                  //$logged_user_name = ($this->dba->consult_data('username'));
                  //$logged_user_email = ($this->dba->consult_data('email'));
                  //$res = "El usuario : ".$logged_user_name." con email: ".$logged_user_email." ,Ha hecho login ";
 
                  //Aqui debemos de iniciar sesión de usuuario
                  //Creamos las varaibles de sesión en el array global $_SESSION[]
 
                  //Iniciamos una sesión
                  session_start();
                  //Creamos una variable que se haga true si el login ha tenido éxito
                  $_SESSION['login'] = true;
                  //Creamos otra variable consultando los datos del usuario acceiendo a su username
                  $_SESSION['id'] = ($this->dba->consult_data('username'));
 
                  //dirigimos al usuario con sesión abierta a la página principal del CRUD
                  header('Location: ../views/crud.php');
               }
           }
           else
           {
          //Si la consulta no tiene éxito mandamos mensaje de error y redirigimos al login.
          echo "<script language='javascript'>
          alert('mail or user not valid');
          location='../views/login.php';
          </script>";
           }
      }
 
      return $res;
  }

 

Vamos a crear ahora esa página crud.php la crearemos en vistas:

De momento solo crearemos una estructura html5 con un mensaje h1 :

<!DOCTYPE html>
<html lang="eS">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>CRUD</title>
</head>
<body>
   <h1> Página protegida con sesiones</h1>
</body>
</html>
 

Ahora si nos logeamos correctamente se nos redirige a la página crud.php mientras que si las credenciales no son válidas se nos devuelve al login previo mensaje de error:

Login correcto:

Ahora necesitamos ir a nuestra nueva vista crud.php para iniciar allí sesión y comprobar si realmente el usuario que accede tiene sesión activa, es decir vamos a proteger esta ruta:

<?php
//Vuelvo a iniciar sesión para poder usar $_SESSION
session_start();
 
if( $_SESSION['login'] != true  ) //Si no hay una sesión activa
{
    //Enviamos al usuario al login
    header('Location: ../views/login.php');
}
//NO hace falta un else, si no hay sesión todo lo demas no se renderiza.
?>
 
<!DOCTYPE html>
<html lang="eS">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>CRUD</title>
</head>
<body>
   <h1> Página protegida con sesiones</h1>
</body>
</html>

 

Si ahora copio la ruta de la página crud.php

Y me voy a otro navegador y la pego, me daré cuenta de que automáticamente la aplicación me manda al login sin poder entrar al CRUD, porque no estoy autenticado:

Lo que necesitamos ahora es crear un método en gestionavista que nos destruya la sesión, de forma que el usuario pueda cerrar sesión antes de abandonar la página protegida.

Podríamos usar un sencillo link a un archivo php que se ocupara exclusivamente de ello, pero recuerda estamos trabajando con el modelo MVC y disponemos del archivo gestionavista.php que es el controlador de vistas, por ello lo que vamos a ahacer es añadir un botón tipo submit, para poder recoger la acción desde gestionavista.php y ahí destruir la sesión, veamos cómo:

Vamos a nuestro archivo crud.php y hacemos:

 <?php
//Vuelvo a iniciar sesión para poder usar $_SESSION
session_start();
 
if( $_SESSION['login'] != true  ) //Si no hay una sesión activa
{
    //Enviamos al usuario al login
    header('Location: ../views/login.php');
}
//NO hace falta un else, si no hay sesión todo lo demas no se renderiza.
?>
 
<!DOCTYPE html>
<html lang="eS">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>CRUD</title>
</head>
<body>
   <h1> Página protegida con sesiones</h1>
   <form class="myform" name="close_session_frm" action="../controllers/gestionvista.php" method="post" enctype="multipart/form-data">
     <input type="submit" name="close_session_btn" value="Close session">
   </form>
</body>
</html>

Ahora si nos logeamos, veremos el botón de cerrar sesión