Expand my Community achievements bar.

Dive into Adobe Summit 2024! Explore curated list of AEM sessions & labs, register, connect with experts, ask questions, engage, and share insights. Don't miss the excitement.

Coding URL in submit button invalidates digital signature

Avatar

Level 2

Hi there:

Hoping someone might be able to shed some light on this. I've been working on a set of forms for quite some time and an out of scope late requirements change came down the pipe stating that the forms must now be digitally signed. I went to work on that and made pretty decent progress being able to apply a valid digital signature to the form with fairly minor modifications. The forms are dynamix xfa forms created in Designer ES2 (aka version 9). I do have the Preserve scripting changes set to manual and I use the delta objects to preserve/restore state.

I've run into a couple of problems:

1. I have some code which populates the URL property for the save, close and submit buttons (these are http submit buttons) from hidden fields which are populated from the xml used to merge data into the form. This is done in the initialize event of the subform containing the buttons. For some reason, populating this property of the submit button (in an initialize event) invalidates the signature immediately after it is applied. Hard coding the URL resolves the issue. I'm pretty certain this code is somehow tied to the signature being invalidated because when I comment out the code the applied signature remains valid.

Here's a sample of the code I have in the initialize event:of the containing subform for the buttons:

xfa.form.FORMDATA.Main.Buttons.ProcessFields.FSSUBMIT_.resolveNode("FSSUBMIT_.event__click.#submit").target = xfa.form.FORMDATA.Main.HiddenFields.SubmitURL.rawValue;

Here's a little more information around this issue which I discovered as I continued work on the form

I was always using a Form Collection to group the above mentioned buttons together in order to exclude them from the signing, thus leaving them enabled after signing. While editing that Collection I noticed that the references to those 3 buttons could not be resolved (I remember I had moved them around in the hierarchy at one point so the Collection must have become corrupted). These buttons were no longer included in the Collection (ie they weren't checked in the Collection Editor dialog box). I changed that and included them in the Collection.

The effect of correcting this appears to be that the dig sig was now valid but in the Acrobat signature panel, it still showed that these buttons had property changes.

I continued to work on the form, refactoring it a bit more to add some behaviour to accomodate the use of the dig sig.

At one point I was experimenting with trying to remove the dig sig in code. I discovered that in order to do this I had to include the signature field in the Form Collection (thus excluding it from locking). I noticed that in relation to the above mentioned URL population code, this caused the signature to invalidate, because when I ten removed the signature field from the Form Collection, the form started validating.

End of story, right? Not quite.

As I unit tested the form more, I started to realize that the application of the dig sig was very inconsistent. I started to experience issues where I could not reliably apply a valid signature, even if I re-applied the form changes I had made originally which fixed the issue I was not always successful and in one case, the same form, during the same session, saw the signature applied the 1st time be invalid and after applying the signature a second time it was valid.

The second issue has to do with dynamic areas of the form.

Please see attached screen shot. There are many dynamic areas on this form where rows/sections are added but I have discovered one area where adding an additional section programmatically invalidates the signature. I am unclear why it only hapens in this one area as I do this all over the form.

In the attached screenshot, Name 3 is the section that exists at design time and Name 4 is a copy of that section added programmatically and populated with data. When Name 4 or additional names after that are added the signature becomes invalid. The design of this form is a remnant of the paper form where the original form had room for name 1 and name 2 and they wanted any additional names to be appeded on the 2nd page in a separate addendum.

Invalid Signature When Too Many Records Added To Affidavit.jpg

Would anybody here have any insight into why this type of button seems to be causing an issue?

Thanks in advance for any help or suggestions anyone can provide.

Dale

0 Replies