autenticación de aplicación web dojo

Question

Estoy intentando desarrollar una aplicación web javascript pura usando Dojo. El problema al que me enfrento es restringir el acceso a partes de la aplicación. Los usuarios autenticados deberían poder acceder a todo, mientras que los usuarios no autenticados solo deberían poder acceder a una pantalla de inicio de sesión.

El problema es que nada (que yo sepa) impedirá que un usuario abra un terminal de JavaScript del navegador e ingrese algo como: app.displayRestrictedContent(); y así obtenga acceso a una pantalla destinada a usuarios autenticados.

He implementado un inicio de sesión basado en ajax; todas las llamadas ajax están aseguradas con una sesión. Por lo tanto, aunque el usuario no autenticado puede cargar una pantalla restringida, no podrá obtener datos para ella. Pero aún así, parece incorrecto que esta pantalla sea arbitrariamente accesible.

¿Estoy tratando de hacer lo imposible? Parece absurdo escribir código como if (user.auth) app.displayRestrictedContent(); cuando se lo burla fácilmente. Y esto me lleva a creer que me falta algo bastante obvio para todos los demás. No puedo encontrar mucha información en aplicaciones puras basadas en JavaScript y modelos de autenticación.

Answer 1

Estoy de ninguna manera un experto, pero aquí están algunas ideas que he hecho en este. No creo que te hayas perdido nada (si es así, yo también) - Creo que este es un problema bastante fundamental con todas las aplicaciones cliente, ya sea un ejecutable compilado o un Javascript.

Por supuesto, el ejecutable compilado no se ve obstaculizado por esto, ya que se ha convertido en código de máquina que es muy difícil de leer o descompilar en algo útil. Sin embargo, con Javascript, la aplicación a menudo se sirve exactamente como la escribiste, por lo que es fácil modificarla y razonar sobre ella.

Eso me lleva a la primera semi-solución: ofuscación de su Javascript. Si usa la herramienta de compilación de Dojo con el parámetro de reducción de seguridad, se eliminan todos los espacios en blanco innecesarios y se acortan todos los identificadores, lo que hace que el código sea bastante difícil de leer. Llamé a esto una semi-solución, algunos pueden decir que incluso eso le está dando demasiado crédito; yo mismo todavía creo que vale la pena hacerlo. ¡Después de todo, el código reducido también se descarga más rápido!

La segunda medida que tomo en mis aplicaciones es separar las diferentes partes en "capas de construcción". Por ejemplo, en el perfil de construcción, voy a tener algo así como

dependencies = { 
    .. 
    layers: [ 
     { name: "../myApp/Core.js", resourceName: "myApp.Core", 
      dependencies: ["myApp.Core", "myApp.Foobar"] 
     }, 
     { name: "../myApp/modules/Login.js", resourceName: "myApp.modules.Login", 
      dependencies: ["myApp.modules.Login", "myApp.modules.LoginUi"...], 
      layerDependencies: ["../myApp/Core.js"] 
     }, 
     { name: "../myApp/modules/Secret.js", resourceName: "myApp.modules.Secret", 
      dependencies: ["myApp.modules.Secret", "myApp.modules.SecretUi"], 
      layerDependencies: ["../myApp/Core.js"], 
      authentication: 42 
     } 
    ] 
} 

Ahora, en lugar de servir a los archivos JS construidas directamente como archivos estáticos, dejo que las peticiones pasan por un controlador en mi aplicación del lado del servidor, que comprueba si la capa JS requiere autenticación y si el usuario ha iniciado sesión con el acceso necesario.

Esto tiene ciertas desventajas. Los archivos JS no están en la memoria caché, y si tuviera todos mis JS en una capa de compilación, la aplicación probablemente cargaría un poco más rápido.Por supuesto, también hay un límite sobre la cantidad de matices que vale la pena hacer las capas. Más capas significan más problemas, pero también un acceso a los módulos más fino.

Estaría interesado en escuchar a otros entrar en esto también. Es una buena pregunta.

Answer 2

Cuando un usuario inicia sesión correctamente en el servidor, debe proporcionarle un token de sesión . Posteriormente, cada vez que el usuario solicita un recurso (ya sea simplemente redireccionando el navegador o AJAX) muestra al servidor su token de sesión (ya sea almacenándolo en una cookie y enviándolo automáticamente a todas las solicitudes o pasándolo explícitamente en el cuerpo) de una solicitud AJAX)

El servidor puede usar tokens de sesión de los usuarios para controlar las autorizaciones del lado del servidor, rechazando cualquier solicitud con un token inválido u obsoleto.

https://en.wikipedia.org/wiki/HTTP_cookie#Session_management

Answer 3

But still, It seems wrong for this screen to be arbitrarily accessible. 

Porque es el código del lado del cliente. Cualquier cosa que escriba en js, o compilada en js, espera que los usuarios la puedan leer.

Am I trying to do the impossible? 

puede cargar dinámicamente los módulos js después de que el usuario se autentique. Entonces, al principio, solo carga 1 módulo de inicio de sesión. Cuando el usuario inicia sesión, si tiene éxito, el servidor devuelve una lista de módulos js para cargar, si no, devuelve la lista vacía. También ayuda a mejorar el tiempo de carga cuando los usuarios visitan su sitio web.