我正在构建移动应用和ServiceStack Web服务后端。 ServiceStack中的身份验证功能看起来很棒但很容易迷失其灵活性 - 非常感谢指导。我将使用自己的数据库表来存储Web服务中的用户等。我希望有一个注册过程和后续的身份验证:
然后,后续Web服务请求将提供设备ID和身份验证令牌(或使用它创建的哈希)。该应用程序不是很健谈,所以我很想在每个网络请求上发送身份验证详细信息。
问题1 :我应该挂钩到ServiceStack的注册API还是只添加几个自定义Web服务调用?例如如果不使用ServiceStack的注册,我会:
但感觉我应该使用ServiceStack内置的注册。
问题2 :为每个请求传递身份验证详细信息有什么问题?这样可以更轻松地编写我的应用程序请求,但根据ServiceStack示例,它似乎没有“完成”。大概是因为如果你有很多请求需要重新验证每个电话 - 其他任何原因,效率低下?我的应用程序最多只会每隔几分钟发出一次Web请求,因此避免使用会话并重新验证每个请求似乎更简单。
问题3 :我是否在正确的轨道上继承CredentialsAuthProvider?
问题4 :是否有任何一点使用auth令牌生成哈希而不是每次都发送身份验证令牌?所有通信都将通过https进行。
答案 0 :(得分:2)
答1:没关系。如果您按要求拨打多个电话。通常,身份验证基于cookie工作,现在您可以将其存储在客户端和/或服务器上,并将用户与之匹配。再次在这里,如果您正在使用设备,可以始终使用设备而不是用户来映射和验证用户。根据您的要求。
我更愿意使用提供商,因为它隐藏了您需要手动执行的许多细节。你走在正确的轨道上。有许多博客专门用于身份验证以及如何使用服务堆栈创建自定义身份验证。如果你愿意,请让我知道我有一些标记,有些人会给你。搜索最新版本的最佳方式是Servicestack的结帐Twitter帐户。
答案2:我再次说,这是根据要求。现在,如果您的用户仅在WIFI区域。 (对于商业用户来说尤其如此),那么呼叫没有限制。只需提供API调用并在后台进行身份验证。简单的JSON令牌不会受到伤害,只有几个字节。但是,如果你有大量用户群没有使用良好的互联网连接,那么最好将认证详细信息存储在设备上并进行检查。只是为了保存网络电话。无论如何,网络呼叫资源很重。
答案3:是的,你走在正确的轨道上。仍可查看博客条目以获取更多详细信息。我不记得代码片段以及它如何与上次更新一起工作,所以我不在这里提供代码。
答案4:这个答案有点复杂。通过https传递数据并将用户从身份欺诈中保存起来是一回事。现在,如果您没有生成身份验证令牌(基于哈希的值),那么您也可以通过http或https传递用户。现在,另一个用户可以使用它来模拟第一个用户并发送数据。甚至数据也通过https传递,但数据仍然被嘲笑。基于散列的值用于避免这种情况。此外,还可以使用身份验证令覆盖其他几个业务用例。
如果我正确理解你的问题并回答他们,请告诉我?或者如果需要进一步的细节?