Tags: | Categories: Blog Posted by admin on 3/9/2009 5:58 PM | Comments (5)

You have been using Silverlight for a while and by now you figure it out that to communicate outside your domain you need the crossdomain.xml file on the root directory of the domain you want to talk to, otherwise if Silverlight does not read that file with the policies, will return an exception on the request.

image

{System.Reflection.TargetInvocationException: An exception occurred during the operation, making the result invalid.  Check InnerException for exception details. ---> System.Security.SecurityException ---> System.Security.SecurityException: Security error.
   at System.Net.BrowserHttpWebRequest.InternalEndGetResponse(IAsyncResult asyncResult)

This is a restriction added in Silverlight that should be removed in my opinion as the work around is pretty simple and just slows down the request. Consuming data from the Internet is now with all social networks the most common task for an application. Restricting the user with making sure the crossdomain.xml is added into the domain just makes it frustrating for developers.

In order to avoid problems like that I added a proxy to consume any data from any domain with with a crossdomain file that looks like this:

<?xml version="1.0" encoding="utf-8" ?>
<cross-domain-policy>
    <allow-access-from domain="*" />
</cross-domain-policy>

 Creating the Cloud proxy

Open VS2008 and create a new cloud project, make sure, of course, that you installed the Azure SDK and Tools for Visual Studio 2008.

image

Just create a generic handler on the Web Role for the proxy code and publish the solution to your cloud account.

image

Click run and could take more than 5 minutes to start the application.

 image

Once started, check the temp website url is working, then you can promote it to your production website by clicking the icon in the middle of both.

image 

To make sure is working check http://al.cloudapp.net/ for a simple html page.

You are welcome to use it.

I added into Azure for anybody that wants to use it, this way, first I’ll be testing the Azure cloud as providing a service to fellow developers. I’ll leave the app running there indefinitely. So use that huge pipe to free yourself away from cross domain requests.

Add the to the beginning of your url path: http://al.cloudapp.net/proxy.ashx?

So to download an xml file from the web you do:

http://al.cloudapp.net/proxy.ashx?http://domain.com/page.xml

Please make sure to use it only for Silverlight development requests.

Vote NO on crossdomain policies for Silverlight.

If you want to vote no, please leave a comment on this blog. Enough people complains may the big guys up in their offices change their minds. In the mid time, use the proxy that will never return an exception for policy errors. As well you are helping test Azure and the speed of the cloud. With time, they would be many services installed there.

The C# Code

Just a normal proxy, nothing special here:

[WebService(Namespace = "http://tempuri.org/")] [WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)] public class Proxy : IHttpHandler { public void ProcessRequest(HttpContext context) { string uri = context.Request.QueryString[0]; if (uri.IndexOf("http://") == -1) { uri = context.Request.Url.Query.Substring(1); } System.Net.WebRequest req = System.Net.WebRequest.Create(new Uri(uri));
 req.Method = context.Request.HttpMethod; // Set body of request for POST requests if (context.Request.InputStream.Length > 0) { byte[] bytes = new byte[context.Request.InputStream.Length]; context.Request.InputStream.Read(bytes, 0, (int)context.Request.InputStream.Length); req.ContentLength = bytes.Length; req.ContentType = "application/x-www-form-urlencoded"; System.IO.Stream outputStream = req.GetRequestStream(); outputStream.Write(bytes, 0, bytes.Length); outputStream.Close(); } System.Net.WebResponse res = req.GetResponse(); context.Response.ContentType = res.ContentType; System.IO.StreamReader sr = new System.IO.StreamReader(res.GetResponseStream());
 string strResponse = sr.ReadToEnd(); context.Response.Write(strResponse);
 context.Response.End(); }
 

Related posts

The cloud for a fast deployment of proof of concepts

Having problems with Windows Azure Tools for Microsoft Visual Studio CTP, do you want a invitation for Azure?

Improve the performance of your ASP.NET application with Silverlight 2.0

Moving Community Server to the Cloud

Cheers

Al

Follow me in twitter | bookmark me | Subscribe to my feed | Check out GeoTwitter | Create GeoRss content

Posted from http://weblogs.asp.net/albertpascual

Comments

on 12/25/2008 4:41 PM

Al you should know better Smile


Do NOT vote yes on this. The restriction is there for a very good reason (Flash has the same thing btw).


If you have talked with the Silverlight Dev Team, You would quickly have realized that security is #1 priority on the team (they pretty much use it as an excuse for any missing feature Smile. I find it highly unlikely that they would consider dropping this restriction, and as you say, the workaround is very simple.


on 12/25/2008 7:57 PM

This in place for a very specific reason...security.  Yes, you can proxy around it, but then it is tracable to your server who make the request...when you allow it from the client, the requestor is not the server hosting the code but the client who is making the request. X-domain calls have been used in a number of areas to allow cross-site scripting attacks and this is there to limit that attack.


on 12/26/2008 12:54 AM

I was hoping we were past this by now. Lowering security on a Microsoft technology would be the best way to make sure that Silverlight gets the same fate as Java in big firms: forbidden, never used. Voting to allow cross domain access to Silverlight apps would be shooting a bullet in your own foot.


on 12/27/2008 10:56 PM

In this issue: Al Pascual, Damon Payne, Laurent Bugnion, Shawn Wildermuth, Jesse Liberty, and Jobi Joy


on 12/29/2008 8:08 AM

I'll also vote YES on cross domain security... however, there ARE issues out there that need to be addressed. The biggest one in my book is that it must be at the root, which is NOT what Flash provides... flash allows you you target a subdomain.


For an example of this usage, look into the API integration story for Picasa Web on Google. The root of their API domain only allows other google sites access, while there is a crossdomain.xml in a sub-path allowing global access to the services underneath it. This effectively blocks direct access via Silverlight, and I feel like we ought to be able to configure a specific link to use a more-specialized .xml file.


Comments are closed