¿Por qué convertir la página de inicio de sesión en una aplicación de página única en una página separada?

28

Me pregunto por qué parece ser popular que la página de inicio de sesión de un SPA sea una página separada que no es una página del SPA (como en carga y envío de datos a través de solicitudes ajax).

Lo único que se me ocurre es la seguridad, pero no puedo pensar en un motivo de seguridad específico. Quiero decir que lo único que viene a la mente es que si su página de inicio de sesión en parte del SPA, envía el nombre de usuario / contraseña a través de ajax, que pueden ver herramientas como Firebug o el inspector web, incluso si lo envía de forma normal. Solicitud POST, hay otras herramientas que pueden capturar fácilmente estos datos (como fiddler, httpscoop, etc.).

¿Hay algo que este olvidando?

javascript architecture ryanzec
fuente
2
No creo que haya o deba haber una razón en este caso. Yo diría, ¿por qué no?
Steven Evers
1
Mi argumento en contra sería que tener la página de inicio de sesión como una página html separada mientras que el resto de la aplicación es una arquitectura SPA parece extraño sin ningún beneficio real (aunque el punto que hizo msanford tiene mérito).
ryanzec
@ryanzec Gracias. Agregué un ejemplo en un intento de ilustrar que hay un beneficio real. Primero, el ahorro de diferir la carga de activos en otro lugar no es despreciable, especialmente en el caso de un inicio de sesión fallido (o suspensión de la cuenta, etc.). En segundo lugar, es mucho más rápido de implementar que un sistema de módulo asincrónico basado en dependencias más sofisticado, y el ciclo de vida del desarrollo es una consideración importante (ver el mantra de la oficina de Opbeat * (contiene vulgaridad)).
msanford
"incluso si lo envía como una solicitud POST normal, existen otras herramientas que pueden capturar fácilmente estos datos". ¿Seguramente su formulario de inicio de sesión está protegido por HTTPS ?
ajlane
@ajlane sí, mi inicio de sesión (y en realidad, toda la aplicación) se ejecutará detrás de HTTPS
ryanzec

Respuestas:

18

Presumiblemente es para ahorrar cargar un montón de activos del lado del cliente (como marcos de JavaScript pesados, imágenes, etc. ) que solo son requeridos por la aplicación.

Existen medios más sofisticados para lograr un objetivo de rendimiento similar (consulte " Malte Ubl y John Hjelmstad: un enfoque novedoso y eficiente para la carga de JavaScript: JSConf EU 2012 "), pero esto es bastante rápido de implementar y posiblemente igual de eficiente, especialmente si su aplicación web usa casi todos sus activos de todos modos.

Puede ver esto en la naturaleza en un sitio como http://infogr.am beta:

  1. http://infogr.am/login/ carga jquery , raphael , js personalizados y 3 archivos css.
  2. http://infogr.am/beta/ (la página principal de SPI para la aplicación) carga 10 frameworks javascript, 5 archivos css externos y alrededor de 60 imágenes.
msanford
fuente
Actualización: en 2016 con angular2 front-end y un back-end de JBoss, seguimos haciendo esto por la misma razón.
msanford
18

Creo que hay algunos argumentos razonables a favor o en contra, y diría que la tecnología también juega un papel en la decisión.

Se podría argumentar que tener una "página" de inicio de sesión separada permite el uso de "Seguridad de directorio". Generalmente, cualquiera puede ver la "página" de inicio de sesión, pero solo los usuarios autenticados pueden ver la "página" de la aplicación y su "directorio". Las rutas también se pueden bloquear, donde / Account / es diferente de / App / y cada una tiene su propio "perfil" de seguridad.

Además, si utiliza un enfoque SPA y combina la autenticación con la experiencia de la aplicación, la lógica podría complicarse. En lugar de suponer que el usuario está "conectado porque está aquí", debe verificar constantemente su estado de autenticación y preguntar "si este usuario está aquí".

Además, la página de inicio de sesión generalmente se encuentra en el sitio orientado al consumidor. Vaya a www.yourapp.com y tiene información acerca de información, contacto, soporte, etc. y una página de "inicio de sesión". autenticación, puede redirigir a una gran cantidad de objetivos ..

La razón por la que mantengo una página de inicio de sesión separada y la razón por la que realmente tengo una aplicación completamente diferente para mi sitio "orientado al consumidor" es porque puedo exponer muy poco a los no autenticados. Por casualidad, algún idiota comienza a golpear mi página de inicio de sesión, no quiero que eso afecte el lado de la aplicación de las cosas ... incluso si el inicio de sesión solo está haciendo una simple búsqueda de autenticación ... me ayuda a evitar que los bozo afecten mi experiencia de los usuarios ... En el peor de los casos, mi sitio de consumidor deja de funcionar y nadie puede iniciar sesión, pero al menos los usuarios registrados no lo sabrán y su experiencia no comenzará a disminuir ... No estoy diciendo que esa sea la opción a prueba de balas ... pero al menos He aislado el riesgo para el área no autenticada.

hanzolo
fuente
1
La seguridad es a menudo una gran razón.
JustinC
1
@JustinC: ¿explicarme en una página separada para iniciar sesión de forma más segura?
ryanzec
No necesariamente a través de los atributos del sistema de archivos (pero puede ser si eso es lo que exige la situación), sino el contenedor de aplicaciones web / software de servlet / tiempo de ejecución mediante la aplicación de métodos selectivos de autenticación / autorización aplicados a un recurso específico o a un grupo de recursos en su conjunto (en términos prácticos, un directorio): para la página de inicio de sesión y recursos estáticos particulares (imágenes, hojas de estilo, páginas de error), el acceso anónimo es a menudo suficiente; para otras páginas, se puede requerir una autenticación / autorización más particular.
JustinC
2
La autenticación fuera de la aplicación aísla la autenticación de ser una preocupación de la aplicación. La seguridad real dependerá de la implementación y la tecnología
hanzolo
actualización 2017: IdentityServer
hanzolo
10

Una razón para hacerlo es porque puede usar sesiones normales basadas en cookies. El usuario inicia sesión, la respuesta envía una cookie junto con la página principal inicial ... y luego todas las llamadas ajax posteriores envían la cookie al servidor.

Gran maestro B
fuente
6

Veo algunas razones para hacer esto:

  1. Puedo usar reglas de control de acceso basadas en rutas normales en web.xml.
  2. Nunca puedo estar seguro de haber protegido toda mi aplicación Ajax correctamente, y necesito hacer pruebas exhaustivas para tener confianza.
  3. Puedo delegar la autenticación a un marco (como Spring Security), una aplicación de terceros o una solución SSO (como CAS o JOSSO).
  4. Puedo dejar que el navegador almacene el nombre de usuario y (opcionalmente) las contraseñas para el usuario.
n0rm1e
fuente