RESTful регистрация с активационным письмом
Я работаю над созданием REST API, и одна из функций — разрешить пользователям регистрироваться. Общий поток следующий:
- Пользователь указывает свою электронную почту и пароль с помощью клиентского приложения (SPA-приложения) и нажимает кнопку отправки.
- Делается запрос к API. API добавляет пользователя в базу данных, генерирует токен подтверждения и отправляет пользователю электронное письмо.
- Пользователь подтверждает свою электронную почту и нажимает ссылку подтверждения.
- API помечает учетную запись пользователя как проверенную.
Мой вопрос касается ссылки подтверждения. Должна ли ссылка указывать на клиентское приложение SPA? В этом случае клиентское приложение отправит запрос POST к API с токеном подтверждения и адресом электронной почты пользователя. Кроме того, как API должен знать ссылку на клиентское приложение (ссылку нужно добавить в письмо, и это делает API). Должен ли API хранить эту ссылку или клиент SPA должен отправлять ссылку для подтверждения в API при отправке запроса на регистрацию пользователя?
Другой подход заключается в том, чтобы ссылка шла к конечной точке, определенной API. В этом случае будет сделан запрос GET с адресом электронной почты пользователя и токеном подтверждения, и API установит учетную запись как проверенную и сообщит пользователю, что его учетная запись теперь активна. Я читал, что этот подход не соответствует принципам REST, потому что запрос GET никогда не должен изменять состояние ресурса. В этом случае пользовательский ресурс будет изменен.
Я не уверен, какое из двух решений лучше или есть лучшее решение, поэтому мой вопрос в том, какой подход лучше всего?
Спасибо!
Ответы 1
Should the link point to the client SPA application?
Если ваше «Клиентское SPA-приложение» является единственным интерфейсом для конечных пользователей, тогда да: оно должно указывать на него. Некоторые люди развертывают отдельный сервер oauth2/аутентификации, но это не похоже на то, что здесь.
The client application will make a POST request to the API with the verification token and the user email.
Токена должно хватить. Я бы не стал отправлять адреса электронной почты через URL-адреса.
Also, how should the API know the link to the client application (the link needs to be added in the email and this is done by the API). Should the API store this link, or should the SPA client send the verification link to the API when sending the request to register the user?
Оба кажутся действительно правильными конструкциями. Если вы хотите, чтобы API совершенно не знал о внешнем интерфейсе и поддерживал множество внешних интерфейсов, мне было бы разумно, чтобы клиент отправлял свои собственные конечные точки. Однако существует проблема безопасности: вы не хотите, чтобы произвольные клиенты регистрировали произвольные URL-адреса.
Если вы просто создаете один интерфейс, я не вижу проблемы в том, что API знает URL-адрес активации. Также кажется, что это будет легко изменить, если ваши требования изменятся позже.
I'm not sure which of the 2 solutions is better or if there is a better solution, so my question is what is the best approach?
В конце концов, это не так уж и важно. Ни один из подходов не звучит так, будто вы действительно загоняете себя в угол. Либо у вас есть стандартная конечная точка, которая использует HTTP-запрос javascript для активации пользователя, либо отдельная конечная точка, которая перенаправляет пользователя после активации. Оба будут работать.