We recently moved our Silverlight app from Ria to ServiceStack. When deployed on a corporate network the client is intermittently throwing Proxy Authentication exceptions. Needless to say it works faultlessly in any kind of test environment. We never experienced any of these issues with the Ria version of our software which strongly suggests the issue is something to do with the ServiceStack silverlight .Net client.
In an effort to fix this we have moved from the ClientHttp to BrowserHttp. We have tried various techniques such as slowing down the frequency of api calls.
Our app is hosted at www.sitename.com/service, and is making calls via the Silverlight client to www.sitename.com/api. We have a cross-domain file in place that opens everything up but I don’t THINK what we’re doing is cross domain anyway.
There doesn’t seem to be any mechanism for telling the Silverlight client to use or not to use any particular proxy authentication.
Do you have any ideas what may be causing this, and any suggestions to resolve the problem?
It’s very difficult to provide much more because the app is running in a corporate network and we are an independent software vendor so we are not able to debug within the network. I have put basic debug windows in place and this is simply reporting Proxy Authentication as the error, that’s about all we can see at the moment.
I would be happy to give you a download link for the Silverlight app if this helps but can’t do this on a public board.
We initially used the ClientHttp version, this worked for a couple of users when tested but we quickly found it failed for others - we didn’t have the debug window in place at that point. We went to the BrowserHttp thinking this would pick up the proxy settings but it isn’t clear if this is happening. Sometimes the requests get through, sometimes they don’t.
I wish I could give you more to go on and I’m grateful for any suggestions. If it appears from the code that the client is not picking up the browser proxy, that would certainly be a clue.
The Silverlight Service Client is built on the same .NET’s HttpWebRequest that all .NET Service Clients use but of course Silverlight only supports a subset of that API as allowed by the constraints of the environment which it is run in.
Thanks for your suggestion. This doesn’t work for Silverlight I’m afraid.
I’ve done quite a lot of work on this over the last three weeks, much of it being spent setting up an environment with an authenticated proxy I can test against. My conclusions are as follows.
It’s nothing to do with ServiceStack. To prove this I built a very trimmed down data access class using HttpWebRequests where I had full access to all it’s methods.
Bottom line is that Silverlight’s ClientHttp stack does not support authenticated proxies. Even if you use the Silverlight RIA classes, if you change to ClientHttp stack these also fail.
The UseDefaultCredentials property on HttpWebRequest is for authenticating against the destination server using the curret windows credentials, it has no affect on the proxy authentication.
The full version of HttpWebRequest has full support for proxy authentication via the Proxy property, and that’s how you’d set up proxy authentication, except that this capability is specifically excluded from the Silverlight cut-down version of this class.
Your suggestion of setting the default proxy in a config file was worth a try but silverlight doesn’t have a app.config file or any equivalent. The closest is the ServiceReferences.ClientConfig file which is used to configure WCF service. I did try putting the system.net configuration in here, but I don’t think any notice was taken of it and it didn’t fix the problem.
This is very hard to test and easy to be fooled into thinking you’ve fixed it. IE will authenticate it’s connection when downloading the xap file, and that connection will be reused for your service requests. So actually it will appear to work until a second connection is created (eg requets from another thread or timeouts etc). This will receive a 407 authentication error, and its at that point that the requests will start to fail. This could be some minutes into the application lifetime.
The required behaviour when a 407 response is received (along with proxy authentication options NTLM, Kereros etc) is to go into a sequence of three requests for the same object, exchanging challenge / response tickets, then the third one will have a 200 code and return the object. The connection will then be reused for its lifetime so subsequent requests will work. So, I tried detecting this 407 proxy-authenticate header and simply reissuing the request three times, in the hope that something underneath might insert the challenge-response information. But it doesn’t, it just sends the same request three times with no auth info.
So the eventual conclusion is that Silverlight does not support authenticated proxies on the ClientHttp stack.
Switching to the BrowserHttp stack meant using my cut down Json service client rather than service-stack’s one, since plenty of the HttpWebRequest functionality is not supported on that stack. Specifically, you can’t set the Accept header or the basic authentication header on the get request, though oddly you can on the post request. I had also previously found various crashes occurring on the ServiceStack client if you tried manipulating cookies. However with the BrowserHttp stack, a cut down Jsonclient using ServiceStack’s excellent Json serializer and other utilities to convert servicestack services to Urls etc, and using only get and post, I’ve got a working solution. This does require that the ServiceStack licence is registered on the client, but that is fine once you realise.
My recommendation if someone wants to build a test environment to look further into whether clientHttp works on authenticated proxies is to get hold of a copy of forefront TMG, and set this up as an azure VM along with a DC and a client. this will only take a few days to get working, as opposed to trying to get squid to work on windows or authenticate with windows which will take several weeks to get partially working only to find out everything behaves completely differently when you put fiddler in the way. TMG is brilliant, why on earth have they discontinued it?
So that’s it, I thought I’d report my full findings as you’d been kind enough to look into this. Perhaps this will show up in a few search results because it seems nobody anywhere has ever posted a definitive analysis about silverlight clientHttp stack and authenticated proxies.
The real problem now is that I really wanted to use SignalR for push notifications, but when running out of browser this only works with the ClientHttp stack. So, more work to do.
I thought perhaps I’d missed something - there are various references around to the fact that BrowserHttp uses the IE proxy but clientHttp uses the OS proxy. I didn’t really understand what that meant but I recently found the netsh winhttp commands which as I understand it sets the OS proxy independently of the browser settings.You can also import the browser proxy settings into the OS : https://technet.microsoft.com/pt-br/library/cc731131(v=ws.10).aspx#BKMK_2
However in my tests, even though the OS proxy was “direct”, the ClientHttp requests would still honour the IE proxy. When I later imported the IE proxy into the OS via the netsh winhttp import command, and I set the IE proxy to direct, the clientHttp stack would again honour the IE proxy. The result was that the command would fail with a security exception because there I had blocked direct access at the client firewall. So this suggests that silverlight ignores the os proxy settings even on ClientHttp stack.
If I’ve misunderstood all this about the OS vs IE proxy settings please let me know - it may be the key to getting it to work. However it defeats the point of silverlight if you need to go to the desktop and mess about with the proxy settings.
wow epic analysis, thx! yeah I’m sure this will help others following in your footsteps trying to get Silverlight to work for their authenticated proxies.
Personally I think Silverlight is a dying platform that everyone should be planning their exit from, it’s destined to be forever shacked on a crippling sandbox and limited .NET profile where I expect it’s plagued with a number of corner issues like this.
On a related note have you checked at our new React Desktop AppsVS.NET project template It lets you package your ASP.NET Web App into a native Winforms Desktop App, native OSX Cocoa App or cross-platform Win/OSX/Linux Console App all in a single VS.NET template! It also includes the tooling to optimize, package and deploy your ASP.NET Web App with MS Web Deploy, Redis React is a good example of this that has downloads for Windows/OSX/Linux running on a users local Desktop or deployed remotely to our Live Demo on AWS at redisreact.servicestack.net
It lets you package your