RESTful регистрация по электронной почте для активации - PullRequest
Новая
       21

RESTful регистрация по электронной почте для активации

0 голосов
/ 06 апреля 2019

Я работаю над созданием API REST, и одна из функций - позволить пользователям регистрироваться. Общий поток выглядит следующим образом:

  1. Пользователь указывает свой адрес электронной почты и пароль с помощью клиентского приложения (SPA-приложения) и нажимает кнопку отправки.
  2. Сделан запрос к API. API добавляет пользователя в базу данных, генерирует токен подтверждения и отправляет пользователю электронное письмо.
  3. Пользователь проверяет свою электронную почту и нажимает ссылку для подтверждения.
  4. API помечает учетную запись пользователя как проверенную.

Мой вопрос касается ссылки для подтверждения. Должна ли ссылка указывать на клиентское приложение SPA? В этом случае клиентское приложение отправит API-запрос POST с токеном проверки и электронной почтой пользователя. Кроме того, как API должен знать ссылку на клиентское приложение (ссылка должна быть добавлена ​​в электронное письмо, и это делается API). Должен ли API хранить эту ссылку или клиент SPA должен отправить ссылку на подтверждение API при отправке запроса на регистрацию пользователя?

Другим подходом будет ссылка на конечную точку, определенную API. В этом случае будет сделан запрос GET с электронной почтой пользователя и токеном проверки, и API установит учетную запись как проверенную и сообщит пользователю, что его учетная запись активна. Я читал, что этот подход не соответствует принципам REST, потому что запрос GET никогда не должен изменять состояние ресурса. В этом случае пользовательский ресурс будет изменен.

Я не уверен, какое из 2-х решений лучше или есть лучшее решение, поэтому мой вопрос: какой подход лучше?

Спасибо!

1 Ответ

0 голосов
/ 06 апреля 2019

Должна ли ссылка указывать на клиентское приложение SPA?

Если ваше «клиентское SPA-приложение» является единственным интерфейсом для конечных пользователей, тогда да: оно должно указывать на это. Некоторые люди используют отдельный сервер oauth2 / для проверки подлинности, но это не так, как здесь.

Клиентское приложение отправит POST-запрос к API с токеном проверки и электронной почтой пользователя.

Токена должно быть достаточно. Я бы не стал отправлять адреса электронной почты через URL.

Кроме того, как API должен знать ссылку на клиентское приложение (ссылка должна быть добавлена ​​в электронном письме, и это делается API). Должен ли API хранить эту ссылку или клиент SPA должен отправить ссылку на подтверждение API при отправке запроса на регистрацию пользователя?

Оба выглядят как настоящие проекты. Если вы хотите, чтобы API полностью не знал о внешнем интерфейсе и поддерживал множество внешних интерфейсов, для меня будет иметь смысл, что клиент отправляет свои собственные конечные точки. Однако существует проблема безопасности: вы не хотите, чтобы произвольные клиенты регистрировали произвольные URL.

Если вы просто создаете один интерфейс, я не вижу проблем с API, который знает URL-адрес активации. Это также звучит так, как будто это будет легко изменить, если ваши требования изменятся позже.

Я не уверен, какое из 2-х решений лучше или есть лучшее решение, поэтому мой вопрос - какой подход лучше?

В конечном счете, это не так уж важно. Ни один из подходов не звучит так, будто вы действительно загоняете себя в угол. Либо у вас есть стандартная конечная точка, которая использует HTTP-запрос javascript для активации пользователя, либо у вас есть отдельная конечная точка, которая перенаправляет пользователя после активации. Оба будут работать.

...