Javascript Submit PDF FOrm Hide Response

[defaultok2tfbprdete]

Hi,

We are using the below Javascript code to Submit the whole pdf to the server.

try {
this.submitForm(
{
  cURL:'{URL}',
  cSubmitAs: 'PDF'
});

} 
catch(e) {
app.alert({
	cMsg: 'Save Failed'});
	}

Currently we are returning the server reponse as application/vnd.fdf format which is causing trust issue.

The FDF response is showing trust issue in Abode.

We also tried plain text return from Server (like "Save Successful"). But in Abode we are getting empty alert.

Is it possible to hide the submit response in abode so that the end user will not get trust issue or empty popup?

[try67]

Just don't return anything...

[defaultok2tfbprdete]

Hi @try67 ,

Tried no response from Server. But in Adobe we are getting this error on submit.

Could you please share an example.

[ls_rbls]

Hi,

You might've come accross this link before:

• https://helpx.adobe.com/ca/acrobat/kb/acrobat-forms-form-data-web.html

And I am curious with a couple of questions:

• What server OS  and version are you on?

• How are the file uploads validated and filtered at the server-side level?

• Is that PDF sent as an FDF to  a web server or a web app?

• What method  is collecting and parsing the data entered by the user in that form?

• How are the file uploads validated and filtered at the client-side (if any)?

• Where is the script executing from in your PDF (.i.e. a Mouse-Up event button, a document-level script? Any global variables in that script? )

Can you share the entire script and explain in  detail the desired workflow ?

[defaultok2tfbprdete]

Hi,

We are using Windows Server and the Server side language is C#. Please find the Server side code while we return FDF response. This response is causing Trust Issues in Abode.

        [HttpPost]
        [Route("receivepdf")]
        public async Task<IActionResult> ReceivePdf()
        {
            var inputFilePath = @"D:\AbodeFile";
            string inputFile = $"{inputFilePath}\\{Guid.NewGuid().ToString()}.pdf";
            using (StreamReader reader = new StreamReader(Request.Body, Encoding.UTF8))
            {
                using (FileStream outputFileStream = new FileStream(inputFile, FileMode.Create))
                {
                    await reader.BaseStream.CopyToAsync(outputFileStream);
                }
            }

            var fdfResponse = @"%FDF-1.2
1 0 obj
<</FDF
<</Status (Submit was Successful)>>
>>
endobj
trailer << /Root 1 0 R >>
%%EOF";
            var content = Encoding.ASCII.GetBytes(fdfResponse);
            var contentType = "application/vnd.fdf";
            return File(content, contentType);
        }

•  We correcting the entire pdf from the user on Submit. We are updating the PDF in our server each time the User Submitted the Form.
• We are using Mouse up event for PDF Submission.
• Please find the Client side Javascript code we used for the Submit Button.

try {
this.submitForm(
{
  cURL:'{URL}',
  cSubmitAs: 'PDF'
});

} 
catch(e) {
app.alert({
	cMsg: 'Save Failed'});
	}​

I have attached a sample PDF we used.

[ls_rbls]

Hi,

I don't have the capability to fully test this scenario back at home or at work, but I think I've been able to identify two things that are not exclusively tied up to each other.

I believe that both of the issues identified here are confused interchangeably.

For example:

* Issue 1- Returning a server-side response in real-time to an opened PDF document that is hosted securely in the client's Adobe Acrobat program

* Issue 2- Suppressing the built-in security warnings and alerts in the client's Adobe Acrobat host program

I'll begin by identifying first Issue 2:

* The client-side script may allow user-console level messages, but the same is not true when you try to suppress the built-in JavaScript core security warnings and messages through a non-privileged Acrobat JavaScript scripting context.

Furthermore, Issue 2 forks into two other considertaions of interest:

* Issue 2A - To completely suppress the built-in security warnings and messages, it has to be done manually at the operating system level by editing registry preferences on each client.

This, however, may be accomplished in bulk at the domain-level and enforced with GPO.

In order to succeed you may need to deploy a custom installation of Adobe Acrobat Pro on each client and define a group policy template with the modfied registry keys for each client... not a trivial task!

In addition, how this will benefit your tech-support staff or administrators if they ever have to log issues and back-trace  potential errors without the feedback of your power-users?

* Issue 2B - If server-side external data (i.e. coming from a web server) is trying to write back to the client's host Acrobat program to produce a pop-up alert in the client's PDF document, that is not going to work with your current method.

In other words, the file that the clients are submitting may have read-only access by default, for example.

Assuming that this would be possible to do, your server-side script may need to include a line of code to explicitely state something that interacts with  "FileAccess.Write" enclosed in the "FileStream()"  function (but this is not my lane... just guessing in the blind).

Which brings me to move forward with Issue 1:

* Issue 1 - I am not clear if you've implemented any Web API through whatever .Net core you're deploying in C#.

If we assume that this may be possible, the main question would be:

• How can we make it interact with the Acrobat JavaScript aspects of the app.alert()

• Specifically if such script  would be able to include the app.alert() function inside of an "app.trustedFunction()" or in combination with "app.trustPropagationFunction()" in order to elevate the privilege context of the  "FileAccess.Write" portion of that C# script (which should also include a way to elevate the Acrobat's document-level context for the PDFs message handler).

That layer of security right there is enforced by the client's host Acrobat program. And to be honest I don't think this is possible.

Perhaps, with a folder-level script installed at the client-side, by which the host Acrobat program may allow the client's PDF document to call for such function (assuming that the document's Disclose property is set to true... just another guess in the blind).

I don't think that this is even remotely possible or documented with any APIs of the .Net library that you are currently using with your C# script.

Otherwise, it would be a breeze if both scripts (client and server) be able to nteract with the core JavaScript security that is strictly enforced by the host Acrobat program on the client's PDF document.

In any case, I did notice that  the Acrobat JavaScript submitForm() method also supports HTTPS (just food for thought).

You also wrote " Abode " in one line of your server-side script; may be you meant :

var inputFilePath = @"D:\AdobeFile";

Re-check the link that I shared in my earlier reply.

When I tested the dummy file I didin't get those errors(of course), except that it cannot connect to the server.

It is worth noting that in the client-side script the URL portion should be expressed like:

this.submitForm({
cURL:'http://localhost:5889/receivepdf/vnd.fdf#FDF',
cSubmitAs: 'PDF'
});

Where "receivedpdf"  is the equivalent of a cgi-bin folder (if you were using a cgi script... I think).

And the next level of that folder path should include the full name of the script that will parse the data structure for this file ( I just used "/vnd.fdf" as an example); it should be terminated by appending the "#FDF" string at the end.

Last, I am also not entirely up to speed with how the FDF to PDF conversion between ASCII to UTF-8 plays a significant role (or not) with some of the weird errors that you are experiencing.

The JavaScript for Acrobat API Reference (dated 2/1/21) covers this.submitForm() function with examples and document methods starting on page 318. 

I highly recommend to take a look at it and test with some of the techniques used in those examples.

NOTE:

The JavaScript for Acrobat API Reference (dated 2/1/21) is hard to find online for download.

I have downloaded a copy; if you need it I can share a link here for you.

Also, to get the best assistance from the Adobe communities you should also post this topic in the Experience League Community:

•  https://experienceleaguecommunities.adobe.com/t5/custom/page/page-id/GlobalSearch#q=FDF%20to%20pdf&s...

Hopefully these insights may point you in the right direction.

[Test Screen Name]

I don't understand why you suggest the experiencebleague forum, when neither server side AEM software nor client side XFA forms are involved...?

[ls_rbls]

I though that maybe a few experts in that community would also be able to assist with the server-side portion or with any additional insights based off of the FDF Toolkit.

But now I know.  Thank you!