He heredado una aplicación web de una sola página. Los usuarios no inician sesión: una vez que tienen la URL, pueden navegar por la aplicación (muy simple). La aplicación se comunica con una API de Java.
Solo algunos antecedentes: la aplicación se lanzó muy rápidamente, luego el equipo de desarrollo se retiró 2 meses después. Sospecho que, por lo tanto, hay agujeros en la arquitectura.
Los desarrolladores anteriores implementaron una especie de arquitectura de inicio de sesión anónima que me cuesta entender.
Déjame explicarlo:
En primer lugar, todas las solicitudes a la API deben incluir un encabezado authorization y un userId en la URL de la solicitud, o de lo contrario fallarán. Entonces, actualmente, el código hace lo siguiente:
1 / En el navegador del cliente, el almacenamiento local se verifica para detectar la presencia de accessToken y userId . Si se encuentra el accessToken , se envía como el valor para el encabezado authorization , y si se encuentra el userId , se envía en la URL.
2 / Si accessToken no se encuentra en el almacenamiento local, el UJID genera un UUID de 36 caracteres al azar y se envía en una solicitud POST a un punto final llamado login . Otra propiedad enviada en la solicitud POST se llama merchant , cuyo valor depende de la url de la web; hay 6 variaciones diferentes (diferentes logotipos y estilos solamente) de la IU, cada una con diferentes URL. Entonces merchant puede ser 1 de 6 valores.
3 / En el controlador login en el lado del servidor, se crea un usuario. El servidor genera su propio UUID y lo establece como una propiedad del usuario. El merchant también se establece como una propiedad del usuario. Un token de servicio genera un token de acceso con una fecha de caducidad (en un plazo de 60 días), un secreto y el UUID generado por el servidor. El token de acceso se establece como una propiedad del usuario y el usuario se guarda en una tabla de base de datos. El token de acceso se devuelve al cliente, junto con una propiedad llamada userId , que es el UUID generado por el servidor.
4 / Ahora todas las solicitudes de API posteriores se realizan con el token de acceso en el encabezado authorization , y el userId en la url de solicitud de API, por ejemplo. www.my-api-base-url/v1/abc-123/product donde abc-123 es el userId .
5 / En el lado del servidor, el servicio de token comprueba el encabezado authorization para ver si es válido, y luego se analiza para obtener el UUID. Eso se compara con el UUID en la URL.
Primero, sospecho que hay un error aquí: el UUID generado por el javascript se ignora y el servidor genera su propio UUID. Por lo tanto, no podemos saber si las solicitudes posteriores provienen del mismo cliente de donde proviene la solicitud login . ¿Esto es correcto?
En segundo lugar, ¿por qué necesitamos el userId en la URL? ¿No es suficiente el encabezado authorization ?
En tercer lugar, ¿cuál es el principio principal detrás de este tipo de arquitectura de inicio de sesión anónimo? ¿Es para asegurarse de que las solicitudes posteriores provengan del mismo cliente del que proviene la solicitud login ? ¿Eso es todo? ¿Hay algún otro razonamiento detrás de esto?