ServiceStack：在没有 AuthUser 的情况下保留自定义用户对象答案

【问题标题】：ServiceStack: Persist custom user object without AuthUserServiceStack：在没有 AuthUser 的情况下保留自定义用户对象
【发布时间】：2013-02-12 11:12:29
【问题描述】：

我正在研究 ServiceStack 的授权功能，并希望使用 Couchbase 作为我的数据存储。我知道 Couchbase 没有 IUserAuthRepository 实现，所以我必须自己开发，这不是问题。

我遇到的问题是，如果我按原样存储内置 UserAuth 对象，CB 它使用 Id 字段作为文档标识符。这是一个问题，因为我认为标识符应该是特定于对象类型的，否则需要一个单独的“桶”来防止不同对象之间的 id 冲突。除非必须，否则我真的不想拥有很多桶。

我的偏好是将文档 ID 设置为对象的类型加上对象特定的标识符。

例如使用 ID“UserAuth_1234”或使用用户名“UserAuth_MikeGoldsmith”

我尝试为不同的应用程序对象重复使用存储桶的假设是否有效，或者我应该考虑每个对象类型/命名空间的存储桶？

欢迎 Couchbase 和 ServiceStack 爱好者的任何指导。

谢谢

其他信息

好的，所以根据 John 的回答，我将假设我的对象类型的附加属性是有效的。

我发现了这个 post，其中 Mythz 建议 BootStrapApi 示例扩展了 AuthUser具有自定义属性。但是，在我看来，AuthUser 似乎被持久化了两次，第一次是 AuthUser，然后是 User 对象（两次都使用 OrmLiteAuthRepository）。我说的对吗？

本质上，我想利用 SS 身份验证功能，但控制将保存到 Couchbase 中的 POCO 对象。如果可能的话，有人可以给出一些方向吗？如果可以，我需要实现/挂钩吗？

我尝试实现 IUserAuthRepository 的 Couchbase 版本，但它使用 UseAuth 具体类型，因此我无法使用我自己的对象。

我也尝试挂接到AuthUserSession 的OnAuthenticated 方法，但此时UserAuth POCO 将使用寄存器IUserAuthRepository 持久化。

我很高兴使用CredentialsAuthProvider，因为我只需要用户名/密码身份验证。以后可能会添加更多内容。

再次感谢！

【问题讨论】：

标签： servicestack couchbase

【解决方案1】：

存储桶与关系世界中的数据库大体相似，因此通常不应将它们映射到应用程序对象。我不熟悉 ServiceStack 的身份验证功能，但您建议使用有意义的前缀键似乎是合理的，并且是提供文档分类的常用方法。

请记住，在 Couchbase 中，文档中没有被视为“id”或“key”字段的字段。用于存储文档的密钥在元数据中可用，但不是 JSON 文档本身的一部分。因此，如果您能够利用视图，那么您还可以存储具有 type 属性的文档，然后通过一些非 id 属性进行查询。换句话说，键值中的键不必是您检索用户身份验证文档的方式。

此外，有些开发人员使用键前缀作为为视图提供文档分类的一种方式，因此您上面的键模式也适用于此。我的偏好是类型属性，但这并不比您的建议更有效。

【讨论】：

到目前为止，每个数据库一个桶、每个设计对象和每个查询视图的想法似乎是正确的方法。
（不小心按得太早了，无法编辑我的第一篇文章，所以这是我的评论的其余部分）我已经创建了具有 id 和 type 属性的模型；我用来保存文档的键是这两者的组合 - 即“{type}_{id}”。正如您所建议的，我认为这是一种标准模式，与 CB 啤酒测试的工作方式非常相似。我遇到的问题更多是 ServiceStack 问题。我想使用自定义用户对象并坚持到 CB 而不存储 SS 的 AuthUser 对象。感谢您对存储桶/文档分类的最佳实践进行澄清。

【解决方案2】：

我遇到过 ServiceStack UseCase 示例，其中一个直接解决了我的 Custom Authentication 问题。

我能够覆盖 TryAuthenticate 方法并使用我自己的支持 Couchbase 的 UserRepository。

【讨论】：

嗨，迈克，您可能希望将您的答案标记为已接受，以帮助其他在寻求帮助时遇到您的问题的人。
嗨，Dan - 我确实尝试过，但 SO 阻止我在接下来的几个小时内回答我自己的问题。时间到了我会的，谢谢。