Пароль RESTful reset и подтвердите адрес электронной почты

Ответ 1

Если вы хотите, чтобы ваши URI ссылались на ресурсы, затем вызывайте подтверждения ресурса confirmation и POST в учетные записи пользователей.

POST /users/{userid}/confirmation

Ответ 2

Истинный ответ RESTful - это URL-адрес не имеет значения, вы все равно помещаете его в подтверждение электронной почты для получателя. Используйте то, что наиболее удобно для вашего балансировщика нагрузки, обратного прокси-сервера, серверов и т.д.

Для удобства вы в конце концов получите подтверждение, даже если оно поступит в запрос GET, потому что то, что браузеры из плоти и костей люди не обращают внимания на доктора Роя Т. Филдинга и др. отправить при нажатии на ссылку по электронной почте: -)

Установив, что он полностью академичен, я бы сказал, что вы правы, думая о PUT, так как клиент идемпотентно указывает на наличие доступа к электронной почте. Повторение запроса не имеет никакого эффекта.

Ответ 3

Учитывая, что он сказал услугу reset для кого-то, кто забыл свой пароль, а не для службы паролей изменений для уже зарегистрированного пользователя...

Я бы использовал 2 службы. 1, чтобы запросить почту пароля reset, а второй - установить новый пароль с маркером, полученным в полученной почте.

Для первого:
POST baseUrl/passwordReset
Тело запроса

{
   "email" : "[email protected]"
}

Это может быть POST или PUT, но поскольку доставка почты не является ресурсом, подпадающим под действие CRUD, пусть не будет педантичным и использует старый POST, который всегда использовался в html-формах.

Очевидно, я бы контролировал, что один и тот же клиент (ip? browser?...) не заставляет меня отправлять 20 тыс. писем через минуту.

Отправка почты пользователю не означает, что старый пароль недействителен. Это произойдет только во втором запросе, когда новый обновит его.

Ответ 204 (возможно, вам стоит это сделать, даже если вы не знаете этого письма, потому что если вы вернете ошибку, это означает, что когда вы не возвращаете ошибку, вы подтверждаете незнакомцу, что данное письмо зарегистрировано)

Для второго:
POST baseUrl/пароль
Тело запроса

{
    "token" : "3D21BA...4F",
    "newPassword" : "m%4pW1!O"
}

Если маркер получен по почте. Таким образом, почта может иметь ссылку на страницу, включая токен, когда страница загружается, форма заполняется и отправляется, являясь маркером скрытого поля, которое некоторые javascript читает из URL-адреса и помещает здесь.

Это действительно ресурс, который вы обновляете, поэтому POST. И я не думаю, что имеет смысл иметь один и тот же URI с двумя глаголами для обоих, потому что они не являются одним и тем же ресурсом/сущностью вообще.

Добавить Кстати, я бы сделал только HTTPS, и поэтому я поместил всю важную информацию в тело, а не параметры URL.

Ответ 4

Во-первых, я не думаю, что PUT - правильный метод для этого. PUT в широком смысле означает "поместить это здесь", где URL-адрес идентифицирует, где должен находиться контент. Вы действительно просите существующий ресурс выполнить какое-то действие, что делает POST более правильным.

Чтобы ответить на ваш прямой вопрос, URL-адрес RESTful должен идентифицировать ресурс, который вы хотите обработать вашим запросом. В этом случае ресурс является либо пользователем, либо некоторым ресурсом сброса пароля у пользователя.

Мое предпочтение было бы для ресурса сброса пароля:

POST /users/{userid}/password-reset

Это имеет смысл с точки зрения HTTP, поскольку вы можете выпустить GET на ресурс и получить что-то, что указывает на действие пароля reset (например, в форме HTML, запрашивающей адрес электронной почты связанного счет).

EDIT:

Для проверки подлинности электронной почты существуют два очевидных варианта. Вы можете либо POST на ресурс "подтвердить электронную почту" с адресом электронной почты и данными подтверждения, чтобы попросить сервер обработать подтверждение, либо вы можете выполнить PUT, чтобы разместить информацию о подтверждении на сервере:

POST /users/{userid}/confirm-email

или

PUT /users/{userid}/email-confirmation

Ответ 5

Вот путь RESTful.

Запрос

PUT /{userid}/email HTTP/1.1
Content-Type: text/json+confirmation-code

{"activateCode": "23sfgsg3twt3rgsdhgs"}

ответ

HTTP/1.1 200 OK
Content-Type: text/json+email-status
{"email": "[email protected]", "active": "true"}

Никаких глаголов в URI не требуется:)

Ответ 6

Я не вижу ничего плохого в том, что у меня есть подтверждениеEmail, как в первом примере. В URL-адресе у вас есть ключ к пользователю, confirmEmail - это действие, а данные с этим действием находятся в строке запроса.

Ответ 7

Недавно я работал над этим, мой прием был

POST /{base_url}/password

потому что я фактически создавал новый случайный пароль и отправлял его пользователю

и

PUT /{base_url}/confirmation?token=...

Поскольку я обновляю подтверждение, которое уже было отправлено, когда пользователь зарегистрировался.