These forums are now Read Only. If you have an Acrobat question, ask questions and get help from one of our experts.

Reader 9.3 security update kills FDF responses

Forum Index > Forms: Acrobat > Reader 9.3 security update kills FDF responses
2010-01-26 03:25:37
synergy
Registered: Feb 23 2007
Posts: 33

The latest security update from Adobe has serious consequences for anyone who is using FDF data from a server to communicate with the original PDF.

When data from a PDF form is submitted to a server script (from Reader - not reader in a browser window) it is common to get the server script to send an FDF response to inform the user that their data has been succesfully collected.

In Reader 9.3 the FDF response triggers a security warning and when the user accepts to trust the PDF document Reader appears to close the doc down and reopen it with all data wiped from the form before it shows the FDF 'succesfully collected' app response message.

Adobe really doesn't appear to have thought this through - their new security protocols may work fine with their big corporate intranets, where trusted URLs and trusted documents can be managed by in-house IT departments. But in the real world of sending PDFs with forms and multi-media built in, to new users, this process just looks 'wrong'.

Their is a history within Adobe of providing lots of interesting features within PDFs (Flash, 3D, Forms, Javascript etc) without actually providing full support for any of these features. I have been using Flash and forms and javascript and FDFs in PDFs since Acrobat V6 and it has never been easy as it should have been. For the past couple of years Adobe has been promoting PDFs as the next generation interactive digital document. Reader 9.3s enhanced security has in my opinion hobbled most of the progress that has been made and could be a death blow to general acceptance of 'smart PDFs' outside of the corporate environment.

Try this link for another post on the FDF problem: http://forums.adobe.com/message/2532190#2532190

There are further issues with Reader 9.3 and media files that I will post on the appropiate forum.

Top
2010-01-28 01:07:02
#1
ssv09
Registered: Jan 13 2010
Posts: 9
Please refer to solutions provided in http://forums.adobe.com/message/2532190#2532190
Top
2010-01-28 04:10:50
#2
synergy
Registered: Feb 23 2007
Posts: 33
Hi ssv09,

Thanks for the link.

I tried the xml cross domain policy route that the link refers to last year when Reader/Acrobat 9 came out. After much effort and the advice and help of Thom Parker no less, we all concluded that as far as using this option in a standalone Reader situation - it didn't work, regardless of what the documentation said.

The new documentation for Reader 9.3 is much better than was available then, but I still can't get it to work as a standalone Reader situation where the user has opened a PDF email attachement. The documentation states:

3.1.5 PDFs in a standalone application vs. the browser

PDF viewed in a standalone application: When the application runs outside of a browser, such as viewing a document on a local file system or opened as an attachment in e-mail, data requests from an http[s] server is blocked. A check is always required (the server must have a cross-domain policy file containing a wild card or the local file must be in a privileged location).

It also states in a table 2 before this entry:

PDF Location: c:\test.pdf
Received data location: http://xyz.com/xyz.data
x-domain required? Yes
allow-access-from domain examples: Use certificate fingerprint

Does this mean that to ensure an server response to a form submit from an emailed PDF opened in Reader 9.3 that I now need both the x-domain policy and a certificate fingerprint?
Top
2010-01-28 11:48:09
#3
nixopax
Registered: Feb 6 2009
Posts: 105
Hi Synergy,

I too have been developing PDFs that are for real world situations. 'In the wild' being the phrase I like to use. The PDFs have video, flash, quicktime VRs, 3D models, and forms with database interaction with FDF data injection and FDF javascript injection. The 9.3 and 8.2 security update have effectively killed everything. In the past couple days I've figured out some workarounds that prevent the yellow security warning strip at the top when submitting. I wholeheartedly agree that the documentation doesn't do what it says. We've been in talks with Adobe about this issue, and despite having a certificate securing the document from the Keynectis CA and a crossdomain policy, there is no effective way to inject FDF without a warning. However, if it's just a response that the submission happened, then you don't need to inject into the PDF via FDF although it's the nicest way, as it's seamless for the end user. I'm working on a workflow for this and documenting it.

In response to your question:
Quote:
Does this mean that to ensure an server response to a form submit from an emailed PDF opened in Reader 9.3 that I now need both the x-domain policy and a certificate fingerprint?
As far as we've tested, it no longer has any further benefit to give us privileged FDF data/javascript injection. Including the SHA-1 hash from your certificate in your x-domain policy does nothing, and responding via SSL over HTTPS still throws warnings.
Top
2010-01-29 07:55:43
#4
synergy
Registered: Feb 23 2007
Posts: 33
Hi Nixopax,

Thanks for the reply - it's nice to know that there are others out there who are not only doing the same kind of PDFs as me, but also facing the same problems.

The FDF response from a server script into a PDF in Reader 9.3 appears to only work without security alerts when the PDF is being viewed in a browser and when a cross-domain xml setup has been done. As for working in a standalone version of Reader, there probably little hope that Adobe will listen to anyone other than their enterprise clients so the days of an enjoyable multi-media experience in a PDF for anyone outside a corporate intranet are over for the time being.

Thanks also for the info about the certificate solution - that was going to be my next line of enquiry.

Please keep in touch if you find any workarounds.


PS: What really annoys me about the implementation of the new security is that as far as a PDF acrobat form is concerned the result is so clunky.

You press the submit button, Reader gives you the security warning about accessing a URL pops up and after clicking OK the BIG Yellow Security warning bar pops up - you then click OK to trust the PDF once and Reader 9.3 then closes the PDF and re-opens it, at the same time deleting whatever data you were trying to submit in the first place!

Whover at Adobe thought that this was a cool and easy way to handle the submission of data from a PDF form from Reader to a server is either dumb or insane or posssibly a little of both.
Top
2010-01-29 14:22:35
#5
nixopax
Registered: Feb 6 2009
Posts: 105
synergy wrote:
PS: What really annoys me about the implementation of the new security is that as far as a PDF acrobat form is concerned the result is so clunky.You press the submit button, Reader gives you the security warning about accessing a URL pops up and after clicking OK the BIG Yellow Security warning bar pops up - you then click OK to trust the PDF once and Reader 9.3 then closes the PDF and re-opens it, at the same time deleting whatever data you were trying to submit in the first place!

Whover at Adobe thought that this was a cool and easy way to handle the submission of data from a PDF form from Reader to a server is either dumb or insane or posssibly a little of both.
Oh man, that really annoys me too, because the FDF response is lost when Reader re-opens the document, so you have to submit again, resulting in duplicate entries. What I'm thinking would be a good workflow for that issue is before any form input has happened, usually at the opening of the document, you initiate a security warning, and have the person accept, this will re-open the document, and they go about their business as usual. An extra step, but better done at the beginning. It's much like downloading something from the internet using Internet Explorer. The security bar pops up at the top, and then you have to accept, and it reloads the page to restart the download.

I'm compiling a few example documents to display how I'm going to deal with this update.

synergy wrote:
Thanks for the reply - it's nice to know that there are others out there who are not only doing the same kind of PDFs as me, but also facing the same problems.
Likewise, I'm glad to hear we're not the only ones that use PDF to its fullest potential outside of the enterprise division. Dynamic media could be so much more if we didn't run into these road blocks like this. Forms are such an integral part of PDFs that it's unacceptable that they've put these constraints on such a broad spectrum of data injection. I'd have approached this by simply blacklisting the functions I haven't closed the memory leaks on.
Top
2010-04-01 04:51:21
#6
Tony_B
Registered: Apr 1 2010
Posts: 18
I'm having the exact same problems.

Tony
Top