¿Cuál es el método preferido para la autentificación de usuarios de una página web de una manera REST?

Question

Estoy desarrollando un nuevo marco de aplicaciones web experimental, y decidió darle un poco de atención REST. He leído en los fundamentos, y siento que tengo una muy buena comprensión de REST como concepto.

Tengo un sistema en funcionamiento, el uso de URL para definir estrictamente '' sustantivos en el sistema y tomar los verbos '' de los métodos de la petición HTTP. Estoy usando javascript, ajax llama para proporcionar acceso a la DELETE y PUT métodos que los formularios HTML no pueden proporcionar. (Me doy cuenta de que estas medidas no son estrictamente necesarios para ser REST, pero satisface los requerimientos de la 'Uniforme Interfaz').

El problema viene con sin estado-dad y cacheability con autenticación. El modelo estándar para la autenticación de usuario en los sitios web implica un evento de "entrada" de autenticación, después de lo cual (si tiene éxito) un usuario está "dentro de la pared" con una sesión segura persistente y puede ver y hacer las cosas en las solicitudes posteriores que los usuarios no autenticados no. Esta persistencia de autenticación parece romper REST-dad. El almacenamiento en caché y la apatridia parecen no estar funcionando, ya que el usuario autenticado verá probablemente HTML que es diferente de la que un usuario no autenticado verá por la misma petición (por ejemplo, puede haber un formulario de acceso en una barra lateral para la iniciada una sesión usuario fuera).

El uso de estrategias de autenticación WWW para autenticar a un usuario sólo en las solicitudes que requieren autenticación parece ser un paso en la dirección correcta, ya que no implica el concepto de una sesión segura persistente. Sin embargo aún existe la pregunta de cómo retratar una "revisión en línea" apariencia para el usuario final de acuerdo con lo que todos hemos llegado a esperar de los sitios web.

Así que en el pensamiento actual, ¿cuál es la mejor forma de controlar la autenticación y para conceder permiso de una página web de una manera estrictamente REST, al tiempo que permite para las decoraciones que has iniciado sesión en el código HTML?

Answer 1

  

Esta persistencia de la autenticación   parece romper REST-dad

En lugar de la autenticación de un usuario, puede pensar en crear una sesión. Volverá un nuevo "ID de sesión", junto con el código de estado HTTP apropiado (200: OK, 403: Prohibido, etc).

  

El usuario es probable que vea que es HTML   diferente de la que una   no autenticados usuario verá para   la misma petición

Se le pide su servidor REST: "¿Me puede conseguir el HTML (o cualquier recurso) para este ID de sesión?". El código HTML será diferente basado en el "ID de sesión".

Con este método, no hay pared en "sesiones de seguros persistentes". Simplemente está actuando en una sesión.

El sustantivo (o recurso) representarían el la sesión actual, si se opta por este método.

Answer 2

"El modelo estándar para la autenticación de usuario en los sitios web implica un '' evento de autenticación, después de lo cual (si tiene éxito) es un usuario 'Inicio de sesión dentro de la pared' con una sesión segura persistente"

1. Esto no es realmente correcto. En parte es cierto, pero sólo para los sitios web que inventar su propia autenticación.

2. Si se utiliza "la autenticación implícita" el navegador debe enviar las credenciales con cada solicitud.

La autenticación implícita - credenciales con cada solicitud. - es totalmente REST

hacer eso.

Para hacer las cosas un poco más ágil, se puede calcular la síntesis de autenticación Nonce basado en el tiempo por lo que es bueno para un cierto período de tiempo (6 minutos, 0,1 h es bueno). Todo el mundo unos minutos una solicitud enviarán un estado 401 y requieren recálculo del digerido.

Answer 3

Una opción para preservar cachability en intermediarios para las páginas con elementos específicos del usuario es añadir el marcado específico del usuario a través de Ajax. Usted sirve cada uso la misma página, incluyendo algo de JavaScript que va a hacer una solicitud XHR a un recurso que devuelve algo diferente en base a la conexión del usuario. A continuación, combinar esto en la página en el lado del cliente. La mayor parte de la página será entonces cachable ya que es la misma para todos los usuarios.

Otra opción es usar ESI (Incluye borde lateral). Con éstos, el propio caché puede fusionar diferentes representaciones para construir el resultado final.

Answer 4

pienso en ello como esto: El "nombre" en la autenticación de usuarios es una sesión. Por lo que su formulario de acceso utiliza una solicitud POST para "crear" una nueva sesión y cerrar la sesión utiliza una solicitud DELETE para "eliminar" la sesión.

Yo sé lo que quiere decir por la persistencia de la autenticación de ir en contra de sosiego, pero las galletas (que dan la ilusión de persistencia) son simplemente una parte de cada solicitud.

Answer 5

"Esta persistencia de autenticación parece romper REST-dad. El almacenamiento en caché y la apatridia parecen no estar funcionando, ya que el usuario autenticado verá probablemente HTML que es diferente de la que un usuario no autenticado verá por la misma petición"

Está bien si la representación del recurso es ligeramente diferente en función de la información de autenticación. La información de autenticación es parte del mensaje y, por tanto, el mensaje sigue siendo "auto-descriptivo". Conceptualmente todavía se está accediendo a un mismo recurso, y el editar y eliminar los enlaces se les permite transiciones, y no piezas adicionales de datos. Controlar lo que se dispone de transiciones en función de quién tiene acceso al recurso parece válido para mí.

Answer 6

Re: La respuesta de Daniel:

Si una sesión es un objeto transitorio que consigue rápidamente eliminado, esto no es muy cachable, como cualquier caché que crear sólo tendría una vida útil de tal vez un día, sino también seguir utilizando el espacio en la memoria caché de todos modos.

¿No sería mejor para crear el usuario como un objeto, y autenticar usando la autenticación implícita, (o una galleta si es necesario). de esa manera, cada usuario tiene su propia caché persistente en lugar de una caché que tiene una duración de un día y desaparece.

Esto también tiene sentido más lógico para mí, ya que usted está haciendo una página de aspecto diferente dependiendo del usuario, (añadiendo 'hola [nombre]' y tal) y la diferencia entre el "conectado" y "Desconectado "Unidos depende de si el usuario está incluido en la URL. Si una persona particular, se concede el acceso a la URL específica del usuario depende de si pueden autenticarse como ese usuario.

Answer 7

Si su marco REST sólo va a ser utilizado por la aplicación web, y no será usado como un API para terceros, no veo ninguna razón por la que no puede utilizar el mismo esquema de autenticación como el resto de su aplicación. Se podría pensar en esta autenticación como una capa de nivel inferior al nivel de "aplicación". El nivel de aplicación todavía puede permanecer sin estado en una forma pura REST.

Por supuesto, si usted está planeando crear una API REST Web, tendrá que dar a este pensamiento más.