RESTful сбросить пароль и подтвердить электронную почту

Question

я думаю, что это лучший способ RESTful, как подтвердить электронную почту и запросить сброс пароля.Я только стремлюсь найти правильный URI ...

подтвердить электронную почту

PUT /users/{userId}/confirmEmail?code=xyz - кажется, не слишком RESTful из-за verifyEmail

PUT /users/{userId}/email?confirmedBy=xyz - может быть, лучше?не знаю

сброс пароля (похожая проблема)

PUT /users/{userId}/resetPassword --DATA {email:xyz@xyz.xy} - то же, что и раньше

PUT /users/{userId}/password --DATA {state:reseted,resent:xyz@xyz.xy} - хммм ... опять я не уверен

Есть ли у тебя лучшие способы? -)

Answer 1

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

POST /users/{userid}/confirmation

Answer 2

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

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

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

Answer 3

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

Я бы использовал 2 услуги. Во-первых, чтобы запросить пароль для сброса пароля, и во-вторых, чтобы установить новый пароль с токеном, полученным в полученном письме.

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

{
   "email" : "my@self.com"
}

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

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

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

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

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

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

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

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

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

Answer 4

Вот способ 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": "my-email@address.com", "active": "true"}

Нет глаголов внужен URI:)

Answer 5

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

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

Я бы предпочел ресурс сброса пароля:

POST /users/{userid}/password-reset

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

EDIT:

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

POST /users/{userid}/confirm-email

или

PUT /users/{userid}/email-confirmation

Answer 6

Я недавно работал над этим, мой дубль был

POST /{base_url}/password

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

и

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

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

Answer 7

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