I am reading a lot of conflicting information about how and when to close a WCF service.
Some people say you don't need to.
Some people say in the same place where you make the Async call
Some people say in the completed method.
Can someone point me to a place where microsoft actually says how to use this method? Also when do you call it?
Are you referring to client or service side closing
For client closing this is the recommended pattern - http://blogs.msdn.com/b/drnick/archive/2007/05/04/the-try-catch-abort-pattern.aspx
For services you can close the service host. For eg. in the self hosted service say using a windows NT Service, on Service shutdown you want to close the host so that clean up like un-registering ports etc. happen gracefully.
If you want to the try/catch/abort patten works for invocation and also for close. So you can provide a timeout and if you get a timeout exception, abort the instance.
Related
the title is quite general but my doubt is specific.
I have doubt regarding where to write the service logic code (in service control handler or in ServiceMain),as in whatever the functionality the service would perform . Is it in ServiceMain ?
I have looked upon these topics on MSDN relate to service. But ,didn't help me
http://msdn.microsoft.com/en-us/library/ms687414%28VS.85%29.aspx
http://msdn.microsoft.com/en-us/library/ms685984%28v=vs.85%29.aspx
Basically, I want to start a socket listening on windows using a service. This listening socket logic code will be in service file because of I am going to use winexe utility to send this service from linux box to windows box. currently, winexe sends the winexesvc service file on windows. So, ultimately I am going to replace the existing winexesvc service so that it will perform listening on a particular port function when sent on windows. (Service skeleton would remain same but its task performing logic will change,right?). please tell if I am missing anything.
Thanks in advance.
Service control handler should only, well, handle control messages that are sent to the service (the ones shown in the examples you linked are SERVICE_CONTROL_STOP and SERVICE_CONTROL_INTERROGATE). These control messages are sent to the service from the environment.
The logic of your service should be implemented in the ServiceMain function, when all required initialization is done. In the example at the URL in your post, the service logic code is put into the SvcInit function (which is probably not the most appropriate name for a function that implements logic of a service).
I have a WCF service which I host inside a WFP application, which acts as one of the clients of service as well. There is one more WPF app which acts as another client for service. After a timeout occurs and clients get disconnected, What is the proper way to clean up resources and connect the clients again. I am trying to create new proxies but I am not able to use them for communication. I know I can increase the recieve timeout on service but I need my clients to be able to communicate always not just for long enough. I have also tried continously sending a message to service at interval but that's something I don't want to go for. What approach is best for continous communication between clients and service? My service might need to be connected to clients for months or may be years.
Any help will be of great value.
Thanks in advance.
You can catch the CommunicationException or something like that and then restore the channel.
I'm not sure if I'm on the right lines but this is what I'm trying to do, I have a Silverlight application and a WCF service, the Silverlight app "subscribes" to the WCF service using PollingDuplex and the service can send data to any connected clients which works.
The service is marked with [ServiceContract(CallbackContract = typeof(IServiceCallback))] and it is single instanced
The problem is there is another service which should be able to call a standard method on this service to pass it data that will get distributed to the connected Silverlight clients, but because of the above settings it requires it to use callbacks (I can't change the other service).
Is there a way to have both types of operations, callback and standard in the same service if that makes sense?
Thanks for your time
Yes. It is possible. I guess CallbackContract parameter will not stop you from using your service as a regular request/response service (though I have not tried it).
But for the same contract, you may have to define two end points with different bindings, one with PollingDuplexHttpBinding and another one with basicHttpBinding (with silverlight this is the only other option).
You have to make sure that you are calling the right operation from the clients using duplex and basic http bindings.
Ok,
I have developed this WinForms client, which interacts with a server (ASPX Application) by means of WCF calls. I would now like to deploy the server to my shared webhost, but I'm kinda new to WCF and especially the security possibilities behind it.
The goal is to kind of secure the WCF service, so that not everybody that knows or finds out the endpoint address can call it. Rather, only my WinForms client must be able to call the WCF service.
I do not need authentication on a user basis, so no authentication is required from the user of the client. But I want only instances of this WinForms client to be able to interact with the service. The information passed between server and client is not very sensitive, so it's not really required to secure it, but it's a plus if it can easily be done.
Is this possible with a Shared Host (IIS) environment (no HTTPS at disposal) ? What bindings and options should I use ? I suppose wsHttpBinding, but how would I setup the security options ?
Using .NET 4.0
Thanks
From what I understand, you have an internet-facing service which you want to limit to only your client app to be able to call - correct? Or do you envision other clients (like PHP, Ruby etc.) also wanting to call into your service at some point?
To secure your message, you have two options in WCF - message or transport security. Over the internet, with an unknown number of hops between your client and your service, transport security doesn't work - you're left with message security (encrypting the message as it travels across the 'net). For this to work, you typically add a digital certificate to your service (only server-side) that the client can discover and use to encrypt the messages with. Only your service will be able to decrypt them - so you're safe on that end.
The next point is: who can call your service? If you want to be totally open to anyone, then yes, you need wsHttpBinding (or the RESTful variant - webHttpBinding). If you want to allow non-.NET clients, you're typically limited to no authentication (anyone can call), or username/password schemes which you will validate on the server side against a database of valid users.
If you only want to allow your own .NET client in, then you can do several things:
disable metadata on your service; with this, you would "hide" your endpoints and the services they provide - someone using a "metadata scanner" (if that exists) wouldn't be able to just stumble across your service and find out what methods it provides etc. This however also makes it impossible for another developer outside your organization to do an Add Service Reference to your service.
you could define and use a custom binary http binding - only other clients with this setup could even call your service. The binary http binding would bring some speed improvements, too. See this blog post on how to do this.
you need to somehow identify those callers that are allowed in - one possible method would be to put an extra header into your WCF messages that you then check for on the server side. This would simply make sure that a casual hacker who discovers your service and figures out the binary http binding would still be rejected (at least for some time). See this blog post here on how to implement such a message inspector extension for WCF.
the ultimate step would be to install a digital certificate on the client machine along with your service. You would then set up your client side proxy to authenticate with the service using that certificate. Only client machine that have that certificate could then call into your service.
It really depends on how far you want to go - WCF gives you a lot of options, but you need to decide how much effort you want to put into that .
The first thing you need to ask your self is: "What can someone do to your WCF service if they connected their own customized client?" Look at all of the functionality that is being exposed via WCF and assume that it could be accessed at will. You have absolutely no control over the client, and you will never have this ability.
HTTPS is beautiful, its a damn shame that your forced to be vulnerable to OWASP A9: Insufficient Transport Layer Protection. If it where up to me, I would move to a different host that cared about security. If you are throwing usernames and passwords over the network, then your putting your users in danger.
One of the biggest problems I have seen with a WCF service is that they had a "executeQuery()" function that was exposed. The developer allowing the client to build queries to be executed by the server. This approach is fundamentally flawed as you are just handing your database over to an attacker. This type of vulnerability isn't SQL Injection, it falls under CWE-602: Client-Side Enforcement of Server-Side Security.
Along the same lines as CWE-602 is OWASP A4: Insecure Direct Object References. Could an attacker fool your WCF service into thinking its another user by providing a different user id? Are you trusting the client to tell the truth?
The next classification of vulnerabilities that you must take into consideration is OWASP A1: Injection, other wise known as "Taint and Sink". For instance if you are exposing a function where one of its parameters is being used in a CreateProcess() which is invoking cmd.exe. This parameter could be controlled by the attacker, and there for this variable is "tainted", the call to CreateProcess() is a "sink". There are many types of vulnerabilities along these lines, including but not limited to; SQL Injection, LDAP Injection, XPATH Injection. These types of vulnerabilities affect all web applications.
I have a Linux/c client app that connects to a WCF web service over HTTP/SOAP (BasicHTTPBinding). I am using gSOAP. Can I implement the calls to the web-service using callback? I want to get the data asynchronously as call back.
Update: I have updated the question title.
WCF does support Duplex services, or those that have the ability to call back to the requesting client. Duplex services can be very complicated, as they are not only stateful, but they impose an contract implementation requirement on their clients.
Duplex services require the use of the WSDuplexHttpBinding. You will need to make use of the OperationContext to get a reference to the callback channel. Your clients MUST implement the callback contract in some class, and provide an InstanceContext that contains an instance of the callback class to the client proxy. Communications in both directions must be supported, and if the client is behind its own firewall or across the internet, this can be a complicated matter to resolve. Take care when writing duplex services...they are often more trouble than they are worth...so make sure you really need it. ;-)
The following page might be helpful:
http://msdn.microsoft.com/en-us/library/ms731064.aspx
The basicHttpBinding does not support callbacks. Another approach might be to have another method that the client can poll on for the response.
I am facing the same issue and the approach I am trying is to have a pair of gsoap servers/clients. Basically each process will listen on a port for soap calls and make its client calls to the other server. This way I avoid the polling or other complex approaches. The code has to be obviously thread safe for whatever business logic is implemented but the client/server combo pair is the simplest solution i have thought of so far.
Obviously one needs to be in control of both sides of the solutions the mentioned server and the mentioned client.