Reposant réinitialisation de mot de passe

Quelle est la bonne façon de structurer une bonne ressource pour la réinitialisation d'un mot de passe?

Cette ressource est destinée à être un mot de passe resetter pour quelqu'un qui a perdu ou oublié leur mot de passe. Il permet d'invalider leur ancien mot de passe, e-mails et leur mot de passe.

Les deux options que j'ai sont:

POST /reset_password/{user_name}

ou...

POST /reset_password
   -Username passed through request body

Je suis sûr que la demande devrait être un POST. Je suis moins confiant que j'ai choisi un nom approprié. Et je ne suis pas sûr si le user_name doit être transmis par le biais de l'URL ou le corps de la requête.

InformationsquelleAutor Chris Dutrow | 2010-06-19

password-recovery rest

48

Mise à JOUR: (plus de commentaire ci-dessous)

Je voudrais aller quelque chose comme ceci:
```
POST /users/:user_id/reset_password
```
Vous avez une collection de l'utilisateur, où le seul utilisateur est spécifié par le {user_name}. Vous devez ensuite spécifier l'action à opérer, qui dans ce cas est reset_password. C'est comme de dire "Créer (POST) une nouvelle reset_password d'action pour {user_name}".

Réponse précédente:

Je voudrais aller quelque chose comme ceci:
```
PUT /users/:user_id/attributes/password
    -- The "current password" and the "new password" passed through the body
```
Vous auriez deux collections, les utilisateurs de la collection, et une collection d'attributs pour chaque utilisateur. L'utilisateur est spécifié par le :user_id et l'attribut est spécifié par password. Le PUT fonctionnement des mises à jour de la membre de la collection.
- Cette ressource est destinée à réinitialiser le mot de passe pour quelqu'un qui a perdu ou oublié leur mot de passe. J'ai précisé ci-dessus.
- Oh, désolé... mal compris... la mise à Jour de ma réponse.
- Tout est bien, je devrais avoir été plus clair.
- Ouais, c'est mieux que ce que j'avais, je vais devoir re-facteur de la façon dont je suis la structuration de certaines de ces ressources.
- Je suis d'accord avec votre mise à jour (POST) solution. METTRE les demandes doivent être idempotent (c'est à dire les demandes répétées ne devraient pas influer sur les résultats). Ce n'est pas le cas avec les requêtes POST.
- Je ne pense pas que cette réponse est correcte. reset_password contient un verbe. Selon le REPOS, les ressources ne peut être constituée que de noms.
- Je voudrais changer reset_password à password_reset
- Je l'appelle /user/{id}/password/reset. Cependant, je suis toujours en pensant entre celle-ci et /user/password/reset. /user/password/reset nécessite de post first_name & email pour compléter la demande.
- Accrocher les gars...ne serait-ce pas essentiellement de permettre à QUICONQUE de réinitialisation de mot de passe de quelqu'un? Comme, si c'est pour quelqu'un qui oublie le mot de passe actuel, l'utilisateur concerné ne peut pas être authentifié avec le mot de passe actuel. Donc, essentiellement, cela signifie que cette API ne pouvait pas accepter un mot de passe à tous - permettant ainsi à quiconque de réinitialisation de mot de passe de quelqu'un, et si l'API retourne, même mettre la main sur des connus de l'utilisateur mot de passe??? Ou ai-je raté quelque chose
- Voir des Sabres de réponse ci-dessous pour une description de la bonne façon de le faire. Si la demande de réinitialisation de mot de passe a été initié par accident ou par quelqu'un d'autre que l'utilisateur, l'e-mail peut être simplement ignoré.
- Le problème avec /utilisateurs/{id}/mot de passe et l'aime, c'est que vous ne pouvez pas savoir à l'utilisateur de "id". Vous connaissez leur "nom d'utilisateur" ou "e-mail" ou "téléphone", mais pas "id".
- Quel serait le code de réponse - 200? Ou 201, comme de "nouvelles ressources" ont été créés?
- Le vice fondamental de cette approche est qu'il suppose que vous connaissez déjà le nom d'utilisateur. Ce sera vrai dans certaines circonstances, mais comment vous le faites, puis quand le nom d'utilisateur ou id d'utilisateur n'est pas connu si l'utilisateur a seulement besoin de spécifier un e-mail pour le réinitialiser.
- qu'en est POST /users/{username}/password/reset ?
- Si votre nom d'utilisateur est votre utilisateurs identifiant unique, qui devrait fonctionner tout aussi bien, mais, habituellement, le nom d'utilisateur est plus simple et plus URL-friendly
- pourquoi password_reset au lieu de reset_password ?
InformationsquelleAutor Daniel Vassallo
57

Les utilisateurs non authentifiés

Nous faire un PUT demande sur un api/v1/account/password d'extrémité et nécessitent un paramètre correspondant à un compte e-mail pour identifier le compte pour lequel l'utilisateur veut reset (mise à jour) le mot de passe:
```
PUT : /api/v1/account/password?email={[email protected]}
```
Remarque: Comme @DougDomeny mentionné dans son commentaire sur le passage de l'e-mail comme une chaîne de requête dans l'url est un risque pour la sécurité. OBTENIR les paramètres ne sont pas exposés lors de l'utilisation de https (et vous devriez toujours utiliser un bon https de connexion pour ces demandes), mais il existe d'autres risques de sécurité impliqués. Vous pouvez en lire plus sur ce sujet dans ce billet de blog ici.

Passant à l'e-mail dans le corps de la requête serait un plus sûres que les passant comme un param:
```
PUT : /api/v1/account/password
```
Du corps de la requête:
```
{
    "email": "[email protected]"
}
```
La réponse a un 202 accepté réponse signification:

La demande a été acceptée pour le traitement, mais le traitement n'a pas été achevée. La demande pourrait ou ne pourrait pas éventuellement être suivies, comme il peut être supprimée lorsque le traitement a lieu. Il n'y a pas de possibilité de ré-envoi d'un code d'état d'une opération asynchrone comme cela.

L'utilisateur recevra un e-mail à [email protected] et de traitement de la demande de mise à jour dépend des mesures prises avec le lien de l'email.
```
https://example.com/password-reset?token=1234567890
```
À l'ouverture du lien de cet email direct à une réinitialisation du formulaire de mot de passe sur le front-end de l'application qui utilise le jeton de réinitialisation de mot de passe à partir du lien comme entrée pour un champ caché (le jeton est en partie le lien, comme une chaîne de requête). Un autre champ de saisie permet à l'utilisateur de définir un nouveau mot de passe. Une deuxième entrée pour confirmer le nouveau mot de passe sera utilisé pour la validation sur le front-end (pour éviter les fautes de frappe).

Remarque: Dans le courriel que nous pourrions aussi mentionner que dans le cas où l'utilisateur n'a pas initialiser toute réinitialisation de mot de passe, il/elle peut ignorer la messagerie et de continuer à utiliser l'application normalement avec son mot de passe actuel

Lorsque le formulaire est envoyé avec le nouveau mot de passe et le jeton comme entrées la réinitialisation du mot de passe d'un procédé. Les données du formulaire sera envoyé avec un PUT demande à nouveau, mais cette fois, y compris le jeton et nous allons remplacer la ressource mot de passe avec une nouvelle valeur:
```
PUT : /api/v1/account/password
```
Du corps de la requête :
```
{
    "token":"1234567890",
    "new":"password"
}
```
La réponse sera un 204 pas de contenu réponse

Le serveur a satisfait à la demande, mais n'a pas besoin de retourner une entité-corps, et pourrait vouloir retourner à jour de la métainformation. La réponse PEUT inclure de nouveaux ou mis à jour de la métainformation dans la forme de l'entité en-têtes, qui si elle est présente, DOIT être associé à la demande de la variante.

Utilisateurs authentifiés

Pour les utilisateurs authentifiés qui veulent changer leur mot de passe PUT demande peut être effectuée immédiatement, sans l'e-mail (le compte pour lequel nous mettons à jour le mot de passe est connu pour le serveur). Dans de tels cas, le formulaire de soumission de deux champs:
```
PUT : /api/v1/account/password
```
Du corps de la requête:
```
{
    "old":"password",
    "new":"password"
}
```
- Dans votre premier paragraphe, vous dire, mais l'exemple ci-dessous indique les SUPPRIMER. Ce qui est exact?
- MIS est correct. J'ai mis à jour la réponse.
- Ce n'exposer l'adresse e-mail sur l'adresse, ce qui serait plus sûr d'une des données JSON.
- Oui, l'envoi de l'email en tant que données json serait probablement mieux. J'ai ajouté ceci à la réponse comme une alternative plus sûre option, sinon la solution peut être le même.
- Ne serait-ce pas une opération de PATCH ? MIS a besoin pour envoyer les ressources
- Bon point. Lors de l'écriture de ce que je pensais serait mieux, mais je ne me souviens pas exactement pourquoi. Je suis d'accord avec votre raisonnement, que le patch pourrait être plus approprié pour ce cas.
- J'ai une question similaire ici. Vous pouvez prendre un coup d'oeil - stackoverflow.com/questions/45140940/... C'est juste il ya plusieurs attributs qui peuvent être modifiés
- dans votre réponse pour la réinitialisation du mot de passe vous suggérons de fournir un lien dans l'e-mail qui contient le jeton comme param URL. Toutes les préoccupations w/le jeton comme un param URL? Je demande parce que je pensais à fournir un bouton dans l'email que lorsque l'utilisateur clique dessus permettrait de générer une requête au serveur, mais j'ai été préoccupé par l'envoi de Jeton comme param URL raison de ramifications de sécurité (par exemple, les paramètres ne sont pas chiffrés). Tout simplement pas sûr de la façon de retourner un Jeton de toute autre manière que comme param URL à partir d'un courriel. Pensées? De sécurité? Comment envoyer jeton de retour dans le corps à l'aide de "bouton e-mail approche"?
- L'ajout d'un jeton à un lien dans un e-mail est de pratique courante pour les fonctionnalités telles que la réinitialisation de mot de passe, récupération de compte, etc. De nombreux webservices l'utilisation d'une telle solution. Le jeton doit être randomisés et ont une certaine longueur minimale (de la force), et pour augmenter la sécurité, il est recommandé d'expirer après un laps de temps raisonnable (c'est à dire une heure), ce qui signifie un nouveau lien de réinitialisation du mot de passe (avec un nouveau jeton) doit être demandé. Le jeton peut être utilisé qu'une seule fois et sera également invalidé après l'utilisation. Le lien fourni doit être demandé via une connexion sécurisée (doit être un lien https).
- merci pour la réponse. Je suis d'accord que c'est une pratique courante. Cependant, mon souci (si je ne me trompe), c'est que le simple ajout du jeton comme un paramètre de l'URL désigne le jeton sera envoyé en texte clair et peut être intercepté par des pirates et en théorie utilisée réinitialiser le mot de passe AVANT que l'utilisateur a la possibilité de l'utiliser...Ma compréhension est que d'une connexion https ne pas encoder les paramètres d'URL. Faire le jeton en une fois et de le donner et le temps d'expiration est utile mais il n'est pas complètement éliminer le risque, si le jeton est envoyé en texte clair (comme un param url). Pensées?
- https ne chiffrer les chaînes de requête, mais il est livré avec d'autres risques de sécurité qui sont mentionnés dans ce post. C'est bien le seul moyen d'obtenir ces données à un utilisateur à l'intérieur d'un e-mail pour autant que je sais. Si vous avez une autre solution, je serais heureux d'en entendre parler. Vous pouvez bien sûr augmenter la sécurité par l'ajout d'une validation en deux étapes de ce processus (envoyer un autre code de vérification à l'utilisateur son/son téléphone avant de permettre de définir un nouveau mot de passe).
InformationsquelleAutor Wilt
17

Let's get uber-Sommeil pendant une seconde. Pourquoi ne pas utiliser l'action de SUPPRESSION de mot de passe pour déclencher une réinitialisation? De sens, n'est-ce pas? Après tout, vous êtes effectivement à rejeter le mot de passe existant en faveur d'une autre.

Cela signifie que vous feriez:
```
DELETE /users/{user_name}/password
```
Maintenant, deux gros bémols:
1. HTTP SUPPRIMER est censé être idempotent (un bien grand mot pour dire "pas grand-chose si vous le faites plusieurs fois"). Si vous faites de la norme des choses comme l'envoi d'une "Réinitialisation du Mot de passe e-mail, puis vous allez rencontrer des problèmes. Vous pouvez travailler autour de ce marquage de l'utilisateur/mot de passe avec un booléen "Réinitialisation" du pavillon. Sur tous les supprimer, vous vérifiez ce drapeau; si elle n'est pas définie puis vous pouvez réinitialiser le mot de passe et envoyer votre e-mail. (Notez que d'avoir ce drapeau peut avoir d'autres usages aussi.)
2. Vous ne pouvez pas utiliser HTTP SUPPRIMER par le biais d'un formulaire, de sorte que vous aurez à faire un appel AJAX et/ou le tunnel de la SUPPRIMER par la POSTE.
- Idée intéressante. Cependant je ne vois pas DELETE côté bien ici. Vous seriez en substituant le mot de passe généré de façon aléatoire, j'imagine, de sorte DELETE pourrait être trompeuse. Je préfère le Create (POST) new reset_password action, d'où le nom de la (des ressources) vous seriez en agissant sur le "reset_password action". Cela correspond bien, pour l'envoi des e-mails ainsi, étant donné que l'action est un condensé de tous ces éléments de bas niveau. POST n'est pas idempotent.
- J'aime la proposition. Question 1, pourrait être traitée en utilisant des requêtes conditionnelles, c'est à dire de la TÊTE qui envoie ETag + SUPPR et Si le Match de l'en-tête. Si quelqu'un essaie de supprimer un mot de passe qui n'est plus actif, il va se faire un 412.
- Je voudrais éviter de les SUPPRIMER. Vous êtes à la mise à jour, depuis la même entité/concept permettra d'obtenir une nouvelle valeur. Mais en fait, habituellement, il n'est même pas qui se passe maintenant, mais seulement après l'envoi d'un nouveau mot de passe plus tard dans un autre demande (après une réinitialisation de mot de passe de messagerie) - aujourd'Hui, personne n'envoie un nouveau mot de passe par mail, mais un jeton de réinitialisation dans une nouvelle requête avec un jeton, non?
- Que faire si l'utilisateur se souvient de son mot de passe juste après avoir fait une demande de réinitialisation? Les bot essayer de réinitialiser aléatoire des comptes? L'utilisateur doit être autorisé à ignorer l'e-mail de réinitialisation dans de tels cas (l'e-mail de le dire), ce qui signifie que votre système ne devrait pas supprimer ou mettre à jour les mots de passe par lui-même.
- C'est un très bon point. Vraiment, vous êtes "la Création d'une Demande de Réinitialisation", qui serait un POST.
InformationsquelleAutor Craig Walker
11

Souvent vous ne voulez pas supprimer ou de détruire de l'utilisateur mot de passe existant sur la demande initiale, car cela peut avoir été déclenchée (accidentellement ou intentionnellement) par un utilisateur qui n'a pas accès à l'e-mail. Au lieu de cela, la mise à jour d'un jeton de réinitialisation de mot de passe sur l'enregistrement de l'utilisateur et envoyer un lien figurant dans un e-mail. En cliquant sur le lien de confirmer que l'utilisateur a reçu le jeton et souhaite mettre à jour leur mot de passe. Idéalement, ce serait temps aussi bien sensibles.

Le repos de l'action dans ce cas serait un POST: le déclenchement de l'action de création sur le contrôleur PasswordResets. L'action elle-même permettrait de mettre à jour le jeton et l'envoyer un e-mail.

InformationsquelleAutor Mark Swardstrom
8

Je suis actuellement à la recherche d'une réponse, pas de sens de lui donner, mais "reset_password" sonne mal à m'en RESTE contexte, car c'est un verbe, pas un nom. Même si vous dites que vous êtes en train de faire une "remise à zéro" nom - à l'aide de cette justification, tous les verbes sont des substantifs.

Aussi, il peut ne pas avoir lieu à une personne à la recherche pour la même réponse que vous pouvez être en mesure d'obtenir le nom d'utilisateur à travers le contexte de sécurité, et ne pas avoir à l'envoyer par le biais de l'url ou le corps, ce qui me rend nerveux.
- Peut-être reset-password sonne comme un verbe, mais vous pouvez facilement l'inverser (password-reset) pour en faire un nom. Et si vous avez modélisé votre application en utilisant l'Event Sourcing ou même si vous avez n'importe quel type de l'audit, il est logique que tu avais fait un véritable entité de ce nom, et peut même permettre de prend sur elle pour les utilisateurs ou les administrateurs de l'histoire (évidemment masquant le texte de mot de passe). Ne me rend pas nerveux du tout. Et comme pour la récupération du nom d'utilisateur automatiquement sur le côté serveur - vous pouvez, mais alors, comment gérez-vous les choses comme l'administration et de l'usurpation d'identité?
- Il n'y a rien de mal à utiliser des verbes en RESTE. Aussi longtemps qu'il est utilisé dans les endroits appropriés. Je pense que c'est plus un controller qu'un resorce, et reset-password gérer pour décrire les effets bien.
InformationsquelleAutor orbfish
5

Je pense que la meilleure idée serait:
```
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)
```
Concernant la fourniture de données:
- Pour réinitialiser votre mot de passe actuel
  - e-mail doit être donnée dans le corps.
- Pour créer un nouveau mot de passe (après un reset)
  - nouveau mot de passe, code d'activation et emailID devrait être accordée dans le corps.
- De mettre à jour le mot de passe (pour loggedIn utilisateur)
  - ancien mot de passe, le nouveau mot de passe doit être mentionné dans le corps.
  - UserId dans Params.
  - Auth Jeton dans les en-têtes.
- Comme indiqué dans d'autres réponses, "SUPPRIMER /api/v1/compte/mot de passe" est une mauvaise idée, qu'on peut réinitialiser le mot de passe de quelqu'un.
- Nous avons besoin d'une adresse e-mail pour réinitialiser le mot de passe. Les chances de connaître l'e-mail de l'Id d'utilisateur inconnu est très sombre, à moins que nous sommes à l'exécution d'un site comme Facebook et ont des tonnes d'e-mails IDENTIFIANT recueillis par tout moyen. Ensuite, les politiques de sécurité seront définis en conséquence. Quelle est votre suggestion pour réinitialiser le mot de passe de quelqu'un?
InformationsquelleAutor codesnooker
3

Il ya quelques considérations à prendre:

Réinitialisations de mot de passe ne sont pas idempotent

Un changement de mot de passe affecte les données utilisées comme informations d'identification pour l'exécuter, ce qui pourrait invalider les futures tentatives si la demande est simplement répété mot à mot, tandis que les informations d'identification stockées ont changé. Par exemple, si un temporaire token est utilisé pour permettre le changement, comme il est d'usage, dans un mot de passe oublié situation, ce jeton doit être expiré lors du changement de mot de passe, ce qui annule toute nouvelle tentative de réplication de la demande. Donc une bonne approche pour un changement de mot de passe semble être un travail mieux adapté pour POST que PUT.

IDENTIFIANT ou e-mail dans le chargement des données est probablement redondant

Bien que ce n'est pas contre le REPOS et peut avoir certaines fins particulières, il est souvent inutile de spécifier un ID ou une adresse email pour réinitialiser votre mot de passe. Pensez-y, pourquoi vous fournir l'adresse de courriel comme une partie des données à une demande qui est censé passer par l'authentification d'une manière ou d'une autre? Si l'utilisateur est simplement en train de changer leur mot de passe dont ils ont besoin pour s'authentifier dans le but de le faire (via nom d'utilisateur:mot de passe, e-mail:mot de passe, ou jeton d'accès fournis via les en-têtes). Par conséquent, nous avons accès à leur compte à partir de cette étape. Si ils avaient oublié leur mot de passe, ils auraient été fourni avec un temporaire de token (via email) qu'ils peuvent utiliser expressément que les informations d'identification pour effectuer le changement. Et dans ce cas, l'authentification par jeton doit être suffisante pour identifier leur compte.

Compte tenu de tous les ci-dessus en considération, ici est ce que je crois être le bon régime pour un séjour Reposant changement de mot de passe:
```
Method: POST
url: /v1/account/password
Access Token (via headers): pwd_rst_token_b3xSw4hR8nKWE1d4iE2s7JawT8bCMsT1EvUQ94aI
data load: {"password": "This 1s My very New Passw0rd"}
```
- Une déclaration qu'un espace réservé nécessite out-of-band de l'information n'est pas complètement vrai. Une spéciale type de média peut décrire la syntaxe et de la sémantique de certains éléments de la demande ou de la réponse. Il est ainsi possible pour un type de média à définir que l'URI contenues dans un certain domaine peut définir l'espace réservé pour certaines données et la sémantique de mieux définir qu'un encodées par l'utilisateur e-mail ou ce qui devrait être inclus au lieu de l'espace réservé. Les Clients et les serveurs respectant le fait que le type de support sera toujours conforme à la RESTful principes d'architecture.
- Concernant POST vs PUT RFC 7231 spécifie qu'une mise à jour partielle peut être obtenue par le chevauchement des données de deux ressources, mais il est douteux si quelque chose comme /v1/account/password ne font vraiment de place pour une bonne ressource en fait. Comme POST est la suisse de l'armée-kniff du Web qui peut être utilisée si aucune des autres méthodes sont possibles, compte tenu de PATCH peut aussi être un choix pour mettre le nouveau mot de passe.
- que dire de l'URL pour demander la réinitialisation de mot de passe quand ils ne savent pas leur mot de passe?
InformationsquelleAutor Michael Ekoka
2

Je n'aurais pas quelque chose qui change le mot de passe et de les envoyer en un nouveau si vous décidez d'utiliser le dossier /utilisateurs/{id}/mot de passe de la méthode, et s'en tenir à votre idée que la demande est une ressource qui lui est propre. ie /utilisateur-mot de passe-demande/est la ressource, et permet de METTRE, les infos de l'utilisateur doit être dans le corps.
Je ne voudrais pas changer le mot de passe si, Id envoyer un courriel à l'utilisateur qui contient un lien vers une page qui contient un request_guid, qui pourraient être passés avec une demande de POST /utilisateurs/{id}//mot de passe?request_guid=xxxxx

Qui allait changer le mot de passe, et il ne permet pas à quelqu'un tuyau d'un utilisateur en demandant un changement de mot de passe.

Avec les premiers MIS peut échouer si il y a une demande en suspens.

InformationsquelleAutor bpeikes
0

Nous mettons à Jour connecté Mot de passe utilisateur
METTRE /v1/utilisateurs/mot de passe - identifier l'id de l'utilisateur à l'aide de AccessToken.

Elle n'est pas sécurisée pour l'échange de l'id d'utilisateur. L'API Restful doit identifier l'utilisateur à l'aide de AccessToken reçu en en-tête HTTP.

Exemple au printemps-boot
```
@putMapping(value="/v1/users/password")
public ResponseEntity<String> updatePassword(@RequestHeader(value="Authorization") String token){
/* find User Using token */
/* Update Password*?
/* Return 200 */
}
```
InformationsquelleAutor Dan

Vous devez vous connecter pour publier un commentaire.

Les utilisateurs non authentifiés

Utilisateurs authentifiés

Réinitialisations de mot de passe ne sont pas idempotent

IDENTIFIANT ou e-mail dans le chargement des données est probablement redondant