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!
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.
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.
Related
I am storing additional attributes in my '_users' db records. In the case where I have multiple users sharing a database, where one is the owner and one is the reader/writer, I would like to get that user's db property to see what database they have permissions to write to.
Is it possible to modify the response of POST _session or GET _session to respond with the cookie, but also with the db property from a '_users' record in the response body? Thanks in advance.
No, that is not possible at this time. This idea has been proposed, but not implemented a few reasons. (it's a long thread, but I felt it was relevant)
It sounds like you may want to take advantage of the database security object. This configuration allows you to set up specific users or roles with read/write capabilities per-database. (plus, this object will be sent to validation function, and it allows custom fields in addition to the mandatory ones)
Consider a typical Breeze controller that limits the results of a query to entities that the logged in user has access to. When the browser calls SaveChanges, does Breeze verify on the server that the entities reported as modified are from the original set?
To put it another way, does the EFContextProvider (in the case Entity Framework) keep track of entities that have been handed out, so it can check against malicious data passed to SaveChanges? Or does BeforeSaveEntity need to validate that the user has access to the changed entities?
You must guard against malicious data in your BeforeSaveEntity or BeforeSaveEntities methods.
The idea that the EFContextProvider would keep track of entities that have already been handed out is probably something that we would NOT want to do because
The EFContextProvider would no longer be stateless, which was a design goal to facilitate scaling.
You would still need to guard against malicious data for "Added" entities in the BeforeXXX methods.
It is actually a valid use case for some of our users to "modify" entities without having first queried them.
I'm rather new at this, but I've come to understand the security risks of using Breeze to expose an IQueryable<>. Would someone please suggest to me some best practices (or merely some recommendations) for securing an IQueryable collection that's exposed in the JavaScript? Thanks.
I would not expose any data via IQueryable that should nto be sent to the client via a random query. So a projection could be exposed or a DTO.
I'm not sure if this answers your question tho ... What "security risks" are you worried about?
I second this question, too. But to add some specifics along the questions that Ward asked:
In securing queryable services, two traditional issues come to mind:
1) Vertical security: Which items is the currently logged in user (based on user identity or roles) NOT allowed to see in the UI. Those need to be removed from the queryable list. IMO, this can be done as part of the queryable ActionFilter magic by chaining some exclude logic on the returned IQueryable.
2) Horizontal security: Some models contain fields that are not appropriate for the logged in user to see (and/or edit). This is more difficult to handle as it's not a matter of just removing instances from the returned IQueryable. The returned class has a different shape and therefore can be handled either by the json formatter omitting the fields based on security (which AFAIK screws up breeze meta data) or you return a DTO in which case since the DTO doesn't exist in the metadata it's not a full life cycle (updatable) class? (I am asking this not stating it)
I would like to see either built-in support or easy to implement recipes for number 2). Perhaps some sample code to amend the client side metadata to make DTOs work perfectly fine comingled with model objects. The newset VS 2012 SPA templates (in the TodoList app) seem to push DTO variants of the model object both on the queryable and insert/update side. This is similar to the traditional MVC modelviews...
Finally - I'd add a request to auto-handling of the overposting security issue for inserts and updates. This is the reciprocal aspect of 2). Some users should not be able to edit certain fields.
I model a User as an aggregate root and a User is composed of an Identifier value object as well as an Email value object. Both value objects can uniquely identify a User, however the email is allowed to change and the identifier cannot.
In most examples of DDD I have seen, a repository for an aggregate root only fetches by identifier. Would it be correct to add another method that fetches by email to the repository? Am I modeling this poorly?
I would say yes, it is appropriate for a repository to have methods for retrieving aggregates by something other than the identity. However, there are some subtleties to be aware of.
The reason that many repository examples only retrieve by ID is based on the observation that repositories coupled with the structure of aggregates cannot fulfill all query requirements. For instance, if you have a query which calls for some fields from an aggregate as well as some fields for a referenced aggregate and some summary data, the corresponding aggregate classes cannot be used to represent this data. Instead, a dedicated read-model is needed. Therefore, querying responsibilities are decoupled from the repository. This have several advantages (queries can be served by a dedicated de-normalized store) and it is the principal paradigm of CQRS. In this type of architecture, domain classes are only retrieved by the repository when some behavior needs to execute. All read-only use cases are served by a read-models.
The reason that I think it appropriate for a repository to have a GetByEmail method is based on YAGNI and battling complexity. You an allow your application to evolve as requirements change and grow. You don't need to jump to CQRS and separate read/write stores right away. You can start with a repository that also happens to have a query method. The only thing to keep in mind is that you should try to retrieve entities by ID when you need to invoke some behavior on those entities.
I would put this functionality into a service / business layer that is specific to your User object. Not every object is going to have an Email identifier. This seems more like business logic than the responsibility of the repository. I am sure you already know this, but here is good explanation of what I am talking about.
I would not recommend this, but you could have a specific implementation of your repository for a User that exposes a GetByEmail(string emailAddress) method, but I still like the service idea.
I agree with what eulerfx has answered:
You need to ask yourself why you need to get the AR using something
other than the ID.
I think it would be rather obvious that you do not have the ID but you do have some other unique identifier such as the e-mail address.
If you go with CQRS you need to first determine whether the data is important to the domain or only to the query store. If you require the data to be 100% consistent then it changes things slightly. You would, for instance, need 100% consistency if you are checking whether an e-mail address exists in order to satisfy the unique constraint. If the queried data is at any time stale you will probably run into problems.
Remember that a repository represents a collection of sorts. So if you do not need to actually operate on the AR (command side) but you have decided that where you are using your domain is appropriate then you could always go for a ContainsEMailAddress on the repository; else you could have a query side for your domain data store also since your domain data store (OLTP type store) is 100% consistent whereas your query store (OLAP type store) may only be eventually consistent, as is typical of CQRS with a separate query store.
In most examples of DDD I have seen, a repository for an aggregate
root only fetches by identifier.
I'd be curious to know what examples you've looked at. According to the DDD definition, a Repository is
A mechanism for encapsulating storage, retrieval, and search behavior
which emulates a collection of objects.
Search obviously includes getting a root or a collection of roots by all sorts of criteria, not only their ID's.
Repository is a perfect place for GetCustomerByEmail(), GetCustomersOver18(), GetCustomersByCountry(...) and so on.
Would it be correct to add another method that fetches by email to the repository? - I would not do that. In my opinion a repository should have only methods for getting by id, save and delete.
I'd rather ask why you don't have user id in the command handler in which you want to fetch the user and call a domain method on it. I don't know what exactly you are doing, but for the login/register scenario, I would do following. When a user logs in, he passes an email address and a password, and you do a query to authenticate the user - this would not use domain or repository (that is just for commands), but would use some query implementation which would return some UserDto which would contain user id, from this point you have the user id. Next scenario is registration. The command handler to create a new user would create a new user entity, then the user needs to log in.
I need to Cache certain objects which are based on SharePoint Managed Client Object Model like ClientContext, GroupCollection, User , List etc. Initially I tried using Appfabric cache but it gives some issues like "cannot be serialized" . Here my question is "Is it possible to serialize SharePoint Managed Client Object Model based Objects?" .
Next I tried with .NET ObjectCache which actually caches the SP's Managed Client Objects but problem over here is I need a distributed / unified caching technique. As per my knowledge we cant make ObjectCache distributed over multiple hosting servers. Can anyone suggest me a solution or show me light to proceed. Thanks in advance.
SharePoint Client Object Model will not support Object Cache w.r.t the Client objects. That is the limitation in Client Object Model.
You cannot serialize the context or the result of a query. Also a ListItem cannot be serialized. Nonetheless: At least when thinking about query-results the most important information you usually want to know is the content of the fields returned.
So, ListItem.FieldValues is a simple Dictionary<string,object> which can be easily serialized.
You could use this Dictionary in combination with the Listitem's ID to create your own caching mechanism.