8

我正在构建一个移动应用程序和一个 ServiceStack Web 服务后端。ServiceStack 中的 Authentication 东西看起来很棒，但很容易迷失在它的灵活性中——非常感谢指导。我将使用我自己的数据库表在 Web 服务中存储用户等。我想要一个注册过程和随后的身份验证，如下所示：

  • 用户最初只提供一个电子邮件地址，然后我的网络服务通过电子邮件将注册密钥发送给用户
  • 用户输入密钥。应用程序发送到网络服务进行注册：电子邮件、密钥和唯一的设备标识符。
  • Web 服务验证密钥并存储电子邮件和设备 ID。它使用应用程序将用于以后的身份验证的身份验证令牌进行响应。

然后后续的 Web 服务请求将提供设备 ID 和身份验证令牌（或使用它创建的哈希）。该应用程序不是很健谈，因此我很想在每个 Web 请求上发送身份验证详细信息。

问题 1：我应该挂钩到 ServiceStack 的注册 API 还是只添加几个自定义 Web 服务调用？例如，如果不使用 ServiceStack 的注册，我会：

  • 使用电子邮件地址和设备 ID 发布到注册 Web 服务。我的 Web 服务将发送带有密钥的注册电子邮件并将记录添加到用户 db 表中。
  • 当用户输入密钥时，它会再次发布到注册 Web 服务，这次也是使用密钥。我的 Web 服务将验证密钥并更新将用户标记为已注册的用户表，创建并记录身份验证令牌并将其返回给调用者
  • 随后的请求将使用 http 基本身份验证发送，设备 ID 作为用户名，身份验证令牌作为密码。该服务不是很健谈，因此每个请求都会发送凭据。
  • 我将实现一个 CredentialsAuthProvider，它将使用 httpRequest.GetBasicAuthUserAndPassword() 获取凭据，并根据 db 数据验证它们。

但感觉我应该使用内置到 ServiceStack 的注册。

问题 2：在每个请求中传递身份验证详细信息有什么问题？这将使编写我的应用程序请求更容易，但根据 ServiceStack 示例，它似乎没有“完成”。大概这是因为如果您有很多请求需要重新验证每个呼叫，那么效率会很低——还有其他原因吗？我的应用最多每隔几分钟只会发出一个 Web 请求，因此避免会话并重新验证每个请求似乎更简单。

问题 3：我是否在继承 CredentialsAuthProvider 的正确轨道上？

问题 4：使用 auth 令牌生成哈希而不是每次发送 auth 令牌有什么意义吗？所有通信都将通过 https。

4

1 回答 1

2

答1： 会好的。如果您根据要求拨打多个电话。通常身份验证基于 cookie，现在您可以将其存储在客户端和/或服务器上，并将用户与其匹配。再次在这里，如果您使用的是设备，您可以始终使用设备而不是用户来映射和验证用户。根据您的要求。

我更喜欢使用 provider，因为它隐藏了许多您需要手动执行的细节。你走在正确的轨道上。有许多专门针对身份验证以及如何使用服务堆栈创建自定义身份验证的博客。如果你喜欢让我知道我有书标记一些会给你。搜索最新版本的最佳方法是查看 Servicestack 的 Twitter 帐户。

回答2：这又是，我说根据要求。现在，如果您的用户将仅在 WIFI 区域中。（主要是商业用户），那么通话没有限制。只需调用 API 并在后台进行身份验证。简单的 JSON 令牌不会受到伤害，它只有几个字节。但同样，如果您的用户群很大，但没有使用良好的互联网连接，那么最好将身份验证详细信息存储在设备上并进行检查。只是为了节省网络通话。在任何情况下，网络调用都会占用大量资源。

答案 3：是的，您在正确的轨道上。仍然查看博客条目以获取更多详细信息。我不记得代码片段以及它如何与上次更新一起使用，所以我不在这里放代码。

答案4：这个答案有点复杂。通过 https 传递数据并将用户从身份欺诈中拯救出来几乎是不同的事情。现在，如果您没有生成身份验证令牌（基于哈希的值），那么您也可以通过 http 或 https 传递用户。现在，另一个用户可以使用它来模拟第一个用户并发送数据。甚至数据也通过 https 传递，但数据仍然被嘲笑。基于散列的值用于避免这种情况。还有其他几个业务用例可以使用 auth token 来覆盖。

请让我知道我是否正确理解了您的问题并回答了？或者如果需要任何进一步的细节？

于 2013-07-19T16:23:49.987 回答