OLE : remove security to addScript

[sylvainmi]

Hi,

I am processing a collection of PDF files in which I execute a script for each 3D annotation found. However, some PDFs are secured and addScript method on Doc is throwing an exception : "NotAllowedError: Security settings prevent access to this property or method.".

Is it possible to remove the security to be able to call addScript?
The PDF file won't be saved at the end. Is there a way to open the PDF as a non-secured one, just the time to do the treatment?

Thank you in advance.

[Test Screen Name]

1. Security belongs to the file as a whole rather than just the open document, so however you remove security you need to save the file before it takes effect.

2. There is no way for OLE to use the password to remove security, anyway. 

[sylvainmi]

Is there a possibility to execute a script as if the user clicked "Run a javascript" on the 3D annotation in an OLE application ?

We were trying to make addScript works because it was the easiest access point, but maybe we can use another way to do it, either by this access, or the Javascript Debug console. Do you know if either of these ways are possible from an OLE application?

[Test Screen Name]

Not if the PDF security forbids it.

[sylvainmi]

The PDF does not forbid it since we can manually execute "Run a javascript" by using the contextual menu over a 3D annotation. We can also execute script commands inside the Javascript console.

However addScript method is forbidden. But we won't need it, if we can execute a javascript from an OLE program ordering the Javascript console or simulating a click on "Run a javascript".

[Test Screen Name]

Do you use the VB: JavaScript bridge?

[sylvainmi]

C# :

AcroAVDoc document = new AcroAVDoc();

if (document.Open(a_pdfPath, ""))

{
    CAcroPDDoc pdDocument = (CAcroPDDoc)document.GetPDDoc();
    Object jsObject = pdDocument.GetJSObject();
    ...

[Test Screen Name]

No, that's not the VB:JavaScript bridge.

[sylvainmi]

No, it's a C#:Javascript bridge

[Test Screen Name]

Yes, GetJSObject is the bridge. No idea if it checks document security, sorry.

[sylvainmi]

However, I can't execute a script right from a file. I could try to decypher the script file and "execute it" with bridge objects but I encounter another issue described there : https://forums.adobe.com/message/10776324#10776324

But I would rather have a script file used as-is to be executed since the script file returns data that is used for testing procedures. We will compare those results in the Acrobat context with results in another context. Using the same javascript file would guarantee the same input and avoid synchronization error between a script file and its C# equivalent of bridge objects.
I am not a native english speaker so I hope this makes sense to you.

[lrosenth]

Since you are building an application that a user must install, why not also install an application level script in Acrobat & call that via the bridge?

[sylvainmi]

Well it is a good idea but have some downsides :
- as said before, the purpose is to call a set of javascripts for each annotation 3D of each PDF. We now have 2 scripts to tests but we will increase this collection in the future. We would need to add the new ones and delete the old ones as they come and go if they are put as application level scripts. This is a task we'd rather avoid.
- The scripts are written to be executed in an annotation 3D scope. We can (at runtime of an OLE application) encapsulate them to be called from an application scope and this is part of the program I have written. The script we wanted to add using the method 'addScript' was an encapsulation having all scripts put in a function with a parameter scene given. If we add or remove test scripts, we would need to update the encapsulation of the scripts and re-install them. We'd like to have those files kept for a context3d scope as the files will be processed in another context than Acrobat's.
- On the ideology level, we are running test scripts. By definition, we should not intrude more than necessary the context in which the test is processed to avoid side effects. Application level scripts should be kept for adding tools into the application, not some specific behavior for some specific files, especially if you can't control the content of the scripts inside those PDFs. They are not ours, they were created by other companies and we are using some of them to test our functionalities, and have a reference of bugs fixed to avoid regressions.

[Test Screen Name]

Except for the startup scripts read once when Acrobat starts there is no provision to run a file in Acrobat JavaScript. But there's nothing to stop you reading a file and using ExecuteThisJavaScript from an external app (except the poor debugging).

[Test Screen Name]

If addScript is viable, you should probably update your working practices to ensure that nobody is permitted to set document security - which has no value except as a nuisance to you.

[sylvainmi]

addScript is viable only because we won't save the PDF after the tests. And it is a nuisance still.
The PDF are given to us by other companies, we don't and can't have control on the context or the security on those.ExecuteThisJavaScript'.

You were mentionning 'ExecuteThisJavaScript'. Where can I find this method?

[Test Screen Name]

ExecuteThisJavaScript is one of the IAC methods in the Acrobat IAC Reference. I saw it there, I never used it.

[sylvainmi · Accepted solution]

It seems to work fine except for PDFs that have no AcroForm/Fields.
It is strange that this method is put on Fields object instead of CAcroPDDoc.

Well, I guess I gonna go for a mix and hope there is no secured PDF with this case.