• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar
  • Skip to footer
TSB Alfresco Cobrand White tagline

Technology Services Group

  • Home
  • Products
    • Alfresco Enterprise Viewer
    • OpenContent Search
    • OpenContent Case
    • OpenContent Forms
    • OpenMigrate
    • OpenContent Web Services
    • OpenCapture
    • OpenOverlay
  • Solutions
    • Alfresco Content Accelerator for Claims Management
      • Claims Demo Series
    • Alfresco Content Accelerator for Policy & Procedure Management
      • Compliance Demo Series
    • OpenContent Accounts Payable
    • OpenContent Contract Management
    • OpenContent Batch Records
    • OpenContent Government
    • OpenContent Corporate Forms
    • OpenContent Construction Management
    • OpenContent Digital Archive
    • OpenContent Human Resources
    • OpenContent Patient Records
  • Platforms
    • Alfresco Consulting
      • Alfresco Case Study – Canadian Museum of Human Rights
      • Alfresco Case Study – New York Philharmonic
      • Alfresco Case Study – New York Property Insurance Underwriting Association
      • Alfresco Case Study – American Society for Clinical Pathology
      • Alfresco Case Study – American Association of Insurance Services
      • Alfresco Case Study – United Cerebral Palsy
    • HBase
    • DynamoDB
    • OpenText & Documentum Consulting
      • Upgrades – A Well Documented Approach
      • Life Science Solutions
        • Life Sciences Project Sampling
    • Veeva Consulting
    • Ephesoft
    • Workshare
  • Case Studies
    • White Papers
    • 11 Billion Document Migration
    • Learning Zone
    • Digital Asset Collection – Canadian Museum of Human Rights
    • Digital Archive and Retrieval – ASCP
    • Digital Archives – New York Philharmonic
    • Insurance Claim Processing – New York Property Insurance
    • Policy Forms Management with Machine Learning – AAIS
    • Liferay and Alfresco Portal – United Cerebral Palsy of Greater Chicago
  • About
    • Contact Us
  • Blog

Flex Applications and Security Constraints

You are here: Home / Adobe / Flex Applications and Security Constraints

June 30, 2010

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:

http://www.adobe.com/devnet/flashplayer/articles/fplayer10_uia_requirements.html

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">
<cross-domain-policy>
<allow-access-from domain="*.company.com" />
</cross-domain-policy>

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:

http://server:port/crossdomain.xml

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.

Filed Under: Adobe, Flex, OpenContent Forms, Tech Tip

Reader Interactions

Comments

  1. Cláudio says

    July 13, 2010 at 4:31 am

    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 i could get to it..
    I put the crossdomain.xml,

    I’ve tried

    tomcat/crossdomain.xml
    tomcat/webapps/crossdomain.xml

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

    Thanks

    Reply
  2. George Steimer says

    July 13, 2010 at 8:41 am

    Claudio,

    Try placing the crossdomain.xml file in:

    tomcat/webapps/ROOT/crossdomain.xml

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

    http://host:port/crossdomain.xml

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

    Reply
    • Claudio says

      July 13, 2010 at 9:47 am

      Hi.. The tomcat that I use is embebded on Alfresco and don’t hata webapps/ROOT folder. But it have a alfresco folder and I put there the crossdomain.xml..
      In the browser I can do http://alfserver.no-ip.info:8080/alfresco/crossdomain.xml
      and as you could see I’m getting the crossdomain.xml file..
      but..
      I’m using HttpServices and they still dont comunicate
      http://myaprendernanet.no-ip.info/teste/teste.html when I do Login.. can’t do the call..

      And when I run the Flex aplication from my computer It work fina but gives me

      Warning: Domain alfserver.no-ip.info does not specify a meta-policy. Applying default meta-policy ‘master-only’. This configuration is deprecated. See http://www.adobe.com/go/strict_policy_files to fix this problem.

      Error: Ignoring policy file at http://alfserver.no-ip.info:8080/alfresco/crossdomain.xml due to meta-policy ‘master-only’

      Any thoughts?

      Reply
  3. skapadia says

    July 21, 2010 at 12:35 pm

    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.

    Reply
    • Claudio says

      July 21, 2010 at 3:21 pm

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

      Thanks for the help…

      Reply
  4. Eric says

    September 6, 2010 at 7:50 am

    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!

    Reply
    • skapadia says

      September 7, 2010 at 9:18 am

      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:


      <mime-mapping>
        <extension>xml</extension>
        <mime-type>text/x-cross-domain-policy</mime-type>
      </mime-mapping>

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

      Reply
      • Eric says

        September 10, 2010 at 3:04 am

        Thanks!

        Reply
      • Keith says

        December 29, 2010 at 12:55 am

        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.

        Reply
      • George Steimer says

        January 3, 2011 at 4:02 pm

        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.

        Reply
  5. Cláudio says

    October 18, 2010 at 8:56 am

    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?

    Anyone?

    Reply
  6. George Steimer says

    March 31, 2011 at 12:49 pm

    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.

    Reply
  7. Cory says

    March 31, 2011 at 12:08 pm

    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?

    Reply
  8. Eric says

    May 18, 2011 at 5:54 pm

    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?

    Thanks

    Reply
  9. George Steimer says

    May 19, 2011 at 12:04 pm

    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.

    Reply

Leave a Reply Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Primary Sidebar

Search

Related Posts

  • Working with Adobe Flex and iframes
  • Active Wizard Flex Interface – Upcoming Enhancements
  • Documentum – What’s Next Updated for 2010
  • Creating Active Wizard Forms Outside Documentum – AWLite
  • Adobe Form Integration – Now Available from Active Wizard
  • Documentum and Alfresco – Electronic Forms and Workflow User Requirements
  • Adobe Livecycle and ActiveWizard Comparison
  • Documentum Transformation Services (DTS) – Alternative Approaches with Adobe LiveCycle and OpenOffice
  • Documentum Open Source Software
  • TSG Labs – Customizing Documentum's CenterStage Pro

Recent Posts

  • Alfresco Content Accelerator and Alfresco Enterprise Viewer – Improving User Collaboration Efficiency
  • Alfresco Content Accelerator – Document Notification Distribution Lists
  • Alfresco Webinar – Productivity Anywhere: How modern claim and policy document processing can help the new work-from-home normal succeed
  • Alfresco – Viewing Annotations on Versions
  • Alfresco Content Accelerator – Collaboration Enhancements
stacks-of-paper

11 BILLION DOCUMENT
BENCHMARK
OVERVIEW

Learn how TSG was able to leverage DynamoDB, S3, ElasticSearch & AWS to successfully migrate 11 Billion documents.

Download White Paper

Footer

Search

Contact

22 West Washington St
5th Floor
Chicago, IL 60602

inquiry@tsgrp.com

312.372.7777

Copyright © 2023 · Technology Services Group, Inc. · Log in

This website uses cookies to improve your experience. Please accept this site's cookies, but you can opt-out if you wish. Privacy Policy ACCEPT | Cookie settings
Privacy & Cookies Policy

Privacy Overview

This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience.
Necessary
Always Enabled
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Non-necessary
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
SAVE & ACCEPT