这是我的场景。想象一下,有一个瑜伽工作室使用专业的预订和预订系统,公开API。通过此API,应用程序可以为客户端进行预订。API使用客户端的用户ID和密码进行预订。预订API不使用OAuth或任何社交媒体登录。
我的愿望是创建一个助理操作,它将检索类的列表,并允许客户进行预订。
我的困惑是,为了提供预订API所需的用户ID/密码对,应该采用什么设计/架构。
其他人是如何解决这个难题的?
我应该将用户ID/密码存储为"吗;用户状态";与行动相关?
首先,您应该与API提供商进行对话,讨论他们为什么不提供基于OAuth的解决方案。这是一个等待发生的安全漏洞,如果它还没有发生的话。
其次,您需要非常仔细地思考在这种情况下您自己的风险状况:
-
Google不允许您通过Action收集凭据信息(即密码(。
-
因此,必须使用帐户链接对其进行身份验证。
-
这意味着你需要一些东西(即数据库或数据存储(来管理他们在你这边的帐户。
- 这个数据库将是一个很好的地方,可以保存API所需的用户名/密码
- 。。。但现在这意味着您需要非常小心地保护这个数据库
您并没有真正说明此API如何允许创建和管理帐户。如果这些帐户只是为您使用(即用户不一定会看到它们(,那么您可以通过将用户名/密码视为您管理和生成的不透明令牌来减轻一些风险,而用户永远不会看到。
如果用户知道这一点,那么您需要通过以下两种方式之一来联系帐户:
- 让他们使用您需要保存的凭据信息(ack!(通过应用程序或网络应用程序登录您的服务,然后使用OAuth链接到助手
- 让他们使用谷歌登录通过应用程序或网络应用程序登录您的服务,这将转到您的行动。然后让他们提供API的凭据信息,您需要保存这些信息(ack!(