How to make WPF MVVM application connect to multiple WCF Services? - wpf

I have 4 WCF services that I have developed.
Each service is responsible for something else.
Each service has a UserNamePasswordValidator, so clients need to supply credentials when connecting.
I would now like to develop my WPF client application, in an MVVM architecture.
I would like for the WPF application to load with a 'Login' screen,
where the user will input a username and password,
and then this will be passed on to the 4 clients for the 4 WCF services (all use the same username and password).
What is the best approach to doing this ?
Where are the clients located ? in the 'Model' part ? which view's model ?
The WCF Service needs to be consumed by multiple views, so I don't think I can put any of the WCF service clients in a specific Model class...

To do this, we have created a ServiceFactory class that connects to a service given its endpoint and an appropriate IClientChannel-derived interface. This assumes that you are using the WCF services directly, e.g. not via the VS-generated proxies, since you need to set the username and password values on each client channel creation.
The client channel interfaces are in an external "service library" along with the service factory, so they can be shared with the WCF service implementations and the clients. We store the credentials in a static state dictionary (though you also put it, for example, into the main resource dictionary) with the password being saved in a SecuredString for a tiny bit of extra security.
I've described the basic process for creating such a service factory on by blog:
http://blog.kutulu.org/2012/03/proxy-free-wcf-ditching-proxy.html
In our case, we perform a setup routine in App.xaml.cs that prompts for credentials and makes an attempt to call one of our services, looping until we get a successful login. That code is much more complex, but it's basically:
while (true)
{
var factory = new ChannelFactory<ITestChannel>(new WSHttpBinding("SecuredBinding"));
ITestChannel client = null;
try
{
factory.Credentials.UserName.UserName = logOnModel.UserName;
factory.Credentials.UserName.Password = logOnModel.Password;
var address = Settings.Default.TestServiceUrlBase));
client = factory.CreateChannel(address);
break;
}
// Catch various exceptions here.
}
The trick here is that, if your login or password is wrong and your UsernamePasswordValidator fails your login, you'll get a MessageSecurityException which will fault your channel, so you'll need to close it and open a new one. But you cannot change the credentials on a ChannelFactory once you've opened the first channel, so you need to dispose and re-create a new factory and new client channel every time.
We also check for CommunicationException and ArgumentException here in case the URL is wrong.
Once that's done, you can use similar code in your service factory class to construct a client, given its channel interface, and set up the credentials for each call. (We actually cache the service factories for each distinct interface because we create and destroy channel frequently, but that's up to you.)

Related

Read parameters from Java client in WPF application

I have created WCF service in .net.
It is called by Java client, how do I read parameters when service is being called?
Here is my code:
public string getMethod(string id, string name)
{
string str = name;
return str;
}
Here is my WPF application code, I have added web reference:
WebReference.Service1Soap client = new WebReference.Service1Soap();
string str = client.getMethod(id, name);
How do I read values of "id" and "name" called from Java client?
I am stuck here, please help me please!!
Any help would be greatly appreciated.
Thanks!!
The simplest way:
Run a local instance of the service in debug mode, or attach the visual studio debugger to WCF service host process.
Put a breakpoint in the getMethod() service operation code
Call the service with the java client.
Check the values using a watch or just mouseover.
EDIT.. from comments...
but I have set debug point, still it is not happening
That means that your java client call is not being made successfully. If your java client cannot call the service then you need to sort that out first. Please post a new question to address this, or there are plenty of stuff on google: https://www.google.co.uk/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=problem+calling+wcf+from+java
I need those parameter values in WPF application and I have to read
it. How to do it?
You can't send a message to a service and then have that data relayed to another client (WPF) unless you use callbacks via a duplex binding like wsDualHttpBinding, which is not a nice solution in my opinion. More reading here: http://www.codeproject.com/Articles/491844/A-Beginners-Guide-to-Duplex-WCF
If your java client needs to call into a WPF then you'll need to use ServiceHost inside your WPF application and host a WCF service from there. Look here for an example: http://blogs.msdn.com/b/brunoterkaly/archive/2013/11/01/wcf-service-hosting-how-to-host-a-wcf-service-from-inside-a-windows-presentation-foundation-application.aspx
EDIT 2
From Java, service client has been made successfully, and it is
getting the response. But how do I read parameters, and is there any
way or code, that "we come to know that .net service is being called".
Then the only thing you can do is either host the WCF service inside your WPF application, or use a duplex WCF binding on the service, and have the WPF application subscribe by registering a callback delegate. This way the service can call back to the client when something happens (a call is made).
Alternatively you could use a shared database which is updated with the call values when the java client makes the call. Your WPF app can then poll or use a SqlDependency to know when the data has changed.

Understanding how WCF works

I am using a WCF service between the Client side UI (Silverlight 3.0) and the Data Layer. We are using NHibernate for Database Access. So please tell me if my below understanding is correct or not:
UI calls WCF for a Save Method (for eg).
The WCF has a Save method in it which actually encapsulates a Save method from the Data
Access Object.
The Data Access Object method of Save in turn encapsulates a default Save Method of
NHibernate which actually saves some Business Object/s into the Database.
Also can someone tell me that how do we pass objects from WCF to the UI (Silverlight 3.0) layer and vice versa. I have read that we use DTO for that. But how does a DTO work? Do they correspond to the 'Data Contracts' in the WCF? If not then is the DTO declared on WCF (server) side and Client side code as well?
No, not quite....
UI calls the client-side proxy method Save
the WCF runtime takes that call and all parameters being passed in, and serializes them into a message (typically a XML serialized message)
the WCF runtime sends the serialized message over some kind of a transport media (whatever it is)
on the server side, the WCF runtime takes the incoming message
the message is deserialized, the appropriate class and method to handle it are identified
typically: a new instance of a service class is instantiated to handle the request
the WCF runtime unpacks the parameters and calls that appropriate message on the service class
same steps - basically backwards - are done for response
Important point: the only thing between the client and the server is a serialized message (which could be sent by e-mail or pigeon courier) - there's no other connection - no "remote object call" or anything like that at all
marc_s mentions the client-side proxies, which can be generated via the service references in your Silverlight project. The generated proxies are decent enough and provide an async model for running requests from the Silverlight side; those will look mostly like remoted procedure calls.
Another approach is to use the leaner (but maybe more advanced?) channel factory directly. A simple example of that can be found here. Both methods take care of most of the serialization details for you.

EF4 + STE: Reattaching via a WCF Service? Using a new objectcontext each and every time?

I am planning to use WCF (not ria) in conjunction with Entity Framework 4 and STE (Self tracking entitites). If I understand this correctly my WCF should return an entity or collection of entities (using LIST for example and not IQueryable) to the client (in my case Silverlight).
The client then can change the entity or update it. At this point I believe it is self tracking? This is where I sort of get a bit confused as there are a lot of reported problems with STEs not tracking.
Anyway, then to update I just need to send back the entity to my WCF service on another method to do the update. I should be creating a new OBJECTCONTEXT every time? In every method?
If I am creating a new objectcontext every time in every method on my WCF then don't I need to re-attach the STE to the objectcontext?
So basically this alone wouldn't work??
using(var ctx = new MyContext())
{
ctx.Orders.ApplyChanges(order);
ctx.SaveChanges();
}
Or should I be creating the object context once in the constructor of the WCF service so that 1 call and every additional call using the same WCF instance uses the same objectcontext?
I could create and destroy the WCF service in each method call from the client - hence creating in effect a new objectcontext each time.
I understand that it isn't a good idea to keep the objectcontext alive for very long.
You are asking several questions so I will try to answer them separately:
Returning IQueryable:
You can't return IQueryalbe. IQueryable describes query which should be executed. When you try to return IQueryable from service it is being executed during serialization of service response. It usually causes exception because ObjectContext is already closed.
Tracking on client:
Yes STEs can track changes on a client if client uses STEs! Assembly with STEs should be shared between service and client.
Sharing ObjectContext:
Never share ObjectContext in server environment which updates data. Always create new ObjectContext instance for every call. I described reasons here.
Attaching STE
You don't need to attach STE. ApplyChanges will do everything for you. Also if you want to returen order back from your service operation you should call AcceptChanges on it.
Creating object context in service constructor:
Be aware that WCF has its own rules how to work with service instances. These rules are based on InstanceContextMode and used binding (and you can implement your own rules by implement IInstanceProvider). For example if you use BasicHttpBinding, default instancing will be PerCall which means that WCF will create new service instance for each request. But if you use NetTcpBinding instead, default instancing will be PerSession and WCF will reuse single service instance for all request comming from single client (single client proxy instance).
Reusing service proxy on a client:
This also depends on used binding and service instancing. When session oriented binding is used client proxy is related to single service instance. Calling methods on that proxy will always execute operations on the same service instance so service instance can be stateful (can contains data shared among calls). This is not generally good idea but it is possible. When using session oriented connection you have to deal with several problems which can arise (it is more complex). BasicHttpBinding does not allow sessions so even with single client proxy, each call is processed by new service instance.
You can attach an entity to a new object context, see http://msdn.microsoft.com/en-us/library/bb896271.aspx.
But, it will then have the state unchanged.
The way I would do it is:
to requery the database for the information
compare it with the object being sent in
Update the entity from the database with the changes
Then do a normal save changes
Edit
The above was for POCO, as pointed out in the comment
For STE, you create a new context each time but use "ApplyChanges", see: http://msdn.microsoft.com/en-us/library/ee789839.aspx

Windows Phone 7 - Cookies not sent to WCF service

I have a bunch of WCF services at a domain:
AuthenticationService (the standard MS one, over HTTPS)
AppService (HTTP)
Usually, I call the Authentication Service and a cookie is returned. For desktop applications, I detach the cookie and reattach it with every new service call to the AppService which exposes the meat of my API.
Silverlight in the browser automatically attaches the cookie in all calls to the domain. I expected the phone to do the same.
It doesn't.
Access to the headers is not supported on the phone, so manual manipulation is out. I wonder if its because some bright spark at MS thought that the phone should enforce that cookies are only reattached to HTTPS endpoints at the same domain or something...
Help!!
This is a nightmare to troubleshoot since the phone doesn't support the other major major helpful setting; ignoring self-signed certificates.
Thanks,
Luke
** UPDATE **
While I'm following up the method using CookieContainer I must point out that even though the Add method on the Headers collection is missing in Silverlight, one can still add headers using the indexer.
See http://cisforcoder.wordpress.com/2010/12/01/how-to-implement-basic-http-authentication-in-wcf-on-windows-phone-7/
** UPDATE 2 **
CookieContainer can be set as per Lex answer. I'm now stuck and continuing to investigate an ArgumentNullException thrown from within the WCF client upon References.cs EndInvoke. My server shows no sign of receiving the call.
Two key calls on the stack are:
System.Net.Browser.HttpWebRequestHelper.ParseHeaders
And
MS.Internal.InternalWebRequest.OnDownloadFailed
FINAL UPDATE
The ArgumentNullException seems to be thrown when called against a server with a self-signed certificate.
However, there's something odd with the emulator/SDK. I have had this exception against all my servers, even those with no SSL, and one with an issued certificate.
I've also had problems that have been resolved only by a local reboot. So I think my problems have been a result of having the right code, but thinking it was wrong because of other problems in the SDK.
Not sure what advice to give, except to be mistrusting of exceptions stemming from the WP7 WCF stack, particularly EndpointNotFoundException and ArgumentNullException, and to have a full framework test client app around as a sanity check.
Luke
In desktop SL, I do it by sharing cookie container between service proxies in client http stack. Did not try this on WP7, but you may check this out.
First, you need to insert <httpCookieContainer/> in your client-side binding configuration (usually in ServiceReferences.ClientConfig).
In code, switch to client http stack.
WebRequest.RegisterPrefix("http://", WebRequestCreator.ClientHttp);
WebRequest.RegisterPrefix("https://", WebRequestCreator.ClientHttp);
Then you need to create a CookieContainer instance and assign it to all service proxies.
var cc = new CookieContainer();
var service1 = new ServiceReference1.MyService1Client { CookieContainer = cc };
var service2 = new ServiceReference2.MyService2Client { CookieContainer = cc };
Now, when your cookie container receives cookie, it will reuse it for all web services. Make sure, that cookie comes with correct Path setting.

WCF security between WinForms client and Shared Host webserver

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.

Resources