API服务是否应该发送用户激活电子邮件或客户端应用程序?

use*_*736 17 api rest activation

我正在尝试开发REST API Web服务.我有一个关于如何处理用户激活电子邮件的问题.目前,API服务处理电子邮件发送.

这是我目前的流程:

  1. 用户通过客户端应用程序注册
  2. 客户端应用程序POST到API服务
  3. API服务验证并将用户添加到数据库
  4. API服务向用户发送激活链接
  5. 用户单击激活链接,将其带到客户端应用程序激活页面
  6. 客户端应用程序激活页面POST到API服务
  7. 完成

这是我目前看到的问题:

由于API服务当前正在发送电子邮件,因此客户端应用程序无法控制电子邮件的外观.并且电子邮件中可能存在应指向客户端应用程序的URL.


另一个选项是发送激活电子邮件的API服务,它将激活密钥返回给客户端应用程序.然后,客户端应用程序将能够将激活电子邮件发送给用户.

我在这个策略中看到两个问题:

  • 安全性,因为激活密钥现在公开给客户端应用程序.
  • 不干,因为每个客户都可以负责电子邮件发送.

你认为最好的办法是什么?

我想允许客户端应用程序自定义他们的电子邮件,以及包含客户端特定的URL(激活页面).

nau*_*tur 11

TL; DR

为开发人员创建一个小型服务来创建模板,让他们在POST到您的激活API时声明他们想要使用哪个模板


问题摘要:

  • 每个客户端应用程序的电子邮件需要看起来不同
  • 发送邮件应该实施一次
  • 解决方案应该是安全的

电子邮件不需要每次都看起来不同.因此,无需使用POST请求发送电子邮件格式.

而是可以完成以下任一操作:

1创建单独的API端点以定义模板,并让客户端应用程序在POST激活请求时选择其中一个.

这并不完全安全,如果您想要从客户端应用程序接受HTML,至少会带来一些挑战.

推荐解决方案

2为开发人员(在获取其API密钥的同一网站中)创建一个工具,该工具接受创建它们的模板和辅助工具.在发布激活请求时,客户端应用可以选择其中一个.请求正文的片段是这样的:

...
"template": "foobar-app",
"fields": {
    "title": "Welcome to foobar app",
    "username": "jim78"
}
...
Run Code Online (Sandbox Code Playgroud)

允许的字段中没有HTML.

这使您可以使用开发人员准备的预定义模板,这些模板可供您的电子邮件发送服务使用,客户端应用程序中的任何错误都不会导致电子邮件变得不安全.此外,您还可以获得可以处理和测试模板的位置.(开发人员可以将它们发送给自己进行调试 - 制作电子邮件模板非常糟糕,相信我)

您将来能够更好地支持您的开发人员/客户,并准备在多个邮件客户端中测试的一组工作模板.