Hiding contents of PDF based on NON-existence of a password?

[Brian3_14]

(repost from different group)

Hi all -

I'd like to use javascript to "hide" my Livecycle Designer form on open if a password for the pdf is NOT present.  (If someone strips the password, at least I can make it more annoying for them.)

I understand that if javascript is not enabled on the end-user side, the PDF will still be visible.  But that's ok.  The PDF is javascript heavy and only useable if javascript is active.

I've had some success, I think (lol), with "securityHandler".

If I add a password in LCD to the form and then open it with Acrobat, I can use the Console window and type:

this.securityHandler

The return is "Standard".

If no password is added in LCD to the form and then I open it with Acrobat, using Console window and typing:

this.securityHandler

The return is "null".

So we have two different values we could use to establish whether or not a password is on the PDF.

But I think I'm getting caught up when trying to write the code to reference the securityHandler value.  Documentation seems to indicate that securityHandler is in both Acrobat and LCD.

Something like:

var a = this.securityHandler;

if (a == "Standard"){

    xfa.host.messageBox("There is a password of some type on this PDF");

    }

if (a == null){

    xfa.host.messageBox("No password on this PDF.")

    }

Any ideas?  I know this is just a bump to someone who's taken the time to strip the password using 3party software but why not make it a little more confusing for them, right?

Thanks!!!

Brian

[Brian3_14]

Follow up:  regardless of the presence of a doc open or permissions password, this.securityHandler seems to always return null...

Hmmm....

[radzmar · Accepted solution]

Just replace this with event.target to execute the script from within a XFA-form.

var a = event.target.securityHandler;
if (a == "Standard"){
    xfa.host.messageBox("There is a password of some type on this PDF");
    }
if (a == null){
    xfa.host.messageBox("No password on this PDF.")
    }

[Brian3_14]

Ah!

Well done, Radz and thanks much for ALL your posts.

More to follow, just a quick thanks and wanted to mark as a "Correct"!

B

[Brian3_14]

Hi Radz -

Thanks again for the response.  Have more than a sec to write this time so following up.

Your code works great.  Placed in the right location, and if javascript is not disabled, the PDF will open and then close again if no password is in place.

Is there any way to programmatically do the same but in LCD?  So If no password on the document, not even Livecycle will open it?

Know it sounds like a stretch - using LCD to write code so LCD won't open it if there's no password on it the next time LCD opens it. Maybe by adding something directly into the XML code?  There is a PDFSecurity tag in there.

Thanks much,

Brian

[SI_MSD7]

I'm not exactly sure what you're trying to accomplish, but have you tired using the built-in password features in LiveCycle Designer..Form Properties>PDF Security?

Are you trying to prevent someone from opening the form (in Adobe Reader/Acrobat & Designer) if they don't have the correct password, or are you trying to prevent the form from opening if the document "owner" failed to assign a password. Meaning, it will operate as a fail-safe for the owner, vs trying to "assign" a password.

In either case, it seems simply using the PDF Security features baked into Designer "should" suffice. But again, I'm not 100% clear on what you're trying to accomplish.

[Brian3_14]

Hi SI:

Thanks for the post. Sometimes it's just good to bounce ideas, ya know?

The goal is to prevent the dynamic form from being modified.

Thanks to Radzmar, his code can be used to essentially disable the form in Reader/Acrobat if the LCD created password has been stripped. (Technically, it "opens" but then it immediately closes itself again.  Whole thing happens pretty quickly. Radz rules.) But the javascript is written for Reader/Acrobat. Livecycle will still open it.

I'm wondering if a line(s) of the XML source code could be added - hmm... altered/deleted, more likely(?) - so that once the document is saved and closed by LCD, that's it. Next time LCD tries to open it, it won't be able to because of the added/altered/deleted code in the XML.  I could be way off on this - still a major newbie compared to everyone else in here.

In theory:

1) Open a fully complete "original" PDF (with unaltered XML) in LCD.

2) Change/break the XML that LCD needs (but not Reader/Acrobat) to open the file to see the underlying arch/make edits/etc.

3) Double check your work 8,000 times, save and close --- and it's forever closed to LCD.

It's not like the original dynamic PDF template, with the untampered XML, isn't backed up.  Besides, there's no way to save info entered into the form anyway once LCD opens it.  So why not just kill it?

Again, probably way off base here.  But in the XML there are references to values of the form:

     <?templateDesigner DefaultPreviewType interactive?>

   <?templateDesigner DefaultPreviewPagination simplex?>

   <?templateDesigner XDPPreviewFormat 20?>

It got me wondering.  Could a "templateDesigner" line (or some other line in the XML) be altered/added so LCD would essentially say, "Umm... not sure what to do with this.  Can't open. Sorry."

Thoughts?  Thanks!

B

[radzmar]

If you would modify the XML data in a XFA-form in the way Designer could not process, the form also wouldn't work in Acrobat nor Reader. A XML-file has to be wellformed everytime, otherwise it won't be processed by the XML-parser. In Acrobat and Reader this means you'll only see the "Please wait…"-Message of the Shell-PDF when you open the form.

To avoid a later editing the form in Designer add a 256-Bit-AES password with Acrobat under the Document Properties (Ctrl+D) > Security tab.

[Brian3_14]

Thanks, Radz.  Gut instinct was telling me I was reaching on that one...

Did some testing using Acrobat to put a password on a PDF vs the LCD password feature.  Either way, even using Acrobat's 256 AES, those free sites strip the passwords.  Grrrr. Or am I missing something?

Side note - or question, rather on the "Please Wait..." shell message: any way to change the text of it?

Would be nice to tell people from the start: "Woops! Wrong PDF application.  Please use Acrobat or Acrobat Reader to open this PDF file."

The "Please Wait...." seems to give people hope it will work, then confuses them as to how long to wait and then disappoints them when nothing happens.  (Regardless of the fact that the next two sentences tells them what to do,lol.) They just seem to focus on the "Please Wait..."

Big thx, as always.

B

[radzmar]

Did you try the Certificate Security?

I didn't found a service that can crack this and the form als cannot be editied in Designer anymore.

[SI_MSD7]

Brian -

I agree, the Page Zero "Please Wait..." message associated with XFA forms can be very misleading, thus causing alot of confusion - especially with dynamic forms since those must be opened in Adobe Reader/Acrobat for guaranteed full-compatibility.

There’s a partial solution made possible by using an application called PDF Stream Dumper, but it’s not very intuitive, and can be very aggravating to use.

An easier/cleaner solution is to get the Designer version of AEM Forms (“AEM Forms Designer”) which can be downloaded here: https://www.adobe.com/devnet/livecycle.html

Scroll down to bottom right under "Download and Updates".

Once downloaded and installed, follow these instructions here: https://helpx.adobe.com/aem-forms/6-1/changing-page-zero-content-designer.html

I’ve tested and it works great; however, you may be required to remove any current/prior installations of Livecycle Designer. At least that was the case for me…I had to uninstall Designer ES4 and I believe ES3 before I could successfully install AEM Forms.

Hope this helps!

[Brian3_14]

Hey Radz -

Never thought of that.  Will check experiment with today.  Thanks!

B

[Brian3_14]

SI -

Wow.  That's a great find.  Downloaded and will be experimenting with this weekend.  Will keep you in loop!

Thanks!

B

[Brian3_14]

SI -

So far so good.  Simple editing has been accomplished but struggling with the format.  Any guides/links as to how to write the code?  Seems to be roughly CSS based but not working as expected.  For example, can't add a color to a span or add a top-margin to a <p>.

Thanks again!

[Brian3_14]

Hey SI -

More success.  A question and then a kinda-funny story regarding what my issue above was with the code.

The question:

1.) Does AEM not truly "save" the custom property?  I noticed that if you:

     a) Dropped code into the value.

     b) Saved the file (I'll call it "TestPageZero.pdf"

     c) Closed TestPageZero in AEM.

     d) Opened TestPageZero with a non-Adobe PDF application. (Confirm it works.)

     e) Re-open Test Page Zero in AEM.

The custom property we created is deleted.

Now, if you just just CLOSE the file in AEM (not re-saving it) the _pagezerocontent seems to hold - even though the value field is empty. (If you open with a non-adobe product, the customized page zero content will still be there.)

But if you save the PDF, the default _pagezerocontent language reappears when you open with a non-adobe product.

Is this a bug?

Thanks again for help.  Great find and happy with results except for this disappearing issue.

B

[Brian3_14]

Si -

Forgot the story.  It's a cautionary tale regarding quotation marks.

The value field for the custom properties is just a small field where you place the loooooooooooooooooooong string of code --- so you can't see all the code at once.

I was running AEM inside a virtual windows 7 machine on a MAC and using the Mac TextEdit to try and write the code.

The quotes (" ") in Mac's TextEdit weren't translating over in AEM as quotes.  That's why the code kept busting.  Ugh... lesson learned. And a big FYI to anyone who reads this. Make sure when you paste code over, that AEM or Livecycle translates the characters correctly.  In my case, it was really subtle.  Straight (vertical) quotation marks vs slightly curved (right-leaning) quotation marks.

Embarrassed to say how long it took me to figure that one out.  So be careful out there, people!

B

[SI_MSD7]

Hi Brian -

I've been out-of-town so was unable to reply sooner.

Regarding your first question/comment...I haven't tested the ability to fully edit the code, but I presume there might be some limitations. Honestly, just being able to get rid of the "Please Wait.." part and replacing it with something more informative was a HUGE success for me. Were you able to get color text as desired?

Regarding the custom properties not being saved...I haven't been able to test any form to the extent you have, thus it's good to know your findings. Are you saying that "after" step e) above (Re-open Test Page in AEM), that if you "re-save" the document it clears the value and any custom message added? But if you simply CLOSE the file and not -re-save it, that the value remains? Hence, the issue is in saving the document more than once? If that's the case, then it very well could be a bug. I know Adobe released two Feature Packs which "might" have fixed the issue, but I haven't been able to locate and/or download the files. For some reason, alot of this AEM stuff appears to be hidden and requires a lot of digging!!!!

Lastly, I know exactly what you're taking about re: the misuse of (" ") in code. I've had that happen to me a couple times only to realize the quotes were the culprit.

[Brian3_14]

Hi Si:

Sorry for the delay on my part.  Here's where I'm at.  Good news first, then the bad news - so don't get exited.

Good News

1) WAS able to get the color working.  It was the "" issue discussed above.

Annoying, but workable News

2)  Correct.  The custom _pagezerocontent value disappears once the AEM Forms re-opens the PDF.  (You won't see it  - the value will be empty under Form Properties.)  If you change and save the PDF, you have to add the _pagezerocontent each time.

The Really Bad News

If you Extend the PDF using Acrobat (I'm using 10) - the custom _pagezerocontent gets deleted and we're right back to where we were. Still testing but not hopeful.

Will keep you informed.  Let me know if you have any discoveries. Damn.

B