I know this has been asked more generally before, but here is my specific situation:
I have an endpoint (API exposed to clients/users) that ends up calling public member functions of some objects. Should I validate at the endpoint or at the member function?
It seems that validating at the endpoint is a little easier in this case because then all of my validation is done around my API functions.
But somehow it feels like the objects should maintain themselves and prevent invalid data from being used on their own functions.
Thanks!
Validation can be, and usually is, quite complex process, that involves lots of heavy, bussiness-related logic and which has plenty of dependencies to the outer resources.
I suppose it's better to let the client create invalid object and validate it at the very end - just before its use in the bussines service.
Related
I have a business logic layer that acts as a service and is agnostic to any application facing or user facing interface. For example, I've got UserService which takes care of operations related to user (e.x. creating users) and at the moment it returns a custom error object that includes a message that explains what went wrong. Now my RESTful API would use services to handle api requests but how do I handle business errors? how do I know what status code to use? I obviously don't like to put a lot of if statements in every single API call. I also thought about having a global error handler that would map every single business logic error to a status code and return that but that's also very verbose code. I'd love to hear some good ideas to handle this elegantly.
this is my first post, and I really have tried hard to find an answer, but am drawing a blank thus far.
My implementation of IDataContractSurrogate creates surrogates for certain 'cached' objects which I maintain (this works fine). What doesn't work is that in order for this system to operate effectively, it needs to access the service instance for some properties of the instance which it is maintaining from the interaction with its client. Also, when my implementation of IDataContractSurrogate works in its 'client mode' it needs access to the properties of the client instance in a similar way. Access to the information from the client and service instance affects how I create my surrogate types (or rather SHOULD do if I can answer this question!)
My service instancing is PerSession and concurrent.
On the server side, calls to GetDataContractType and GetDeserializedObject contain a valid OperationContext.Current from which I can of course retreive the service instance. However on the client side, none of the calls yield an OperationContext.Current. We are still in an operation as I am translating the surrogate types to the data contract types after they have been sent from the server as part of its response to the client request so I would have expected one? Maybe the entire idea of using OperationContext.Current from outside of an Operation invocation is wrong?
So, moving on, and trying to fix this problem I have examined the clientRuntime/dispatchRuntime object which is available when applying my customer behaviour, however that doesn't appear to give me any form of access to the client instance, unless I have a message reference perhaps... and then calling InstanceProvider. However I don't have the message.
Another idea I had was to use IInstanceProvider myself and then maybe build up a dictionary of all the ones which are dished out... but that's no good because I don't appear to have access to any session related piece of information from within my implementation of IDataContractSurrogate to use as a dictionary key.
I had originally implemented my own serializer but thats not what I want. I'm happy with the built in serializer, and changing the objects to special surrogates is exactly what I need to do, with the added bonus that every child property comes in for inspection.
I have also looked at applying a service behavior, but that also does not appear to yield a service instance, and also does not let me set a Surrogate implementation property.
I simply do not know how to gain access to the current session/instance from within my implementation IDataContractSurrogate. Any help would be greatly appreciated.
Many thanks,
Sean
I have solved my problem. The short answer is that I implemented IClientMessageFormatter and IDispatchMessageFormatter to accomplish what I needed. Inside SerializeReply I could always access the ServiceInstance as OperationContext.Current is valid. It was more work as I had to implement my own serialization and deserialization, but works flawlessly. The only issue remaining would be that there is no way to get the client proxy which is processing the response, but so far that is not a show stopper for me.
I am building an open source library to interact with a public API. The API validates all data passed to it and on failure properly returns a non-200 status code and usually a failure message causing my library to throw an Exception.
Some of my methods do check for required parameters, but mostly I have decided not to validate the data before passing it to the API.
Should a library for an API also be validating the data? If so, to what extent? Should it attempt to fully validate all data or just verify that required parameters are present/not empty?
The rule has two parts: on input, be an accepting loving grandmother: take what the caller gives you and don't be a stickler about the interface convention in places where it makes little difference; or where you can supply reasonable defaults. On output, follow the convention to the letter: be a strict pedant, a martinet.
So, in my opinion, the answer is yes, you should check your caller's input and give the API the best data you can. But this does not necessarily mean you should duplicate validations that the API is going to do anyway.
You have to use your head and think about what makes sense.
Is it possible to create a "generic" as in "adaptable" routing service, which will NOT have any public methods to call. Instead, you'd be able to call any command, which would then be mapped in the service and will pass it to appropriate end point with simple message transformation where required.
It may be hard to understand and idea might seem a bit crazy (it came from a colleague of mine), but it's clearer if you look at the example:
similar to what's described in this article, only difference is that our service should not have a "SubmitTimeSheet" public method, in fact it should have no public methods to call. We'd have to "intercept" an incoming call on a much lower level before it returns "Method Not Found" error.
Is this at all possible? The reason for this is obvious: possibility of adding new clients without having to change the code. All we'd have to do is to add a new mapping entry in some sort of config file or even database, e.g.
<Client address="newClientAddress" method="DoAnything" transformation="NewClientDoAnything.xslt" endPoint="endPointClientAddress" endPointMethod="endPointClientDoAnything" />
Check out WCF 4 routing - supports content based routing, xpath transforms and much more.
http://blogs.msdn.com/b/routingrules/
They have already done it in Nirvana. But it is very expensive.
This is not possible in WCF unless you define your contract as a very loose, fit-for-all contract which takes a message and returns a message. By doing this, you will los all the goodness (although not huge goodness in WCF) of WCF.
I am looking at securing some WCF services using WIF, and have read within the Identity Training Kit from Microsoft, within exercise 1, "Furthermore, you can expect developers to assign conditions via Code Access Security style calls (i.e. decorating via attributes and so on). Both capabilities will require some coding support"
(midway through this article:
http://channel9.msdn.com/Learn/Courses/IdentityTrainingCourse/WebServicesAndIdentity/WebServicesAndIdentityLab/Exercise-1-Using-Windows-Identity-Foundation-to-Handle-Authentication-and-Authorization-in-a-WCF-Ser
)
However I'm unable to find any documentation regarding how to implement a solution that makes use of this decoration approach. I don't really have any need for using the claims within the actual WCF method or business logic, but simply want to use WIF/STS to secure access to the method. Any tips on whether this is the best approach, and how to secure methods using decorations would be appreciated.
I think you can take a look at PostSharp. You can implement your cross cutting concerns using AOP and then apply them as attributes to decorate your methods. So your checks would be isolated in well knows places and the business methods would have specified in the security attributes the claims required to execute those methods.
Or, for simple cases, you can use this (I think you were referring to these):
[ClaimsPrincipalPermission(SecurityAction.Demand, Operation = "Operation1", Resource = "Resource1")]
You can also implement an IOperationInvoker. Attribute your contract, and implement with a behavior. Spin through the channels and endpoints at startup, reflect on your operations for attributes on the methods and/or parameters to setup your checks. Then apply the checks when the operation is invoked.
There are a couple of good articles around. Though I can only find the one below.
http://msdn.microsoft.com/en-us/magazine/cc163302.aspx