Como unir AngularJS y Cordova para generar aplicaciones móviles (parte 2)

Y aquí seguimos… dos entradas seguidas… guau…

Venimos de Como unir AngularJS y Cordova para generar aplicaciones móviles (parte 1) y vamos a continuar donde lo dejamos.

Hasta el momento hemos creado los dos proyectos y unido los archivos base package.json.

Ahora es el momento de continuar.

Para que todo funcione, hay que hacer un par de modificaciones en unos archivos de angular.

En el archivo main.ts del proyecto de angular, hay que modificarlo de tal forma que quede similar al siguiente:

Con esto le indicamos que Angular estara atento al evento onDeviceReady que se generará en la aplicación móvil. Y le indicamos que fije un vigilante (listener) al evento “deviceready”.

Despues, deberemos ir al index.html y efectuar un par de cambios. El primero es cambiar la etiqueta “base” para que la ruta haga referencia al directorio actual donde se encuentre la aplicación (esto tiene sentido ya que utilizará la carpeta donde se instale la aplicación en el dispositivo). Así que hay que hacer que quede así:

Despues debemos añadir la referencia al archivo “cordova.js” que será el encargado de proporcionar la interfaz con todos los plugins de Cordova y al dispositivo.

Con estos pasos ya estaríamos en condiciones de compilar y probar la aplicación, por lo que será necesario instalar todas las dependencias de node, compilar angular, añadir las plataformas a probar en cordova y compilar o correr el proyecto. Los pasos básicamente con los siguientes comandos (1 linea por comando)

Si queremos probar en modo local, se puede ejecutar un servidor local que correrá en el puerto 8000 con

Si tenemos un dispositivo (Android por ejemplo) conectado al pc y con la depuración y demás requisitos instalados, y queremos ejecutar la aplicación sobre el, se puede ejecutar el siguiente comando.

A partir de este punto entramos en las consideraciones para el desarrollo, aquí es donde probablemente haya quien lo haga de forma diferente y mejor. Yo por mi parte para ir haciendo los cambios y poderlos observar lo que hago es situar a angular en modo compilación continua cada vez que detecta cambios en el código fuente con:

Despues arranco el servidor Cordova con el comando anterior serve, y lo que hago es que cada vez que hago algún cambio relevante y quiero probarlo en cordova, ejecuto el comando

O bien si solo voy a colocar una plataforma (Android por ejemplo)

Y después, según la plataforma, o bien ya puedo comprobarlo directamente (en el navegador) o vuelvo a ejecutar el run del dispositivo.

Nota: Un último apunte. Si teneis instalado el sdk de android y teneis algún android virtual, el siguiente comando arranca ese dispositivo virtual para poder efectuar el desarrollo si no teneis uno físico disponible.

En otra entrada continuaré con este desarrollo, y escribiré sobre cómo he conseguido hacer una integración continua con este proyecto, Visual Studio Team Services y HockeyApp, para poder tener Integración continua con el repositorio y poder distribuir las apps que se hagan por los betatesters antes de subirlo a las tiendas. Ese paso también lo abordaré… cuando aprenda a hacerlo jeje…

¡Muchos saludos y gracias por leerme!

Laravel: error stream_socket_enable_crypto(): al tratar de usar certificados autofirmados

Buenas a todos.

Continuando con el desarrollo con Laravel 5.4, me encontre en la tesitura de usar desde la máquina de desarrollo el poder enviar correos electrónicos con el protocolo smtp.

Buceando por la red un buen rato, la solución la encontré aquí.

Y básicamente consiste en añadir las siguientes opciones al archivo “config/mail.php” de Laravel.

Con esto, conseguiremos que no se haga la comprobación completa del certificado (especialmente para certificados auto-firmados), pero si que se efectue la negociación de la conexión cifrada.

Espero que os sirva de ayuda.

Angular. Consumiendo la API para el login

Seguimos en liza. En las entradas anteriores vimos como configurar las rutas para poder separar nuestro proyecto en la parte “frontend” o la que vera el usuario, y la parte “backend” o zona de administración de los contenidos. También configuramos nuestra app para poder tener las variables de entorno separadas en desarrollo y producción.

Hasta este momento, a la hora de buscar un usuario correcto, utilizabamos dos direcciones de correo y sus contraseñas “hardcodeadas” en el archivo de login.

Esto, evidentemente, es mala idea, lo que necesitamos es que nuestros usuarios puedan entrar con las credenciales que tengan en la base de datos. Y para ello vamos a consumir nuestra api Laravel que hemos ido desarrollando.

Una vez tenemos configurados los entornos, es hora de comenzar a consumir nuestra API de Laravel, comenzando con la llamada de login de usuario.

Para ello, realizaremos algunos cambios.

Servicios.

Primero crearemos un nuevo servicio llamado “user.service.ts”, que contendrá la clase para los datos del login. Dicho archivo quedará así:

Despues, en login.service.ts, realizaremos algunos cambios. Comenzaremos por adecuar los imports:

Despues la clase y el constructor, donde añadiremos el objeto http para poderlo utilizar en la llamada a la api:

Ahora, y por no cambiar de momento el orden de las funciones con respecto al momento anterior del login, para no perdernos, adecuamos la función logout, de tal manera que borre los datos que se recogieron al conseguir un login correcto.

Y ahora viene el login. Hay varios cambios con respecto al anterior. Donde antes unicamente se comprobaba si los datos estaban en el array de usuarios que teniamos hardcodeado, ahora es necesario realizar una petición http a la api para que nos devuelva los datos adecuados del usuario o bien un error de existir algún problema.

Para ello, en la funcion, conformamos las cabeceras (headers), el cuerpo (body) y las opciones de la petición (request) que vamos a efectuar, y esperaremos que nos devuelva una respuesta (response) que será la que trataremos.

Hasta aquí es sencillo, ¿no?. Bueno, el cambio mayor en esta funcion es que la función login(user) pasa a ser una promesa (promise) de angular. Y esto es así porque necesitamos que se efectue el login y que según el resultado la aplicación efectue una acción u otra. En otros momento que se necesiten cargas asincronas de datos, será posible usar los Observables de Angular, pero, en mi humilde opinión, en este caso que se necesita disponer de la respuesta a la petición para poder tomar una decisión sobre si dejar actuar al usuario o no, es mejor utilizar una Promise, que nos permite esperar la respuesta de una forma más sencilla, ya que tiene dos eventos (reject y resolve) para las situaciones de error y satisfactorias, que nos permitiran tomar las decisiones adecuadas para el caso.

Para ello, al declarar la función login(user) le añadimos que sera de parametro Promise<any>.

La función queda así (ahora sigo desgranandola):

Cómo se puede observar, se genera el usuario a realizar el login (usertologin), se generan las cabeceras, cuerpo y opciones para la petición (headers, body y options), y se efectua la petición http, y su respuesta es la que se devuelve como resultado de la función. Si se observa la implementación, se utiliza la petición http también como una promesa al ponerla el modificador .toPromise(), y se utilizan los bifurcadores .then() y .catch() para recibir el resultado, bien satisfactorio o bien de error, y se envían a dos funciones auxiliares que trataran los datos.

Y las funciones auxiliares quedan como sigue:

Esta función ya la utilizabamos para decidir si volviamos al login porque el usuario no estuviera guardado en memoria, y de momento no se ha cambiado.

En esta funcion resolvemos el error que nos haya podido dar la petición. En este caso lo que hacemos es escribir en la consola el error (recomiendo comentar esta línea antes del paso a producción), y devolvemos el rechazo de la promesa y devolvemos el error, que ya viene personalizado de la api para los casos adecuados.

Y esta es la función de login satisfactorio. Como veis es similar a la anterior, pero esta vez resolviendo la promesa satisfactoriamente y devolviendo los datos de usuario para que sean tratados.

Componente.

Ahora, en el componente de nuestro formulario de login, que controla su funcionamiento, es donde le diremos que debe hacer con estos nuevos datos, y lo adecuaremos a la nueva situación.

Como se puede observar, lo que se ha hecho es utilizar la llamada al servicio para generar una respuesta, y en función de los datos obtenidos, bien redirigir al usuario al inicio de la administración, o bien presentarle un mensaje de error en el formulario, para que pueda observar que está mal introducido o si ha habido algún otro error.

Y con esto estaremos en disposición de continuar.

Nota: Es posible que os encontreis con problemas de CORS (recursos remotos) cuándo trateis de hacer el login y lo esteis viendo en las consolas de los navegadores. Vereis que los clientes REST que utiliceis funcionan correctamente, pero el login de nuestro servidor de desarrollo angular (localhost:4200, el creado con npm start) no hay forma de hacerlo andar. De forma rápida, aunque no es lo adecuado en sitios de producción, lo que debeis hacer es que en el servidor que este sirviendo la api (iis, apache, nginx, etc) hagais que para la api siempre mande la cabecera “Access-Control-Allow-Origin” con el valor “*”. y que os instaleis una extensión en el navegador que os permita activar o desactivar el CORS a voluntad.

 

Laravel. Implementando CORS

Un pequeño inciso.

Al desarrollar la parte con angular y tratar de realizar el login y que funcione correctamente con la API, os podreis encontrar con el problema de que las peticiones desde el login de angular a la api os den un resultado diciendo que son fallidas porque se piden desde otro recurso (otro servidor, otra ip, etc).

Al final, para sitios de desarrollo, lo mejor es que activeis la cabecera “Access-Control-Allow-Origin” en el servidor que esteis utilizando.

Por ejemplo en apache incluyendo en el htaccess de la api esto:

y ademas, os recomiendo instalaros alguna extensión que os permita manejar el tema de cors a vuestro antojo.

En firefox he instalado esta: https://addons.mozilla.org/en-US/firefox/addon/cors-everywhere/

Y en Google Chrome esta: https://chrome.google.com/webstore/detail/allow-control-allow-origi/nlfbmbojpeacfghkpbjhddihlkkiljbi?hl=es

Si veis que os salen este tipo de errores, antes de maldecir a vuestro servidor o vuestro pc, comprobad esto y al menos dejadlo “libre” en vuestro servidor de desarrollo, en el de producción será otra cosa.

Saludos.

Angular. Entornos (environments)

Antes de continuar con el desarrollo de angular, hemos de colocar un par de cosas.

Hasta este momento hemos estado desarrollando la parte de angular de forma local, es decir, todo funcionaba dentro de la propia app e incluso al compilarla para tenerla en el servidor de producción las rutas y demas factores hacían referencia a rutas “locales”.

Pero para poder empezar a consumir los datos de la api que estamos desarrollando en paralelo en las entradas referidas a Laravel, hemos de comenzar a separar los entornos de “desarrollo” y de “producción”.

En angular, al crear un proyecto, se habrá creado una carpeta y unos archivos llamados “environment”, que serán los que usaremos para poder definir las variables de entorno que vayamos necesitando para el proyecto.

Lo normal es encontrarnos con dos archivos, uno para el entorno de desarrollo, “environment.ts”, y otro para producción, “environment.prod.ts”.

En este momento la unica variable que nos va a hacer falta es la url de nuestra api, por lo que modificaremos los archivos para incluir lo siguiente:

Cambiando “urltoapi” a los valores adecuados para nuestros servidores.

Así que, una vez hechos estos cambios, hasta ahora utilizabamos

Para construir la aplicación, sin embargo a partir de ahora le indicaremos que use el entorno de producción. Sin parámetros usará el archivo “environment.ts” que es el de desarrollo. De esta forma el comando resultante es:

Y si ademas queremos minimizar los archivos para que queden compilados de manera que ocupen lo mínimo posible usaremos:

En estos archivos podremos colocar las variables que necesitemos, a la hora de usarlas será necesario incluir en nuestros archivos de servicios, controladores, etc… el siguiente codigo:

Así podremos utilizar las variables definidas en estos archivos de la forma usual.

Angular. Implementando Login.

Hasta este momento hemos tenido siempre visible nuestra app angular con la parte publica (la que va a ver cualquier usuario que entre a la app).

¿Qué ocurre si vamos a implementar una administración?

Bueno, pues es el momento de empezar a separar cosas y usar las rutas de Angular para el funcionamiento. Lo que vamos a hacer es separar nuestra app, de momento, en tres rutas: “client” (para los visitantes), “login”, para el formulario de entrada a la administración, y “admin” para la administración en si.

Para ello, hay que modificar un poco nuestra aplicación.

Comenzamos por crear un nuevo modulo con ng generate module routes. Con esto generaremos un nuevo archivo en el que vamos a colocar la logica de nuestras rutas de aplicación para que pueda funcionar.

A partir de aquí, tendremos que rellenar todos los campos para que las rutas sean reconocidas y utilizadas en nuestra app. Así que vamos por pasos:

  • routes\routes.module.ts

  • app.component.html. Este únicamente necesita estar compuesto por
  • main.ts. Aquí indicaremos nuestro modulo de rutas y que se utilicen en el inicio del modulo de la app.

  • app.module.ts. Aqui tenemos que declarar las rutas e importarlas para que sean usadas correctamente. Sino habrá errores.

Ahora generaremos los componentes que formarán el login y la entrada a la administración.

  • ng generate component common\login. Con esto generaremos el componente del formulario de login.
  • ng generate component admin\main. Con esto generamos el componente de entrada a la administración.
  • ng generate service services\login. Con esto generaremos el servicio que se encargara de procesar los datos.

Y finalmente los poblaremos. De momento en la clase login está una clase “User” con los datos a pelo, en otra entrega utilizaremos un servicio para consumir los datos de la API que creamos con Laravel para hacer el login.

  • login.service.ts

  • login.component.ts

  • login.component.html

  • main.component.ts

  • main.component.html

Con todos estos pasos, si comprobamos en nuestro navegador (teniendo encendido el servidor de angular de desarrollo, claro, con npm start), podremos ver que las rutas funcionan.

La ruta raíz (“/” o ” “) nos redirige automaticamente a la parte cliente (lo que hemos estado personalizando hasta ahora).

La ruta de administración (“admin”) nos redirige al formulario de login (ruta “login”) si no nos hemos autentifcado, y nos muestra el mensaje de autenticación correcta y el link de logout.

Y con esto estamos en condiciones de ir desarrollando tanto la administración como la parte cliente.

En proximas entradas iremos viendo componentes, servicios y datos necesarios. Tambien volveremos a Laravel cuando haya detalles que impliquen nuevas situaciones con la API.

Muchas gracias por seguir hasta aquí 🙂

Actualizacion: una cosa más, para que funcione en el servidor apache, una vez compilada la web con ng build --prod es necesario que exista un archivo .htaccess con el siguiente contenido. Sino, las rutas no funcionaran:

 

Angular. Personalizando el estilo de Bootstrap.

Puede que a estas alturas nos estemos pensando como personalizar los colores y las fuentes de nuestra app para ir dejando cabos sueltos ya atados antes de empezar con el grueso de los componentes y demás elementos que necesitarán estilo.

En una entrada anterior, ya vimos como integrar bootstrap con angular, ahora es el momento de ver como podemos personalizar ese tema.

En este caso yo voy a optar por un tema oscuro. Para ello, en la web de https://bootswatch.com/ voy a incluir el tema “Darkly” para la app.

El método es sencillo. En la web, en el tema, nos descargaremos el archivo de mínimos de bootstrap (), y lo vamos a incluir en la carpeta “assets/css/global” de nuestra aplicación. Una vez conseguido esto, habrá que modificar el archivo “angular-cli.json” para incluirlo en la sección styles, quedando de esta forma:

Una vez hecho esto, os podeis encontrar con errores al ser compilada nuestra aplicación. En mi caso son errores del tipo:

Bueno, pues se trata de que no está reconociendo la fuente para poder mostrar los iconos. Ante esto la opcion es instalar la fuente con el comando npm install --save glyphicons. Despues de que se haya instalado, hay que modificar el archivo css que acabamos de instalar y modificarlo para eliminar la referencia “@font-face” que hace referencia a los archivos de la fuente Gliphicons.

Dado que la hemos incluido con el anterior npm install, a partir de este momento la fuente estará disponible para ser utilizada, y nuestra app tendra el aspecto del tema que hemos elegido.

AngularJS. Añadiendo el menú superior.

Una vez que en la entada anterior hemos conseguido que se integre bootstrap con angular, es el momento de comenzar a personalizar la aplicación para nuestros fines.

Como voy a utilizar parte de un desarrollo anterior hecho con Codeigniter, Bootstrap y JQuery, parte del código está ya hecho, solo hay que adaptarlo a nuestra nueva disposición para que se muestre adecuadamente.

Pero antes de empezar, habrá que preparar el entorno. En mi caso he decidido separar las funciones de “frontend” y de “backend”, por lo que voy a generar una estructura de carpetas dentro del proyecto de la forma adecuada. También voy a colocar los recursos del proyecto en una carpeta “assets”, que a su vez tendré separada por los elementos que lo componen y por las dos funciones.

Al final nos encontramos en este momento con una estructura como la siguiente:

Como se puede ver, “assets” está separado en los tipos de elementos (css, js, media), y a su vez “media” está separado en sus tipos de elementos (iconos, imagenes, videos, etc), y dentro de cada una esta dividida por su ámbito de accion (frontend, backend y global). Esta estructura es la elegida por mi, por lo que cada cual puede optar por crear la que quiera, pero para sencillez a la hora de encontrar los elementos, recomiendo que al menos la carpeta “assets” esté creada dentro de la carpeta “src/app”.

Una vez realizado y colocado los elementos que vayamos a utilizar, modificaremos el archivo “nav.component.html” que creamos en la sección anterior para que quede de esta forma:

Nota: cabe aclarar que aún no he colocado las rutas de los enlaces (elementos “a”), por lo que aunque en nuestra app de prueba ya se vean los resultados, los enlaces no funcionan.

Tambien he modificado el archivo index.html, para que muestre de favicon el logotipo adecuado, y no el de angular.

Angularjs: Añadiendo Jquery y Bootstrap.

Vamos a empezar a ver el desarrollo de nuestra webapp para el frontend del proyecto.

En la sección anterior instalamos las herramientas necesarias, y ahora vamos a empezar a modificar para ir viendo los cambios.

Os recomiendo seguir este curso: https://www.udemy.com/curso-de-angular-4-desde-cero-hasta-profesional/. Yo únicamente iré comentando aquí las cosas que sean específicas para el proyecto que estoy desarrollando en estas entradas.

El primer paso para nuestro proyecto, es asegurarnos de que todas las dependencias están colocadas correctamente. Por si acaso no estuvieran, instalamos jquery y bootstrap en nuestro proyecto, de esta forma:

Despues modificaremos nuestro archivo “angular-cli.json” y añadiremos las siguiente dependencias de css en la sección styles:

En este momento, si ejecutamos un “npm start” el proyecto ya tendrá las dependencias colocadas.

Para comenzar, vamos a implementar una plantilla base de boostrap, para ver que todo está correcto. Así que modificaremos el archivo “app.component.html” para que tenga el siguiente contenido:

Y cambiaremos el archivo “styles.css” que incluye con el siguiente contenido:

Con esto habremos personalizado la base, pero ahora vamos a incluir la barra de navegación de bootstrap. Para ello crearemos un nuevo componente con el comando  ng generate component frontend/nav (la parte “frontend” no es necesario incluirlo para que nos genere el componente, pero yo lo incluyo porque voy a diferenciar los componentes que pertencen a la parte “frontend” o “pública” de la app, y a los componentes de una sección “backend” o de “administración”.

Una vez creado el componente nav, lo incluiremos en la web, modificando el archivo “app.component.html” e incluyendo en el  <app-nav></app-nav> antes de la apertura del div “container”, quedando el archivo de esta forma:

Una vez hecho esto, veremos una frase “nav works!” por encima del contenido que teniamos antes.

En este momento modificaremos el archivo “nav.component.html” para que tenga el siguiente contenido:

Y con esto en el navegador podremos comprobar que se ha añadido la barra de navegación con los estilos de bootstrap.

¡Estamos listos para continuar! y empezar a definir los componentes de la parte pública.

Angularjs. Instalando el entorno.

Comenzamos con Angularjs.

A estas alturas ya deberíamos tener instalado nodejs y las herramientas necesarias. Por si acaso, voy a hacer un pequeño resumen (para Windows).

  • Instalar nodejs desde https://nodejs.org/en/. Yo me descargué la versión actual (en el momento de crear esta entrada la 7.10.0)
  • Instalamos la CLI de Angular. Si no estamos seguros de si lo tenemos o no, lo mejor es hacer limpieza primero y reinstalar.
    • Ejecutar npm cache clean.
    • Vaciar el directorio %userdata%\AppData\Roaming\npm\node_modules.
    • Ejecutar npm install -g @angular/cli@latest (así tendremos la ultima versión disponible).
    • Ejecutar npm install -g bower (para tener Bower disponible).
    • Ejecutar npm install -g gulp (para tener disponible Gulp).
    • Ejecutar npm install -g webpack (si queremos webpack en la versión de este momento de forma global).
  • Crearemos el proyecto con ng new web (he llamado web al proyecto de la web con angular… sigo siendo original).

Una vez instalado todos los elementos, con npm start desde una consola se compilará y ejecutará un miniservidor web local para empezar a desarrollar nuestra app con Angular.

Laravel 5.4. Middlewares

Hasta el momento, y siguiendo la serie de entradas de Laravel, hemos conseguido que nuestra api tenga el modulo CRUD de usuarios, y que esté securizada para que solo los usuarios que tengan el token adecuado funcione.

Ahora es el momento de añadir un paso más en la securización de nuestra aplicación Laravel, en este caso adaptar las peticiones para que únicamente los usuarios con un rol/nivel adecuado puedan ejecutar según qué funciones.

Los middleware, son funciones que nos permiten agregar filtros a cada petición HTTP realizada por un usuario en una aplicación. La finalidad de este componente es disminuir la carga de trabajo en los controladores y proporcionar una solución mucho más simple y estándar a la hora de aplicar las restricciones necesarias en el proyecto.

Lo primero será crear el Middleware que vamos a utilizar, en este caso LevelMiddleware.

Qué nos generará un archivo como el siguiente:

De momento no hace nada más que mandar la petición ($request) al siguiente elemento dentro del framework para que sea tratado. Más adelante lo modificaremos.

Pero antes, vamos a incluirlo en la aplicación para que se pueda utilizar cuando se hagan las llamadas adecuadas. Para esto, incluiremos nuestro Middleware en el archivo Kernel.php, en las zonas adecuadas, en este caso en el array $routeMiddleware, quedando así:

Y modificaremos el archivo de rutas “web.php” para incluir este middleware en las peticiones de la api que no sean la del login, en este momento la del grupo de usuarios, quedando este grupo asi:

Con esto ya estará colocado para que funciones nuestro middleware, y se ejecutará despues de que se haya ejecutado el de “auth:api”, que definimos anteriormente para que sea el verificador de token.

Si quereis ver que se ejecuta el middleware, antes de empezar a modificarlo, probar con un cliente rest alguna de las rutas anteriores, y añadid esta linea en el archivo “LevelMiddleware.php”, antes del return que se creó por defecto:

Vereis que al ejecutarlo os devuelve el error de “notlevel”.

Y a partir de aquí, tras modificarlo adecuadamente, se podrá utilizar para que las funciones que se deseen estén limitadas por el nivel del usuario, proporcionando la separación para nuestra aplicación.

Laravel 5.4: Securizando la API

Bueno, de las entradas anteriores ya tenemos listo el CRUD de usuarios y las rutas para las llamadas.

Ahora voy a seguir las indicaciones de https://styde.net/api-rest-con-laravel-5-1-proteccion-con-access-key/ para poder securizar la API.

Una vez seguidos los pasos de este tutorial para generar la access key de toda la aplicación y securizarla de manera que nadie que no tenga esa clave la pueda utilizar, es el momento de generar la llamada de login para que un usuario pueda loguearse en la aplicacion con una llamada y recibir un access token que le sirva para poder utilizarla.

Cuándo se creó la tabla de usuarios, se añadió un campo de “api_token” que se autogeneraba cuando se guardaba el usuario por primera vez, así que ahora es el momento de generar la llamada de login. Si recordais del paso anterior, en el archivo “routes/web.php” ya incluimos la ruta de login, para estas llamadas.

También os puede pasar que, despues de seguir los pasos del tutorial de styde.net, os esteis encontrando que las llamadas os devuelven un 401 not authorized si intentais las llamadas sin incluir el access token que ahí está generado.

Pero vamos por pasos. Lo primero es generar el controlador y el modelo que usaremos para el login

E incluir la función login() en la clase del controlador, y el modelo, por lo que quedaría así:

Si estamos siguiendo los pasos, ahora mismo al probar la url de login nos pueden pasar dos cosas: o bien nos de el ok sin contenido, o bien nos de un 401 not authorized. Esto ultimo se debe a la comprobación que hace la clase “VerifyAccessKey” que generamos para securizar la API. Lo que tenemos que conseguir es que no haga esta comprobación si las rutas de uso son “/” o “/v1/login”.

Para ello, tendremos que modificar lo siguiente (o al menos lo que a mi me ha funcionado):

En App\Http\Kernel.php, ha quedado así:

En App\routes\web.php, modifcar el grupo para el prefijo “v1”, ha quedado así:

En App\Http\Middleware\VerisyCsrfToken.php, añadir al array $except la ruta de login:

Ya tenemos la api segura para las llamadas que no sean la raíz y el login. Ahora es el momento de que ese login haga algo. Únicamente va a tener una funcion login para hacer la petición, y devolverá 3 datos para que sean guardados en la sesión del usuario.

LoginController.php

Models/Login.php

Con esto ya tenemos hecho el login y el usuario recibe un token para poder interactuar después con el resto de la API.

En este punto, hemos de cambiar el verificador de token. Al final queda de esta forma:

Y tras esto habra que modificar y probar adecuadamente el controlador de usuarios para ver que todas las llamadas se producen correctamente y ver que si no está el token no funciona y no autoriza a efectuar la operación.

Por hoy es suficiente…