phone - RESTful contraseña restablecer

recover password en español

Question

¿Cuál es la forma correcta de estructurar un recurso RESTful para restablecer una contraseña?

Este recurso está destinado a ser un restablecimiento de contraseña para alguien que ha perdido u olvidado su contraseña. Invalida su contraseña anterior y les envía una contraseña por correo electrónico.

Las dos opciones que tengo son:

POST /reset_password/{user_name}

o...

POST /reset_password
-Username passed through request body

Estoy bastante seguro de que la solicitud debe ser un POST. Estoy menos seguro de haber seleccionado un nombre apropiado. Y no estoy seguro de si el user_name se debe pasar a través de la URL o el cuerpo de la solicitud.

Answer 1

Usuarios no autenticados

Realizamos una solicitud PUT en un punto final de la api/v1/account/password y solicitamos un parámetro con el correo electrónico de la cuenta correspondiente para identificar la cuenta para la cual el usuario desea restablecer (actualizar) la contraseña:

PUT : /api/v1/account/password?email={[email protected]}

Nota: Como @DougDomeny se menciona en su comentario al pasar el correo electrónico como una cadena de consulta en la url es un riesgo de seguridad. Los parámetros GET no están expuestos al usar https (y siempre debe usar una conexión https adecuada para tales solicitudes), pero existen otros riesgos de seguridad involucrados. Puede leer más sobre este tema en esta publicación de blog aquí .

Pasar el correo electrónico en el cuerpo sería una alternativa más segura para pasarlo como un parámetro GET:

PUT : /api/v1/account/password
data : {
"email": "[email protected]"
}

La respuesta tiene un significado de respuesta 202 aceptado :

La solicitud se ha aceptado para su procesamiento, pero el procesamiento no se ha completado. Eventualmente se puede actuar sobre la solicitud o no, ya que podría no autorizarse cuando el procesamiento realmente tenga lugar. No hay ninguna posibilidad de volver a enviar un código de estado de una operación asíncrona como esta.

El usuario recibirá un correo electrónico a [email protected] y el procesamiento de la solicitud de actualización depende de las medidas tomadas con el enlace en el correo electrónico. El correo electrónico contiene un enlace a un formulario de restablecimiento de contraseña con un token de contraseña de restablecimiento como cadena de consulta.

Cuando el formulario se envía con una nueva contraseña y el token como entradas, se lleva a cabo el proceso de restablecer la contraseña. Los datos del formulario se enviarán nuevamente con una solicitud PUT pero esta vez incluyendo el token y reemplazaremos la contraseña del recurso con un nuevo valor:

PUT : /api/v1/account/password?
data : {
"token":"1234567890",
"new":"password"
}

La respuesta será una respuesta de 204 sin contenido

El servidor ha cumplido la solicitud pero no necesita devolver un cuerpo de entidad, y puede querer devolver metainformación actualizada. La respuesta PUEDE incluir metainformación nueva o actualizada en forma de encabezados de entidad, que de estar presentes DEBERÍAN asociarse con la variante solicitada.

Usuarios autenticados

Para los usuarios autenticados que desean cambiar su contraseña, la solicitud PUT puede realizarse inmediatamente sin el correo electrónico (el servidor conoce la cuenta para la que estamos actualizando la contraseña). En tal caso, el formulario presentará dos campos:

PUT : /api/v1/account/password?
data : {
"old":"password",
"new":"password"
}

Answer 2

A menudo no desea eliminar o destruir la contraseña existente del usuario en la solicitud inicial, ya que esto puede haber sido desencadenado (involuntaria o intencionalmente) por un usuario que no tiene acceso al correo electrónico. En su lugar, actualice un token de contraseña de restablecimiento en el registro del usuario y envíelo en un enlace incluido en un correo electrónico. Al hacer clic en el enlace se confirmará que el usuario recibió el token y desea actualizar su contraseña. Idealmente, esto también sería sensible al tiempo.

La acción RESTful en este caso sería un POST: desencadenando la acción de creación en el controlador PasswordResets. La acción en sí actualizaría el token y enviaría un correo electrónico.

Answer 3

Actualizamos la contraseña del usuario registrado PUT / v1 / users / password - identifica la identificación del usuario usando AccessToken.

No es seguro intercambiar la identificación de usuario. La API Restful debe identificar al usuario que utiliza AccessToken recibido en el encabezado HTTP.

Ejemplo en arranque de resorte

@putMapping(value="/v1/users/password")
public ResponseEntity<String> updatePassword(@RequestHeader(value="Authorization") String token){
/* find User Using token */
/* Update Password*?
/* Return 200 */
}

Answer 4

Creo que una mejor idea sería:

DELETE /api/v1/account/password - To reset the current password (in case user forget the password)
POST /api/v1/account/password - To create new password (if user has reset the password)
PUT /api/v1/account/{userId}/password - To update the password (if user knows is old password and new password)

En cuanto al suministro de los datos:

• Para restablecer la contraseña actual

  • el correo electrónico debe ser entregado en el cuerpo.

• Para crear una nueva contraseña (después del reinicio)

  • nueva contraseña, código de activación e ID de correo electrónico deben darse en el cuerpo.

• Para actualizar la contraseña (para usuarios registrados)

  • contraseña anterior, nueva contraseña debe mencionarse en el cuerpo.
  • UserId en Params.
  • Auth Token en los encabezados.

Answer 5

De hecho, estoy buscando una respuesta, sin intención de proporcionarla, pero "reset_password" me suena mal en un contexto REST porque es un verbo, no un sustantivo. Incluso si dices que estás haciendo un nombre de "acción de reinicio", con esta justificación, todos los verbos son sustantivos.

Además, puede que no se le haya ocurrido a alguien que busca la misma respuesta que usted puede obtener el nombre de usuario a través del contexto de seguridad, y no tener que enviarlo a través de la url o el cuerpo en absoluto, lo cual me pone nervioso.

Answer 6

Hay algunas consideraciones a tomar:

Los restablecimientos de contraseña no son idempotentes

Un cambio de contraseña afecta los datos utilizados como credenciales para realizarlo, lo que como resultado podría invalidar los intentos futuros si la solicitud simplemente se repite al pie de la letra mientras las credenciales almacenadas han cambiado. Por ejemplo, si se usa un token de restablecimiento temporal para permitir el cambio, como es habitual en una situación de contraseña olvidada, ese token debería caducar al cambiar la contraseña con éxito, lo que anula nuevamente los intentos de replicar la solicitud. Por lo tanto, un enfoque RESTful para un cambio de contraseña parece ser un trabajo más adecuado para POST que PUT .

Las URL con marcadores de posición ID no son RESTful

Un recurso que se especifica como /password-reset/{user_id} implica que la url real que apunta al recurso debe construirse con información fuera de banda (es decir, necesitamos tener conocimiento previo de user_id ), no adquirida a través de descubrimiento. Además supone que tendremos acceso a esa información en el momento de la solicitud, que en muchas situaciones no será el caso.

La identificación o el correo electrónico en la carga de datos probablemente sea redundante

Aunque eso no está en contra de REST y puede tener algún propósito especial, a menudo no es necesario especificar una ID o dirección de correo electrónico para restablecer la contraseña. Piénselo, ¿por qué debería proporcionar la dirección de correo electrónico como parte de los datos a una solicitud que se supone debe pasar por la autenticación de una forma u otra? Si el usuario simplemente está cambiando su contraseña, necesita autenticarse para poder hacerlo (a través de nombre de usuario: contraseña, correo electrónico: contraseña o token de acceso proporcionado a través de encabezados). Por lo tanto, tenemos acceso a su cuenta desde ese paso. Si olvidaron su contraseña, se les habría proporcionado un token de restablecimiento temporal (por correo electrónico) que pueden usar específicamente como credenciales para realizar el cambio. Y en este caso, la autenticación mediante token debería ser suficiente para identificar su cuenta.

Teniendo en cuenta todo lo anterior, aquí está lo que creo que es el esquema adecuado para un cambio de contraseña RESTful:

El usuario conoce su contraseña:

Method: POST
url: /v1/account/password
Auth (via headers): [email protected]:my 0ld pa55wOrd
data load: {"password": "This 1s My very New Passw0rd"}

El usuario no conoce su contraseña (restablecimiento de contraseña por correo electrónico):

Method: POST
url: /v1/account/password
Access Token (via headers): pwd_rst_token_b3xSw4hR8nKWE1d4iE2s7JawT8bCMsT1EvUQ94aI
data load: {"password": "This 1s My very New Passw0rd"}

Answer 7

No tengo algo que cambie la contraseña y les envíe una nueva si decides utilizar el método / users / {id} / contraseña, y me atengo a tu idea de que la solicitud es un recurso propio. es decir, / user-password-request / es el recurso, y es usar PUT, la información del usuario debe estar en el cuerpo. Sin embargo, no cambiaría la contraseña, Id enviará un correo electrónico al usuario que contiene un enlace a una página que contiene un request_guid, que podría pasarse junto con una solicitud a POST / user / {id} / password /? Request_guid = xxxxx

Eso cambiaría la contraseña, y no permite que alguien manguera a un usuario solicitando un cambio de contraseña.

Además, el PUT inicial podría fallar si hay una solicitud pendiente.

Answer 8

Vamos a ponernos súper-RESTful por un segundo. ¿Por qué no utilizar la acción DELETE para la contraseña para activar un restablecimiento? Tiene sentido, ¿no? Después de todo, está efectivamente descartando la contraseña existente a favor de otra.

Eso significa que harías:

DELETE /users/{user_name}/password

Ahora, dos grandes advertencias:

1. Se supone que HTTP DELETE es idempotente (una palabra elegante para decir "no es gran cosa si lo haces varias veces"). Si está haciendo las cosas estándar como enviar un correo electrónico de "Restablecimiento de contraseña", entonces se encontrará con problemas. Podría solucionar este etiquetado del usuario / contraseña con un indicador booleano "Is Reset". En cada eliminación, marque esta bandera; si no está configurado, puede restablecer la contraseña y enviar su correo electrónico. (Tenga en cuenta que tener esta bandera también podría tener otros usos).

2. No puede usar HTTP DELETE a través de un formulario , por lo que deberá realizar una llamada AJAX y / o tunelizar el DELETE a través del POST.

Answer 9

ACTUALIZACIÓN: (más adelante para comentar a continuación)

Me gustaría ir por algo como esto:

POST /users/:user_id/reset_password

Tiene una colección de usuarios, donde el usuario único está especificado por {user_name} . Luego, debe especificar la acción para operar, que en este caso es reset_password . Es como decir "Crear ( POST ) una nueva acción reset_password para {user_name} ".

Respuesta anterior:

Me gustaría ir por algo como esto:

PUT /users/:user_id/attributes/password
-- The "current password" and the "new password" passed through the body

Tendría dos colecciones, una colección de usuarios y una colección de atributos para cada usuario. El usuario está especificado por :user_id y el atributo se especifica mediante password . La operación PUT actualiza al miembro direccionado de la colección.