In WCF is there a provision to have a layer of protection for a [datamember] variable, so that it occurs only a specific number of time in the request header.
So have a default value set for all data member variable names, rather than setting individual properties for maximum time each variable should occur in a request header. (This setting is basically to protect against say a brute force or a DDOS attack).
Any suggestions / pointers on the same would be great.
Thanks In Advance!!!..
Related
I want to customise the Action and ReplyAction properties of the OperationContractAttributes that I have on my data contract types in my WCF services.
I have some logic in an ESB that will read incoming messages and route them accordingly based on the SOAP action header so I need to explicitly state the values for these properties. But I don't even look at messages being returned, so it seems cleaner to have the same value for both properties.
I'd like to know if there is anything obviously wrong with setting these two properties to equal the same value for a specific operation? Why are the default values different to one another?
Thanks
Just to follow up on my own question in case it's helpful to others... I did proceed with using the same value for Action and ReplyAction.
Many SOAP implementations ignore the actions so it's less relevant, but WCF does use this value to route a message to the operation on a service. Setting both of the values to the same thing doesn't cause any issues because no system processes both the request and the response so there's nothing ambiguous about it.
I found that doing this made the WSDL generated simpler to understand, and there were half as many actions to document and route in our ESB.
I'm trying to add a custom HTTP header to Neo4jClient's outgoing Cypher requests, on a per-request basis. What I mean by per-request basis is that the contents of the HTTP header depend on the (user in the) current session.
The idea is that this header will be interpreted by a load balancer so that it always redirects the request to that slave in the Neo4j cluster where the data of the user in the current session is already mapped to memory, leading to performance gains.
For example, I might keep the address of a particular slave in the user's session and add the HTTP header Neo4j-slave: <address> to outgoing requests towards the load balancer. It will then redirect this request to the right slave.
I'm not sure if Neo4jClient is built with this kind of extensibility in mind; from the looks of it, I'm going to have to duplicate a lot of code in non-virtual methods if I don't want to alter existing code.
I've been looking at implementing IHttpClient as an entry point into the GraphClient. After all, I can pass my implementation to GraphClient's constructor and it receives the outgoing HttpRequestMessage so I can modify it along the way) but I think that only works for modifications that only depend on the HttpRequestMessage itself (or on some state somewhere but I want to avoid that).
I've also been looking into ThreadLocals as a means to pass additional arguments to HttpClient#SendAsync but I'm not sure if those even work if asynchronous methods are involved.
Is there a more or less trivial way to hook into Neo4jClient and add this header?
Thanks!
I can't think of a good way to do this currently, however if you add the required extensibility to IGraphClient in a clean way, I'd accept a pull request for this and we can include it in the published library.
When you make a subscription, you pass in a correlationID and use that to reference the security for the fields that come back
So you can have a counter that increments every subscription and use that as the correlationID, and then keep a map from that counter value to the security object
Is there a more efficient way to do this?
In stead of passing a number and keeping a map, you can use the security object as the correlationID
Then, when you get a tick, instead of getting the counter and looking up the mapped security, you can just cast the correlationID pointer to the security object's type and directly apply any changes to the security object
No lookups needed, and there are no concerns about synchronization on the map.
I have a WCF Service (.NET4.0). Client is in .NET2.0. Enum values passed by the client into the service are always set with enum default value (which is the first enum member).
Is this an issue in .NET2.0 ? Are there any workarounds ?
The <FieldName>Specified is a feature used by the XmlSerializer. I've been stung by this before. It seams everyone finds out about this feature in a similiarly painful manner.
As you say, if this is set to false then your field won't be serialised. Unfortunatly false is the default for a boolean field so it can very annoying if you forget to set it.
If you do not appreciate this feature then you should be able to just delete the <FieldName>Specified field without consequence. Then the field will always be serialized.
These fields only make a difference because you are using the XmlSerializer in .NET 2. In your .NET 4 WCF app you are using the DataContractSerializer which does not possess this feature.
The default value of the enum is not really received by WCF. Really nothing is received on the server for that enum. Consequently the enum is not set, so it remains the default value.
I'm having trouble defining what my OperationContract should be when adding / updating an entity. I want to send an entity (or list of entities) to the ObjectContext via the WCF Service (which will instantiate a Business Manager for me to do the actual validation).
If the entity passes all of the validation rules (which could very well require querying the database to determine pass/fail for more complex business rules), it'll be saved to the database, and I'll need to be able to pass back its ID (Identity Column primary key) and the value of the concurrency token (timestamp column), but if it fails, obviously we want to have a message or messages saying what was wrong. In the case of an update, all we would need would be the new value of a concurrency token, but again we'd want the validation message(s).
To make it trickier, an entity could have multiple child/grandchild entities as well. For instance, a Trip will have Stops, which could potentially have Orders.
I'm just wondering how people handle this in the real world. The simplest examples just show the WCF service's operations like:
[OperationContract]
bool AddEntity(Entity e);
[OperationContract]
bool UpdateEntity(Entity e);
Does anyone have any great ideas for handling this? I guess I'm really just looking for practical advice here.
Should we be trying to save a collection of objects in one service call?
Should we be conveying the validation messages through a fault contract?
Any advice/input would be helpful, thanks!
Should we be trying to save a
collection of objects in one service
call?
If you mean saving whole object graph in one call then the answer is definitely yes. If you mean saving multiple independent object graphs (collection) in one call then the answer is probably yes. It is good idea to reduce number of roundtrips between client and service to minimum but in the same time doing this can introduce complications. You must decide if the whole collection must be saved as atomic operation or if you are happy with saving only part of the collection and returning errors for the rest. This will influence the rest of your architecture.
Should we be conveying the validation
messages through a fault contract?
Yes but only if you will use save operation as atomic because fault contract is exception and exception should break your current operation and return only validation errors. It should be enough to have single fault contract which will transfer all validation errors. Don't fire the exception for each single validation error because it can make your application pretty annoying and useless.
If you want to save only part of the collection which passes validations and return errors for the rest you should not use fault contracts. Instead of fault contracts you should have some container data contract used for response which will carry both ids and timestamps for saved data and ids and errors for unsaved data.
One little note to STEs: Passing back just Ids and timestamps can be probably tricky. I'm not sure if you don't have to turn off tracking when you want to set them and after that turn the tracking on again.