Flex Applications and Security Constraints

To give an update on the Active Wizard Enhancements we were working on last  month, we recently finished up all development and testing of the Flex-based checkin/checkout interface against Documentum. We delivered to our client this week, but I wanted to share some of the challenges we ran into, specifically related to running an application using Flash.

At first, this interface seemed like it would be a straightforward implementation, as we thought about just giving the user a Save As dialog box upon clicking Checkout, to save and edit their content, and an Open dialog box upon Checkin, to browse to their new content. However, things became a little tricky because our design did not popup the Save As dialog box immediately after the user clicked Checkout. In the backend, upon clicking Checkout, we would call our web services layer, OpenContent, to communicate with Documentum and check out the document at the repository level. The web services layer would get the content of the document from Documentum first, and then go back to the Flex side and launch the Save As dialog box.  Due to this design, the Flash player was not allowing us to popup the dialog box since it was not a result of a direct user input event. It was a result of the content coming back. This is a restriction that was introduced as part of Adobe Flash Player 10 and is part of a larger group of constraints that are known as UIA (User-Initiated Action) requirements.  For more information about the changes in Adobe Flash Player 10 that address security, visit the following link:


We found that the only way around this was to alter our design a bit. There wasn’t much we could do within our browser to turn off this security constraint, or anything programmatically within the application to make an exception for this case. What we ended up doing was creating an intermediate Save button that would appear after the Checkout was completed. At that point, the content would already be in memory from Documentum, and when the user clicks Save, all we would need to do is popup the Save As dialog box. Since there were no more intermediate calls or actions from the time the user clicked Save to the time the Save As dialog was launched, the Flash player had no complaints about this.

The other security constraint we noticed was that Flash does not allow you to host a SWF on one domain and have it read data from another domain. In order to accomplish this, you have to add a crossdomain.xml file to the root directory of the web server. This crossdomain.xml specifies what domains are allowed. For example, it would look something like this:

<?xml version="1.0"?>
DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<allow-access-from domain="*.company.com" />

On the Apache Tomcat web server, you can drop this XML file into the ROOT web application for it to take effect. However, in the IBM WebSphere Application Server, we had to create a crossdomain.war file that contained this XML file and replace the default root application in WebSphere, with our crossdomain application.

Regardless of what web server you are using, the best way to test that your crossdomain.xml is in the right location is to navigate to the following URL:


If this serves up the content of your crossdomain.xml, you’ve deployed it in the right location.

Please contact us for any questions regarding our Flex solutions.

15 thoughts on “Flex Applications and Security Constraints

  1. Hi.. I’m having a problem and the search to the answer lead me to this article..
    I’m working with Alfresco that runs on a tomcat server.. And I have a FLEX aplication that acess alfresco.. When I debug the aplication with flexbuilder it runs ok but when I export it to a server and try to acess it could’nt comunicate. I tried to put the crossdomain.xml on the root os tomcat but i’m getting nothing.
    Wen I do http://alfserver.no-ip.info:8080/crossdomain.xml i could get to it..
    I put the crossdomain.xml,

    I’ve tried


    If you have an idea of what i am doing wrong.. please let me know..


  2. Claudio,

    Try placing the crossdomain.xml file in:


    You should then be able to retrieve the XML by pointing a browser to:


    If you put the crossdomain.xml in the ROOT webapp, can your browser see the XML file?

  3. Hi Claudio,

    You may want to try adding the following to your crossdomain.xml:

    <site-control permitted-cross-domain-policies="all" />

    This will allow other policy files besides the master policy file to be used.

    • Hi George,
      I just fixed the problem by adding the ROOT folder to Tomcat and put the crossdomain file there..

      Thanks for the help…

  4. Hi, I’m deploying my app on Websphere but I don’t know where to place the crossdomain.xml? You mentioned we had to create the war files contains the crossdomain.xml. Could you pls guide me how to create it or any avaliable document? Thanks!

    • Hi Eric,

      In order to create a crossdomain war, you’ll need the actual crossdomain.xml as well as a folder called WEB-INF with a web.xml inside of it. The web.xml should have the following MIME mapping configured:


      You can then zip up the folder and the xml file, and rename the resulting .zip file to a .war file.

      • Stumbled across this answer while dealing with the new policy issues for one of my sites. Do you happen to know if there’s a Tomcat way to specify MIME type for a specific file rather than all files with .xml extension? I want the ability to continue serving legit XML files with the right content type.

      • Keith – skapadia’s answer above is specific to creating a crossdomain.war file for use in a WebSphere container. As far as I know, we’ve never had to do this in Tomcat. We just simply drop the crossdomain.xml in the {tomcat.home}/webapps/ROOT folder.

  5. Hi…

    I don’t know if my problem is related to this..
    I am using a url request to upload files from flex aplication to alfresco…
    Everything works well when I debug on my pc.. but when I put it on my server it gives me an Error #2038…
    Could this be related to my crossdomain?


  6. Good article but this policy is just stupid. I can understand the security concern of not wanting a flash app to send data to a server without user knowledge but there should have been another way to accomplish this by perhaps prompting the user because we have an app that sends snapshots from a webcam to a server on a periodic basis from a Timer. This appears to be a deal killer…..

    Any known workarounds?

  7. Cory,

    Are you talking about the UIA restrictions or the need for a crossdomain.xml? If you’re talking about UIA, then I think this quote from the adobe devnet article mentioned in the post sums it up nicely:

    “This restriction avoids the problem of a web page making a call to upload or download files from the user’s machine without the user explicitly agreeing to such an action.”

    I think that’s a great policy – I don’t want some random flash movie downloading files to my machine without my consent.

    If you’re talking about the need for a crossdomain.xml, then it shouldn’t be a deal breaker. If you have control of the server that you’re posting snapshots to, then just create a crossdomain.xml that allows access. If you’re posting to something like Flikr, there’s already a crossdomain.xml located at: http://api.flickr.com/crossdomain.xml.

  8. I am trying to create a flex app that will call remote objects on a Websphere server and I am getting the crossdomain.xml error.

    I create the .war file that is mentioned above but how do I add this to an existing project in Websphere application developer IDE to test it?


  9. Eric,

    We don’t use WebSphere for development, so I’m not sure how you would deploy it in WebSphere’s application developer IDE. You just need to get the war deployed as the root application, so that when you access http://yourserver:yourport/crossdomain.xml, the XML is visible.

Comments are closed.