Hi: There are two solutions:
- Trust content from the host by setting up privileged locations prior to initiating the workflow. As a response to increasing security concerns, Adobe is recommending as a best practice that enhanced security remain enabled and that workflow locations be specfically trusted. For more information, see the quick key or FAQ here: http://learn.adobe.com/wiki/display/security/Application+Security+Library. The longer guide may also be helpful.
- Turn off enhanced security. While tuning a workflow that's already deployed may be annoying, do so is often a better choice than leaving yourself open to cross site scripting and other types of attacks.
These solutions are fine when the scenario exists for the sender of the documents to have any control over the recipients installation of Reader.
But consider this application:
Company A generates PDF Bills and e-Mails them to Company B's client base. For arguments sake let's say these are end consumers and not corporate. Now the Bill may be a static bill or it may contain some customer feedback information, such as a survey.
The information is entered into the form fields and submitted to a CGI script which returns an FDF containing key/value pairs indicating whether the survey was completed successfully, along with a confirmation number (generated at the server side).
With the new security restrictions, the customer will see the yellow popup when the FDF is returned (meaning that the receiving server already has the information). They then have the choice to trust this PDF or not (considering it is an emailed file, trusting once or always is irrelevant).
It's at this point that I think Adobe have overlooked the new functionality. I understand that not trusting the PDF should block the FDF contents from the form. BUT, trusting the PDF should allow the FDF contents to be injected, whether script or key/value pairs.
The problem is that the PDF is "re-opened" (best way I can describe it, as if there is a password on the file it is requested again). This means that not only does the FDF not complete it's action, but the form fields that the end-user inputted are all cleared, with no indication that the submission was successful or not.
From a customer point of view, it looks like an error or a bug. From a provider point of view, it means duplicate submissions at best, and probably an unwillingness to use the solution in the future.
Hi: You are correct. It wasn't clear to me which person in your workflow was experiencing the point of failure (lost data) and that you control one of the servers. Your solution can be solved with a server side fix. If you deploy a cross domain policy file on the server which trusts the other involved server you should be able to set up a viable workflow. For example, Server A could host a crossdomain.xml policy file that trusts http://serverB.com. Again, for details, see the cross domain documentation at http://learn.adobe.com/wiki/display/security/Application+Security+Library.
thanks, I understand that process as well,
but in this case, the PDF's are not hosted, they are sent via e-mail, so are local files essentially.
Do you see any other work-around. Is cross-domain policy even possible with local files in this scenario?
The solution here is to use a cross domain policy file to assign trust. Allow your clients (customers) to trust a pdf, fdf, xfdf, ect. by certifying the doc sent to the client and placing the fingerprint of the certificate used to certify the document to trust in the cross domain policy file.For example, if you returning an FDF with data to your customer's PDFs, certify the FDF and place its cert fingerprint in the cross domain policy file.
This technique is described briefly in the Enhanced Security Guide and more fully in the Cross Domain Security Guide. Both are located here: http://learn.adobe.com/wiki/display/security/Application+Security+Library.
The big picture is this:
Adobe turned on enhanced security by default to protect users’ machines and data. As with any security restriction, the protection has the possibility to break certain workflows that were designed to function in an unsecure way over a network. However, Adobe is providing several methods for establishing trust between files, folders, and hosts to enable these workflows while retaining a desirable level of security. Workflow onwer actions vary depending on the workflow components you control:
- When you control the clients: Pre-configure privileged locations.
- You control the server: Use a crossdomain.xml policy file.
- You control the entire workflow: Set up a certified document workflow where end users trust the signing certificate for privileged networked operations, configure privileged locations for all clients, use a crossdomain.xml policy file.
- You don’t control the client or server: In this case, you have to encourage users to do the right thing prior to interacting with your PDF. For example, prior to having end users fill out a form whose submittal will result in data returning back to that user, have them first trust your server as a privileged location.
These methods are described more fully here: http://learn.adobe.com/wiki/display/security/Application+Security+Library.