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

Question

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

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

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

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

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

欢迎任何方向，包括 Couchbase 和 ServiceStack 爱好者。

谢谢

附加信息

好的，所以从约翰的回答中，我将假设我的对象类型的附加属性是有效的。

我找到了这个 post Mythz 建议使用 BootStrapApi 示例扩展了 AuthUser带有自定义属性。然而，对我来说它看起来像 AuthUser被持久化两次，第一次是 AuthUser再次作为 User对象(两次都使用 OrmLiteAuthRepository )。我说得对吗？

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

我尝试实现 IUserAuthRepository 的 Couchbase 版本，但是它使用 UseAuth 具体类型，所以我不能使用我自己的对象。

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

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

再次感谢!

Answer 1

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

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

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