RESTful скидання пароля

Який правильний спосіб структурувати ресурс RESTful для скидання пароля?

Цей ресурс призначений для скидання пароля для тих, хто втратив або забув свій пароль. Це визнає недійсним їхній старий пароль та надсилає їм електронний лист.

У мене є два варіанти:

POST /reset_password/{user_name}

або ...

POST /reset_password
   -Username passed through request body

Я майже впевнений, що запит має бути POST. Я менш впевнений, що вибрав відповідне ім’я. І я не впевнений, чи слід ім’я користувача переходити через URL-адресу чи орган запиту.

ОНОВЛЕННЯ: (далі коментар нижче)

Я б хотів щось подібне:

POST /users/:user_id/reset_password

У вас є колекція користувачів, де окремого користувача визначає {user_name}. Потім ви б вказали дію, над якою діяти, яка в даному випадку є reset_password. Це як би сказати "Створити ( POST) нову reset_passwordдію для {user_name}".

Попередня відповідь:

Я б хотів щось подібне:

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

У вас буде дві колекції, колекція користувачів та колекція атрибутів для кожного користувача. Користувача вказує :user_idатрибут, а атрибут визначає password. PUTОперація оновлює адресованих елементів колекції.

Неавторизовані користувачі

Ми робимо PUTзапит у api/v1/account/passwordкінцевій точці та вимагаємо параметр із відповідною електронною поштою облікового запису для ідентифікації облікового запису, для якого користувач хоче скинути (оновити) пароль:

PUT : /api/v1/account/password?email={email@example.com}

Примітка. Як згадував @DougDomeny у своєму коментарі, передача електронної пошти як рядка запиту в URL- адресі є ризиком для безпеки. Параметри GET не піддаються впливу під час використання https(і ви завжди повинні використовувати належне httpsз'єднання для таких запитів), але є інші ризики безпеки. Більше про цю тему ви можете прочитати в цій публікації в блозі тут .

Передача електронної пошти в орган запиту була б більш безпечною альтернативою передачі її як параметр GET:

PUT : /api/v1/account/password

Орган запиту:

{
    "email": "email@example.com"
}

Відповідь має 202прийняте значення відповіді:

Запит прийнято для обробки, але обробка не завершена. Зрештою на цей запит не може бути застосовано, оскільки це може бути заборонено, коли обробка фактично відбувається. Немає можливості повторного надсилання коду стану з асинхронної операції, такої як ця.

Користувач отримає електронний лист на адресу email@example.comта обробка запиту на оновлення залежить від дій, здійснених із посиланням з електронного листа.

https://example.com/password-reset?token=1234567890

Відкриття посилання з цього електронного листа направить на форму скидання пароля на додатковому додатку, який використовує маркер пароля скидання з посилання як вхід для прихованого поля введення (маркер є частиною посилання як рядок запиту). Ще одне поле введення дозволяє користувачеві встановити новий пароль. Другий вхід для підтвердження нового пароля буде використаний для перевірки на передній панелі (щоб запобігти помилкам друку).

Примітка: В електронному листі ми також можемо зазначити, що у випадку, якщо користувач не ініціалізує скидання пароля, він / вона може ігнорувати електронну пошту та продовжувати користуватися програмою, як правило, своїм поточним паролем

Коли форма подається з новим паролем та маркер як вхід, відбудеться процес скидання пароля. Дані форми будуть надсилатись із PUTзапитом ще раз, але на цей раз, включаючи маркер, і ми замінимо пароль ресурсу на нове значення:

PUT : /api/v1/account/password

Орган запиту:

{
    "token":"1234567890",
    "new":"password"
}

Відповідь буде 204не зміст відповіді

Сервер виконав цей запит, але йому не потрібно повертати тіло об'єкта і, можливо, захоче повернути оновлену інформацію. Відповідь МОЖЕ включати нову або оновлену метейнформацію у вигляді заголовків сутностей, які, якщо вони є, ОБОВ'ЯЗКОВО бути пов'язані із запитуваним варіантом.

Автентифіковані користувачі

Для аутентифікованих користувачів, які хочуть змінити свій пароль, PUTзапит можна виконати негайно без електронної пошти (обліковий запис, на який ми оновлюємо пароль, відомий серверу). У такому випадку у форму надсилаються два поля:

PUT : /api/v1/account/password

Орган запиту:

{
    "old":"password",
    "new":"password"
}

Давайте отримаємо uber-RESTful на секунду. Чому б не застосувати дію DELETE для пароля, щоб викликати скидання? Має сенс, чи не так? Зрештою, ви ефективно відкидаєте існуючий пароль на користь іншого.

Це означає, що ви зробите:

DELETE /users/{user_name}/password

Тепер два великих застереження:

1. HTTP DELETE повинен бути ідентичним (фантастичне слово для того, щоб сказати "нічого не робити, якщо ви зробите це кілька разів"). Якщо ви робите стандартні речі, такі як надсилання електронного листа "Скидання пароля", то у вас виникнуть проблеми. Ви можете обійти це позначення користувача / пароля булевим прапором "Скидання". При кожному видаленні ви перевіряєте цей прапор; якщо він не встановлений , то ви можете скинути пароль і відправити по електронній пошті. (Зверніть увагу, що наявність цього прапора може мати й інші потреби.)

2. Ви не можете використовувати HTTP DELETE через форму , тому вам доведеться здійснити дзвінок AJAX та / або тунель ВИДАЛИТИ через пошту.

Часто ви не хочете видаляти або знищувати існуючий пароль користувача при первинному запиті, оскільки це, можливо, було спровоковано (ненавмисно або навмисно) користувачем, який не має доступу до електронної пошти. Натомість оновіть маркер пароля для запису користувача та надішліть його у посиланні, включеному в електронний лист. Натиснувши на посилання, підтвердите, що користувач отримав маркер і побажав оновити свій пароль. В ідеалі це також буде залежно від часу.

Дією RESTful у цьому випадку буде POST: запуск дії створення на контролері PasswordResets. Сама дія дозволила б оновити маркер і надіслати електронний лист.

Я насправді шукаю відповідь, не маючи сенсу надати її, але "reset_password" звучить для мене неправильно в контексті REST, оскільки це дієслово, а не іменник. Навіть якщо ви говорите, що робите іменник "скидання дії" - використовуючи це виправдання, всі дієслова є іменниками.

Крім того, хтось, хто шукає ту саму відповідь, може не прийти в голову, що ви можете отримати ім'я користувача через контекст безпеки, і не доведеться надсилати його через URL або тіло взагалі, що мене нервує.

Я думаю, що кращою ідеєю було б:

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)

Щодо надання даних:

• Щоб скинути поточний пароль

  • електронну пошту потрібно вказати на тілі.

• Щоб створити новий пароль (після скидання)

  • новий пароль, код активації та emailID повинні бути вказані в корпусі.

• Оновити пароль (для користувача, що ввійшли в систему)

  • старий пароль, новий пароль слід згадати в корпусі.
  • UserId в Парамах.
  • Auth Token у заголовках.

Потрібно взяти до уваги кілька міркувань:

Скидання пароля не є ідентичним

Зміна пароля впливає на дані, які використовуються як облікові дані для його виконання, що може призвести до недійсності майбутніх спроб, якщо запит буде повторно дослівно повторений, тоді як збережені облікові дані будуть змінені. Наприклад, якщо тимчасовий маркер скидання використовується для дозволу зміни, як це прийнято в ситуації забутого пароля, цей маркер повинен бути закінчений після успішної зміни пароля, що знову зводить нанівець подальші спроби реплікації запиту. Таким чином, здається, що RESTful підхід до зміни пароля є роботою, яка краще підходить для, POSTніжPUT .

Ідентифікатор або електронна пошта при завантаженні даних, ймовірно, зайві

Хоча це не проти REST і може мати якусь особливу мету, часто не потрібно вказувати ідентифікатор або електронну адресу для скидання пароля. Подумайте над тим, чому б ви надали адресу електронної пошти як частину даних запиту, який повинен пройти автентифікацію так чи інакше? Якщо користувач просто змінює свій пароль, для цього потрібно пройти автентифікацію (через ім’я користувача: пароль, електронну пошту: пароль або маркер доступу, наданий через заголовки). Отже, ми маємо доступ до їх облікового запису з цього кроку. Якби вони забули свій пароль, їм було б надано тимчасовий маркер скидання (електронною поштою), який вони можуть використовувати конкретно як облікові дані для внесення змін. І в цьому випадку автентифікації через маркер має бути достатньо для ідентифікації їх облікового запису.

Беручи до уваги все вищесказане, ось що я вважаю правильною схемою зміни RESTful пароля:

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

У мене не було б чогось змінити пароль і надіслати їм новий, якщо ви вирішите використовувати метод / users / {id} / password, і дотримуйтесь вашої думки, що запит - це власний ресурс. тобто / користувач-пароль-запит / - це ресурс і використовується PUT, інформація про користувача повинна бути в тілі. Я б не змінив пароль, я надсилаю електронному листу користувачеві повідомлення, яке містить посилання на сторінку, яка містить request_guid, яку можна передати разом із запитом на POST / user / {id} / password /? Request_guid = ххххх

Це дозволить змінити пароль, і це не дозволяє комусь дозволити користувачеві за допомогою шлангу, вимагаючи зміни пароля.

Плюс початковий PUT може не вдатися, якщо є непогашений запит.

Ми оновлюємо пароль користувача PUT / v1 / users / password - ідентифікуємо ідентифікатор користувача за допомогою AccessToken.

Обміняти ідентифікатор користувача не безпечно. API Restful повинен ідентифікувати користувача, використовуючи AccessToken, отриманий у заголовку HTTP.

Приклад у весняному завантаженні

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