javascript feature request: global object policy refinement?  SOLVED

Forum for the PDF-XChange Editor - Free and Licensed Versions

Moderators: Daniel - PDF-XChange, PDF-XChange Support, Vasyl - PDF-XChange, Chris - PDF-XChange, Sean - PDF-XChange, Paul - PDF-XChange, Ivan - Tracker Software, Stefan - PDF-XChange

Post Reply
Mathew
User
Posts: 563
Joined: Thu Jun 19, 2014 7:30 pm

javascript feature request: global object policy refinement?

Post by Mathew »

I know the Acrobat API reference says
... Enable Global Object Security Policy.
When checked, the default, each time a global variable is written to, the origin which set it is remembered. Only origins that match can then access the variable.
But: Can one interpret this as that the global variable value is accessible from origins that match?

The problem I'm running into is that it basically blocks a global variable name. For tools that I was using before this security policy, they will run once and then never again unless the file name is the same. Even if I make trusted functions, unless the GlobData file is edited manually, or Global Object Security Policy is disabled, that variable name remains blocked. I don't know what the best solution is, but if internally the variable name were combined with the origin, then that name becomes unique to the file. This will fill up the GlobData with a lot of stuff though over time. Maybe an option in preferences to delete saved global data right next to this check box?
User avatar
Daniel - PDF-XChange
Site Admin
Posts: 10897
Joined: Wed Jan 03, 2018 6:52 pm

Re: javascript feature request: global object policy refinement?

Post by Daniel - PDF-XChange »

Hello, Mathew

I have spoken with the Dev team, and they will be looking into what we can do here. It seems that your suggestion to combine may be viable, but will need some further testing. For now we have a formal feature request ticket for you:

RT#6495: FR: javascript: global object policy refinement

While internal only, you can ask any member of the support team for an update on this in the future, just include the ticket number and we can let you know if there is any new progress at that time.

Kind regards,
Dan McIntyre - Support Technician
PDF-XChange Co. LTD

+++++++++++++++++++++++++++++++++++
Our Web site domain and email address has changed as of 26/10/2023.
https://www.pdf-xchange.com
Support@pdf-xchange.com
Mathew
User
Posts: 563
Joined: Thu Jun 19, 2014 7:30 pm

Re: javascript feature request: global object policy refinement?

Post by Mathew »

Thanks - I agree not a high priority. Mostly just an annoyance that has workarounds.
User avatar
Daniel - PDF-XChange
Site Admin
Posts: 10897
Joined: Wed Jan 03, 2018 6:52 pm

javascript feature request: global object policy refinement?

Post by Daniel - PDF-XChange »

:)
Dan McIntyre - Support Technician
PDF-XChange Co. LTD

+++++++++++++++++++++++++++++++++++
Our Web site domain and email address has changed as of 26/10/2023.
https://www.pdf-xchange.com
Support@pdf-xchange.com
User avatar
Roman - Tracker Supp
Site Admin
Posts: 331
Joined: Sun Nov 21, 2004 3:19 pm

Re: javascript feature request: global object policy refinement?

Post by Roman - Tracker Supp »

Hello, Mathew
Mathew wrote: Fri Jun 23, 2023 11:43 pm Even if I make trusted functions, unless the GlobData file is edited manually, or Global Object Security Policy is disabled, that variable name remains blocked.
In privileged context all global variables should be accessible, regardless of their origin. If that was your observation, not just a conclusion based on the Adobe spec, can you please provide repro steps for us?

We will limit the maximum number of stored persistent globals, so that exceeding the limit will automatically erase the GlobData file.
Mathew
User
Posts: 563
Joined: Thu Jun 19, 2014 7:30 pm

Re: javascript feature request: global object policy refinement?

Post by Mathew »

Hmm, so I went and tried to make a test case and it's fussy. I actually see two related bugs here:
1. If the global variable is first accessed from a trusted function, or from an unsaved new document (no filename associated with it), then it doesn't need a trusted function in future.
2. If the global variable is first accessed (without a trusted function) from a saved file, then that filename is associated with it, and you can't even access it from a trusted function.

Case 1

Make two new documents, and DO NOT save them.
Document 1 button mouseup event:

Code: Select all

console.println(global["testVariable"]);
global["testVariable"]="hello world";
global.setPersistent( "testVariable", true);
Document 2 button mouseup event:

Code: Select all

console.println(global["testVariable"]);
global["testVariable"]="goodbye cruel world";
global.setPersistent( "testVariable", true);
You'll be able to access the global variable in both (open the JS console to see output). Now save them. Quit and restart just to be sure. Now load both those documents, and you'll still be able to access from both.

Note that in GlobData, the variable is saved as if it were set up by a trusted function:
/testVariable <<
/V (goodbye cruel world)
>>

Case 2
Edit GlobData to remove the lines above, and save before starting PDFXChange.
First: Open PDFXChange and with no document active, run this to make a trusted function, and set up a toolbar button. Don't click yet.

Code: Select all

// run in the console
var TEST_GLOBAL_VALS = new class {
	constructor(name) {
		this.get = app.trustedFunction(() => {
			app.beginPriv();
			return global[name];
		});
		this.set = app.trustedFunction( value => {
			app.beginPriv();
			global[name] =  value;
			global.setPersistent( name, true);
			});
	}
}("testVariable")

app.addToolButton( {
	cName: "testGlobalButton",
	cLabel: "Test",
	cExec: "app.alert(TEST_GLOBAL_VALS.get())" }
)
Open both the above saved files, and try clicking the buttons in the documents. Only one document can reach it.

Now try clicking the toolbar button. The toolbar button (using the trusted function) will only be able to access the global variable from the document where it was first accessed, even though we have a trusted function with elevated privilege.

Case 1b
This actually follows from case 1. You can use the trusted function above to test it by first deleting the variable from GlobData, then running

Code: Select all

TEST_GLOBAL_VALS.set("Howdy!")
. Both documents will be able to access it.
User avatar
Roman - Tracker Supp
Site Admin
Posts: 331
Joined: Sun Nov 21, 2004 3:19 pm

Re: javascript feature request: global object policy refinement?

Post by Roman - Tracker Supp »

Thank you, Mathew, for your thorough analysis.
We are aware of certain inconsistencies in our implementation of JS globals.
We are working to address some of the issues (at least) in the next release of the Editor.
User avatar
Roman - Tracker Supp
Site Admin
Posts: 331
Joined: Sun Nov 21, 2004 3:19 pm

Re: javascript feature request: global object policy refinement?

Post by Roman - Tracker Supp »

Hi Mathew,
I just ran your test cases on the latest release candidate build. The issues you have reported above, have been addressed in the upcoming v10.0.1 release of the Editor.
Thank you again.
Mathew
User
Posts: 563
Joined: Thu Jun 19, 2014 7:30 pm

Re: javascript feature request: global object policy refinement?

Post by Mathew »

:)
User avatar
Daniel - PDF-XChange
Site Admin
Posts: 10897
Joined: Wed Jan 03, 2018 6:52 pm

Re: javascript feature request: global object policy refinement?

Post by Daniel - PDF-XChange »

Hello, Mathew

I just wanted to mention, that 10.0.1.371 is now available for download! Enjoy :)

Kind regards,
Dan McIntyre - Support Technician
PDF-XChange Co. LTD

+++++++++++++++++++++++++++++++++++
Our Web site domain and email address has changed as of 26/10/2023.
https://www.pdf-xchange.com
Support@pdf-xchange.com
Mathew
User
Posts: 563
Joined: Thu Jun 19, 2014 7:30 pm

Re: javascript feature request: global object policy refinement?

Post by Mathew »

Maybe this is intentional (build 371):

Once a global variable has been set by a trusted function, it can still be accessed by a regular un-trusted access to global[variable]. And then it becomes owned by that document. To reproduce:

With no documents open, run the script to make a trusted function and the button (see above case 2). Open both test documents. In the console:

Code: Select all

TEST_GLOBAL_VALS.set("Howdy!")
Go to one of the test documents: The button works, and sets it to a new value. It's no longer reachable from the other document.

I also tried not changing the global variable: Just getting the variable by one of the documents make it belong to that document.

Is this the intended result? Makes most sense to me that a document that's not running a trusted function should only be able to access its own variables - and definitely shouldn't be able to take one over.
Last edited by Mathew on Tue Jul 04, 2023 10:35 pm, edited 1 time in total.
User avatar
Roman - Tracker Supp
Site Admin
Posts: 331
Joined: Sun Nov 21, 2004 3:19 pm

Re: javascript feature request: global object policy refinement?

Post by Roman - Tracker Supp »

Hello, Mathew,
What version of the Editor are you talking about in your previous post?
Mathew
User
Posts: 563
Joined: Thu Jun 19, 2014 7:30 pm

Re: javascript feature request: global object policy refinement?

Post by Mathew »

sorry, it's build 371 (v10.0.1)
User avatar
Roman - Tracker Supp
Site Admin
Posts: 331
Joined: Sun Nov 21, 2004 3:19 pm

Re: javascript feature request: global object policy refinement?

Post by Roman - Tracker Supp »

Hello, Mathew,
According to the Adobe Acrobat JS API specification, when a global variable is changed, it becomes associated with the active document (receives that document as a security origin). In non-privileged context it is possible to access only global variables whose origin is the active document. By the way, the JS console is considered a privileged context.
So, it is intended behaviour that after setting your test variable in the context of one document, it is no more accessible from the other document in non-privileged context.
However, just reading the variable value should not change its origin. I was unable to reproduce this issue.
Can you please clarify your steps in this case?
Thanks.
Mathew
User
Posts: 563
Joined: Thu Jun 19, 2014 7:30 pm

Re: javascript feature request: global object policy refinement?

Post by Mathew »

Maybe not worth worrying about too much. It's a bit of an edge case.
Roman - Tracker Supp wrote: Fri Jul 07, 2023 10:03 pm Can you please clarify your steps in this case?
1. First make a document, add a button and put this as the mouseup action:

Code: Select all

console.println(global["testVariable"]);
2. Save the document as two different names.

3. With no documents open, run the following to make a function to access global variables and create a toolbar button to test(same as posted above):

Code: Select all

// run in the console
var TEST_GLOBAL_VALS = new class {
	constructor(name) {
		this.get = app.trustedFunction(() => {
			app.beginPriv();
			return global[name];
		});
		this.set = app.trustedFunction( value => {
			app.beginPriv();
			global[name] =  value;
			global.setPersistent( name, true);
			});
	}
}("testVariable")

app.addToolButton( {
	cName: "testGlobalButton",
	cLabel: "Test",
	cExec: "app.alert(TEST_GLOBAL_VALS.get())" }
)
4. Open both the documents you made in step 2.

5. Run the following in the console to set a global variable using the trusted function:

Code: Select all

TEST_GLOBAL_VALS.set("Howdy!")
6. Now the global variable "testVariable" has been set by a privileged function. You can test by clicking the Test toolbar button. But if you click on one of the buttons on the test documents, it will be able to access the variable also - the other document won't.

7. Set the global variable again using the trusted function, and go to the other document. It will now be able to access it, and will be the new "owner" of this variable.

8. Close the application and globData will have the test variable saved with the path of the test document that accessed it.

The reason this is just an edge case, is if you flip steps 4 & 5, the variable cannot be accessed by either document - as expected. Seems that if a document is open (doesn't need to be the active document), it can take control of a global variable set by a privileged function.
User avatar
Roman - Tracker Supp
Site Admin
Posts: 331
Joined: Sun Nov 21, 2004 3:19 pm

Re: javascript feature request: global object policy refinement?

Post by Roman - Tracker Supp »

Mathew wrote: Sat Jul 08, 2023 7:57 pm 7. Set the global variable again using the trusted function, and go to the other document. It will now be able to access it, and will be the new "owner" of this variable.
This does not change the owner of the document. After this step the other document still cannot access the variable. Because privileged assignment to the variable was done in the same document as before - and it is already the owner of the variable. The other document's button cannot access the variable.
Maybe you meant "Go to the other document and set the global variable again using the trusted function"?
Mathew wrote: Sat Jul 08, 2023 7:57 pm if you flip steps 4 & 5, the variable cannot be accessed by either document - as expected.
In this case you perform that privileged assignment to the variable in the global context (no active document), so the variable does not get a document origin (owner) and cannot be accessed (without privilege elevation) from any document.
Mathew
User
Posts: 563
Joined: Thu Jun 19, 2014 7:30 pm

Re: javascript feature request: global object policy refinement?

Post by Mathew »

If you have documents open, and set a global variable with a privileged function while it is open, the first unprivileged document to access that variable after setting it will become the owner.

Here's how it appears (with 2 documents open):
TEST_GLOBAL_VALS.set("something") :arrow: no owner :arrow: doc1 can access it :arrow: doc1 becomes owner :arrow:
activate doc2 :arrow:
TEST_GLOBAL_VALS.set("something") :arrow: no owner :arrow: doc2 can access it :arrow: doc2 becomes owner

Here - it's a bit easier to test if you make the "Test" toolbar button also set the global variable:

Code: Select all

// run in the console
var TEST_GLOBAL_VALS = new class {
	constructor(name) {
		this.get = app.trustedFunction(() => {
			app.beginPriv();
			return global[name];
		});
		this.set = app.trustedFunction( value => {
			app.beginPriv();
			global[name] =  value;
			global.setPersistent( name, true);
			});
	}
}("testVariable")

app.addToolButton( {
	cName: "testGlobalButton",
	cLabel: "Test",
	cExec: "app.alert(TEST_GLOBAL_VALS.get());TEST_GLOBAL_VALS.set(\"Howdy!\")" }
)
Last edited by Mathew on Tue Jul 18, 2023 4:33 pm, edited 3 times in total.
User avatar
Roman - Tracker Supp
Site Admin
Posts: 331
Joined: Sun Nov 21, 2004 3:19 pm

Re: javascript feature request: global object policy refinement?  SOLVED

Post by Roman - Tracker Supp »

Mathew wrote: Sat Jul 15, 2023 12:16 am If you have documents open, and set a global variable with a privileged function while it is open, the first unprivileged document to access that variable after setting it will become the owner.
I cannot reproduce this behavior, Mathew.
Here are my steps:
Open those 2 test documents (containing buttons to perform non-privileged get/set of the global variable on MouseUp).
Perform privileged set of the global variable (through the toolbar button) with doc1 being active.
Switch to doc2 (make it active) and press a document button. Both get and set operations fail with NotAllowedError error, as expected.
TestDoc.pdf
(5.65 KiB) Downloaded 159 times
Mathew
User
Posts: 563
Joined: Thu Jun 19, 2014 7:30 pm

Re: javascript feature request: global object policy refinement?

Post by Mathew »

If a document is active when a privileged function accesses the global variable, then that document becomes the owner. Is that the intended action? ie, after you have switched to doc2 and neither get or set actions are allowed, if (with doc2 still active) you then use the toolbar button, then that second document becomes the new owner.
User avatar
Roman - Tracker Supp
Site Admin
Posts: 331
Joined: Sun Nov 21, 2004 3:19 pm

Re: javascript feature request: global object policy refinement?

Post by Roman - Tracker Supp »

Correct
Mathew
User
Posts: 563
Joined: Thu Jun 19, 2014 7:30 pm

Re: javascript feature request: global object policy refinement?

Post by Mathew »

Roman,
I marked this as solved. I realized I missed a step in my sequence above which explains why it wasn't possible to duplicate (now corrected). But I really don't think it's worth more of your time. It works fine for most uses. Thank you for your attention.
User avatar
Roman - Tracker Supp
Site Admin
Posts: 331
Joined: Sun Nov 21, 2004 3:19 pm

Re: javascript feature request: global object policy refinement?

Post by Roman - Tracker Supp »

Thank you too, Mathew.
Your observations really help us to improve our software.
I agree, it might be controversial and not intuitive, but our implementation of JS API has to be compatible with Adobe specification, so that documents created by other software will work in the Editor. However, we can add extra features that do not break the compatibility.
Post Reply