2

I'm investigating ServiceStack's Authorization feature and want to use Couchbase as my data store. I understand there isn't an IUserAuthRepository implementation for Couchbase so I'd have to develop my own, which isn't a problem.

The issue I am having is if I store the built-in UserAuth object as-is, CB it uses the Id field as the document identifier. This is a problem because I believe the identifier should be object type specific, otherwise a separate 'bucket' would be required to prevent conflicting id's across different objects. I don't really want to have lots of buckets unless I have to.

My preference would be to have the document id set to the type of the object plus the object specific identifier.

eg Using Id "UserAuth_1234" or using UserName "UserAuth_MikeGoldsmith"

Is my assumption of trying to re-use a bucket for different application objects valid or should I be thinking about a bucket per object-type / namespace?

Any direction would be welcome, both from Couchbase and ServiceStack enthusiasts.

Thanks

Additional Info

Ok, so from John's answer I will assume my additional property for the object type is valid.

I found this post where Mythz suggests the BootStrapApi example extends the AuthUser with custom properties. However, to me it looks like the AuthUser is persisted twice, first as the AuthUser and again as the User object (both times using the OrmLiteAuthRepository). Am I right?

Essentially, I want to utilise the SS auth feature, but control the POCO object that will be saved into Couchbase. Can someone give some direction if this is possible and if so, what I need to implement / hook into?

I tried implementing a Couchbase version of IUserAuthRepository, however it uses the UseAuth concrete type so I can't use my own object.

I also tried hooking into the OnAuthenticated method of AuthUserSession but at this point the UserAuth POCO will have been persisted using the register IUserAuthRepository.

I'm happy to use the CredentialsAuthProvider as I just want username/password authentication. More could be added later.

Thanks again!

Community
  • 1
  • 1
Mike
  • 661
  • 5
  • 10

2 Answers2

2

Buckets are loosely analogous to databases in the relational world, so generally they shouldn't be mapped to application objects. I'm not familiar with ServiceStack's auth feature, but your suggestion to use meaningful, prefixed keys seems reasonable and is a common approach for providing document taxonomy.

Keep in mind that in Couchbase, there's no field in the document that's considered an "id" or "key" field. The key used to store the document is available in metadata, but is not part of the JSON document itself. So if you're able to take advantage of views, then you could also store a document with a type attribute and then query by some non-id property. In other words, the key in the key value doesn't have to be the way you retrieve the user auth document.

Also, there are developers who use key prefixing as a way to provide document taxonomy for views, so you're key pattern above would work for that too. My preference is a type property, but that's no more valid than your suggestion.

Brian David Berman
  • 7,514
  • 26
  • 77
  • 144
John Zablocki
  • 1,592
  • 9
  • 6
  • The idea of a bucket per db, object per design and view per query seems to be the right way so far. – Mike Feb 13 '13 at 09:53
  • (Accidentally hit enter too early and can't edit my first post so here's the rest of my comment) I've created my models to have id and type properties; the key I use to save the document is a combination of these two - ie "{type}_{id}". This as you suggest, I think is a standard pattern and very similar to how the CB beer test works. The problem I'm having is more a ServiceStack issue. I want to use a custom user object and persist to CB without storing SS's AuthUser object. Thanks for your clarification on best practice for bucket / document taxonomy. – Mike Feb 13 '13 at 10:03
1

I've come across the ServiceStack UseCase examples, with one that addresses my Custom Authentication issue directy.

I was able to override the TryAuthenticate method and use my own UserRepository that backs onto Couchbase.

Mike
  • 661
  • 5
  • 10
  • Hey Mike, you might want to mark your answer as accepted to help others who come across your question when looking for help. – DanB Feb 14 '13 at 09:04
  • Hi Dan - I did try but SO is preventing me answering my own question for another couple of hours. I will once the time has elapsed, thanks. – Mike Feb 14 '13 at 10:07