SSL, crossing domains, and Flex

Flex is a great tool for building applications. It almost makes you forget that you’re constructing something for the web. That is, until you hit a dreaded cross-domain issue. In my case, I’m using Google Accounts to authenticate my app’s users. Most of the time, I don’t have cross-domain issues because I call C# web services on my server and allow the service to handle all of the calls to anything outside of my own domain. In this case, however, because I was dealing with security, I had to make a cross-domain call directly from my Flex app.

For many developers, this wouldn’t need to be a cross-domain call, but my internet host provides SSL to my site from a completely different domain, and to make matters worse, I don’t have access to the server that hosts the SSL.

My Flex app runs from a non-SSL domain. During the login process, it needs to contact the SSL server and pass the Google Account information. The contact to Google is performed through my C# web service. Everything works great when I run the application from my localhost, but when it gets moved to the server — security kicks in and because the calls are cross-domain, they are no longer allowed.

At that point I had a couple of options:

  • Run my entire app from the SSL domain. – I didn’t want to take the performance hit and I already had everything working in the current domain.
  • Setup a crossdomain.xml file that would enable access across the non-SSL and SSL domain. – This sounds like the obvious choice, but there were quite a few hurdles to figure this one out.

The problem with setting up a crossdomain.xml file on the SSL server is that I don’t have access to the server. It’s just pointing to a virtual root on my server and I don’t have access to the SSL server’s web root.

The default behavior is for Flash to look for the crossdomain.xml file in the web server root. Luckily, I was able to find a command that allowed me to specify an alternate location for the crossdomain.xml file. Once I setup the file on my web server and implemented the code change, everything worked as it should.

Here’s a dummy version of my crossdomain.xml file. Note the inclusion of the [secure="false"] attribute. This is required when using SSL. Otherwise, the https protocol would not be allowed.

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<allow-access-from domain="*.my-non-ssl-domain.com" secure="false" />
</cross-domain-policy>

In my ActionScript, I had to include the following line of code to point Flash to my crossdomain.xml file:

flash.system.Security.loadPolicyFile("{Url to my crossdomain.xml file on the SSL virtual root}");

With these changes in place, I’m able to easily integrate Google Accounts with my Flash app.

Technorati Tags: , , , , , ,

  • Share/Bookmark

4 Comments so far »

  1. John Wood said,

    Wrote on April 3, 2008 @ 7:59 pm

    Great info! Thanks for sharing it!

  2. Erich Cervantez said,

    Wrote on October 27, 2008 @ 2:31 pm

    Dumb question, but in the crossdomain.xml file you specified:

    *.my-non-ssl-domain.com

    For non-ssl localhost, can this remain as is or does it need to change (I dunno, say to “localhost”)?

  3. Shannon Whitley said,

    Wrote on October 27, 2008 @ 3:03 pm

    Hi Erich,

    It’s been awhile since I wrote this, but I believe you’d substitute your regular domain in place of “my-non-ssl-domain.com”

    For example, this website’s file would look like this:

  4. mike said,

    Wrote on June 29, 2010 @ 9:10 pm

    Thanks mate, this helped me out when I was a bit confused. Cheers from Melbourne

Comment RSS · TrackBack URI

Leave a Comment

Name: (Required)

E-mail: (Required)

Website:

Comment:

Twitter Users!
Enter your personal information in the form or sign in with your Twitter account by clicking the button below.