I am using WebClient to download some resource in following way:
Stream stream;
try
{
WebClient webClient = new webClient();
stream = webClient.OpenRead(MyResourceUri);
}
catch (Exception)
{
return null;
}
return stream;
When I do this in a WPF application, it works fine and proper stream is obtained.
When I do this in a WCF service call, it doesn't work. A WebException is thrown with message "Unable to connect to remote server". (It works for files hosted on my machine or within company network, however it fails for any resource on web). The service is hosted on IIS7.
Investigation so far reveals the difference is because of the webproxy. The webclient.proxy in WPF application refers to the proxy settings as set in IE, whereas the one in WCF is having none.
Why is it so? And more importantly, how can I make the WebClient in WCF use similar proxy settings?
EDIT: I set the proxy on WebClient and it worked in WCF service
webClient.Proxy = new WebProxy(ProxyAddressFromIE);
Here I have hardcoded the proxy addess. What method/APIs are there to obtain one? And still why its different in WCF service & in WPF application?
To answer one of your questions, the reason there is a difference between your WPF application and your IIS hosted WCF service is this.
WPF applications run in an actual Windows session (your user session to be exact). This means there is a user profile loaded for that session and that session contains, amongst other things, the proxy settings as configured in IE.
WCF services hosted in IIS do not run in a Windows session. They are run as a service and therefor do not have a Windows session (they actually run in session 0, but that's just an implementatio detail). This means there is no proxy configuration.
To reliably solve this, you could have your own configuration for a proxy, perhaps in web.config.
Another option is to configure the proxy through netsh.exe.
I needed to do the exact same thing, and I found the answer here: Get the URI from the default web proxy. Basically, you need to dynamically read the proxy using WebRequest.GetSystemWebProxy() and by determining the proxy using a test proxied url.
Hope this helps!
Consider handling the call using sources other than the highly abstracted WebClient. From the higher to lower level, this means exploring WebRequest and WebResponse objects all the way down to programming off the socket. The reason is the WebClient method is tightly coupled to choices in Internet Explorer, as much of the high level Internet stack is in windows. If you want to get around this, you need to dig deeper.
I would love to point a finger at precisely where to dig, but I have not incurred this particular issue and have no experience solving. I know where to look for the answer, but no specifics on "X marks the spot". Because of the high level, highly abstracted nature of WebClient, however, I am not sure you can easily get around the implicit creation of the stack and/or the coupling with IE, without more headaches than punting and using an object that gives more explicit control of HTTP communication.
Happy hunting.
Related
I'm a WCF newbie, and I need some help to begin with a project:
I will have a managed application (server) that needs to communicate (messaging system) with several clients over the internet and vice versa.
What is the best approach to achieve this?
using wsDualBinding?
UPDATE
I decided to use the NetTcpBinding mode instead.
It depends on what capabilities your service needs to expose, and what type of clients you need to support. Any of the HTTP-based bindings will work over the internet, its simply a question of the way the data is encoded.
A summary of the built-in bindings and what they support can be found here: http://msdn.microsoft.com/en-us/library/ms731092.aspx
But the most common are:
BasicHttpBinding - This is a basic web service-style binding, usable by any SOAP client.
WebHttpBinding - This allows your service to be used by non-SOAP HTTP clients
WsHttpBinding - This allows your service to use extended service features like transactions and sessions.
WsDualHttpBinding - This is required if your service needs a duplex channel, meaning your service needs to make callbacks up to the client.
Since you specifically asked about the dual binding:
If you are writing an application that needs to be able to make a callback from server into the client, then a dual binding is really your only option. Since you specifically mentioned chat, however, I don't think a dual-channel service is going to work very well.
The way the callbacks work in WCF is that your client makes a call to the service, using a dual channel, and must provide an implementation of the callback interface. The server can use this to make calls to the client for the duration of the service method call; the callback context is per-service-call, so once that call returns, it is no longer valid. In other words, your server cannot just asynchronously "call into" your client, it has to wait for the client to "poll" the server. And if you're going to do that, you don't really need the callback anymore.
Honestly, I don't think I would use WCF for an interactive bi-directional chat application, but I can think of two possible options to do so:
Do the polling client option, using a simple BasicHttpBinding on the server and continuously ask for new messages.
Set your client applications up to self-host a local WCF service, and provide the endpoint information to the server when you log in. This requires your clients to accept incoming connections, which gets messy (but if you can pull it off, I'd go for a NetTcpBinding here.)
WSDualHttpBinding is not a good choice for internet. Callback works great only in local network (intranet) that has no Firewall and NAS restrictions.
See this post for more details:
Connecting over internet to WCF service using wsDualHttpBinding times out
Use WsHttpBinding if you want to set up server to server communications (that should work for WPF).
Use WebHttpBinding if you are planning to use data from Javascript.
I have a WCF Service that I want my client to be able to consume from IIS without going through a proxy. The client was consuming asmx service in vbscript using the htc behavior:
<div id="oWSInterop" style="behavior:url(webservice.htc)"></div>
oWSInterop.useService "http://localhost/WSInteroperability.asmx", "WSInteroperability"
Set response = oWSInterop.WSInteroperability.callServiceSync("BuildSingleDoc", 1002, 19499, XMLEncode(sAdditionalDetail))
So basically I just want to make this work with making as few changes as possible on the existing client. Am I forced to use a proxy (that is, a class on the client side that exposes the operations in the WCF service) when consuming a WCF service? I do understand the benefits of a proxy and am not opposed to using it for most other client implementations, but in this case I'm not sure I have the time to deal with it on the client - i just want it to work the way it has been with only the endpoint changing.
A client-side proxy class to call the service?
Yes, you definitely need that (unless you do REST-based WCF services, which you can call with a HttpClient alone) - that's where the whole WCF runtime lives and does its magic.
If you want to call up REST-based services, you can do this without any proxy whatsoever - but then you're left to do XML or JSON parsing yourself. It can be done, but it might not be such a great idea.
What's the problem with the proxy?? It's really just a small wrapper that bundles up your calls into a serialized message and sends it to the server side. No big harm, in my opinion....
What are you seeing? What makes you thank that proxy is an issue? If that is server-side code, it should use the browsers settings (WinINet) which should work fine. Perhaps the "localhost" would be an issue, though, since to the client that still means "talk to yourself" (i.e. not the server).
If that is server side you'll probably need to configure WinHTTP appropriately; in particular, to skip the proxy for local addresses. Of course, "localhost" should loop-back anyway...
I have a Windows Service that is self hosting a Wcf service, this Wcf service has a tcpBinding with default settings. The Windows service is running as LocalSystem.
The Wcf Service is referenced (default settings) by a Web application that is running in IIS 7.5 integrated pipeline within it's own application pool with its own identity.
Both are running on the same machine.
All is working fine, except that when in the Wcf Service when I check the identity of the current thread with:
Thread.CurrentPrincipal.Identity.Name
It returns the user of the Application Pool of the Web Application.. this is not what I expect. It looks like some sort of impersonation is going on in the Wcf service.
Is this standard behavior? I can't find any documentation on this.
And does it mean that when I try to access a database in the Wcf service i'm introducing a identity hop?
Edit, the config on service side:
Type serviceType = typeof(WcfService);
host = new ServiceHost(serviceType);
Binding tcpBinding = new NetTcpBinding( );
Uri tcpBaseAddress = new Uri("net.tcp://localhost:8001/Test");
host.AddServiceEndpoint(typeof (WcfService), tcpBinding, tcpBaseAddress);
host.Open();
On the client side:
NetTcpBinding tcpBinding = new NetTcpBinding(SecurityMode.Transport);
windowsService = new WindowsService.WcfServiceClient(tcpBinding, new EndpointAddress("net.tcp://localhost:8001/Test"));
I'm reading from Learning WCF by Michele Bustamante. I have used WCF for an application that I've refactored and we're interested in using WCF in new applications for the flexibility it offers. One of the downsides of WCF is that it can be tricky to use the .net attributes or .config files to get the settings just right. I have spent days tracking down issues with the WCF settings. I've even created automated tests that will check that my service runs the way it's supposed to.
In response to your question, Michele says very specifically in Chapter Seven that NetTcpBinding is secure by default, meaning that callers must provide Windows credentials for authentication. I believe that would explain why the thread appears to be running as the identity of the web service. This is to protect your service from being called by an unauthorized user.
I believe that the following quotation from pp. 419-420 will answer your question concisely. "If you are familiar with traditional .NET role-based security, you know that there is a security principal attached to each executing thread. That security principal holds the caller's identity, which may be tied to a Windows account or a custom database credential, and its roles."
That seems to state plainly that yes, this is standard behavior.
I believe that you can change the behavior through attributes and .config files. I recommend you get a good book on the subject. I spun my wheels in the sand a long time trying to get bits and pieces of information about WCF from the web.
To clearify:
I was checking the wrong property here. Because code would be executed under the WindowsIdentity.GetCurrent() identity.
By default this is NOT the same as the caller (which is in Thread.CurrentPrincipal.Identity). If you want this behaviour you can control this with:
host.Authorization.ImpersonateCallerForAllOperations = true;
and
[OperationBehavior(Impersonation = ImpersonationOption.Required)]
We actually have integrated security set at the website, and then any calls from the website to the WCF service we wrap in:
using (((WindowsIdentity)HttpContext.Current.User.Identity).Impersonate())
{
That makes sure the credentials of the logged in user are passed through, rather than the IIS app pool credentials.
Works like magic!
More information is needed, but I'm guessing that it's somewhere in the configuration for the binding on either the server side or the client side that impersonation is enabled. When adding service references, svcutil.exe is VERY aggressive in setting EVERY possible binding property in configuration.
If you could provide more information for the configuration on the server and client side, it would be appreciated.
I'm using WCF through Spring.net WCF integration link text
This works relatively fine, however it seems that WCF and Spring get in each other's way when instantiating client channels. This means that only a single client channel is created for a service and therefore the clients get a timeout after the configured timeout is expired since the same client channel has been open since it was instantiated by Spring.
To make the matters worst, once a channel goes to a fault state, it affect all users of that service since spring doesn't create a new channel for each user.
Has anyone managed to use WCF and Spring.net work together without these issues?
I've created a small library to help you with Spring.NET in these circumstances. You can find the svn repo here. More info can be found on my blog.
I am validating users using the UserNamePasswordValidator.Validate(string username, string password) and the service is hosting itself (e.g. no IIS).
The problem I have is that if the user fails the validation I want to track the users IP address. This works fine of the user gets validated, because then the OperationContext has been initialized (it is null inside the validate method and not created until later).
Does anyone know how to get the clients IP address either in the validate method or before the validate method has been executed?
Yes, I know about how to get the IP address using RemoteEndpointMessageProperty but like I said, it never get that far if validation fails :-)
I've researched this to death all week, and I can't come up with a single blog entry or MSDN article that deals with the issue.
As far as I can tell, you cannot log IP address during the Validate stage.
The only workaround I can suggest is to host in IIS and use the weblogs there, which do log IP address. It's painful, unfortunately, but it may be the only way.
If you're hosting in IIS then this becomes much more simple. This chunk of config comes straight from my hosting web project and forces ASP.NET requests to come down the IIS pipeline rather than being dispatched straight to the ASP err bits of IIS.
aspNetCompatibilityEnabled: When this attribute is set to
true, requests to Windows Communication Foundation (WCF) services
flow through the ASP.NET HTTP pipeline, and communication over
non-HTTP protocols is prohibited.
See: http://msdn.microsoft.com/en-us/library/ms731336.aspx
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
I use the AuthenticationService and make use of the HttpContext to get at all the interesting stuff about the client, much of it is useful for things like ensuring a user isn't logging in from six different subnets as well as playing around with cookies.
Although I think this is applied to the MS AuthenticationService, any other services you have will need this attrib:
[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
If you want to pursue your non-IIS hosted service route, then I'd see what stuff is available inside the MS API using reflection, poking around on a WCF with the debugger while stopped, unfolding all those Non-public members.
I suppose the problem will be getting a reference to a bit of WCF which is initialized from which to start poking. You might have to register some kind of listener to one of the dispatchers when you setup the service host.
http://msdn.microsoft.com/en-us/library/system.servicemodel.dispatcher.channeldispatcher.aspx
Edit:
Adding this link as my thoughts are that you'd need to get at stuff in WCF that's right down the stack before it gets to your code:
http://blogs.msdn.com/sonuarora/archive/2007/06/11/passing-soap-actions-to-adapter-inbound-handler-for-filtering-type-of-listeners.aspx