All Acrobat JavaScript functions that write a file to the user’s local disk pose a security risk, so there are some restrictions placed on their use. These functions include doc.saveAs()
and all of the data export functions, like doc.exportAsFDF()
.
As you can read here:
Acrobat provides us with two modes of operation for these
functions--with a path and without a path. If no path parameter is
provided to the function, Acrobat displays a file-browser dialog. The
file browser dialog gives users control over how data is saved to
their systems. If a path is provided to the function, then no dialog
is displayed and the operation is handled silently, i.e., the user is
not necessarily aware that data has been saved to their hard drive.
This is a security problem, so to use one of these functions in silent
mode, the function must be executed from a privileged context. This
means the code must reside in a trusted location. For example, code
executed from the Console Window, a Batch Process or a certified PDF
is privileged. When any of these functions are used with a path
parameter and executed in a non-privileged context, Acrobat will throw
an exception. The reasoning behind this restriction is, if the code
can’t be trusted, then the user has to specifically select the file
location.
Another restriction on saving data to the user’s system is that the
path specification must be a Safe Path. A safe path is one that
doesn’t point to a restricted location on the user’s hard drive or one
that might pose a security risk. Examples of these restricted
locations are the system folder and the root folder of any hard drive.
Other folders that might be restricted are dependent on the operating
system and the sensibilities of the Acrobat developers. Neither is
well documented, so it’s best to use these functions carefully.
About "Safe Paths", the Acrobat JS API doc.saveAS
method documentation states:
Acrobat 6.0 introduced the concept of a safe path for JavaScript
methods that write data to the local hard drive based on a path passed
to it by one of its parameters. A path cannot point to a system
critical folder, for example a root, windows or system directory. A
path is also subject to other unspecified tests. For many methods, the
file name must have an extension appropriate to the type of data that
is to be saved. Some methods may have a no-overwrite restriction.
These additional restrictions are noted in the documentation.
Generally, when a path is judged to be not safe, a NotAllowedError
exception is thrown (see Error object) and the method fails.
For sure you can't do it with the exportDataObject
method, since it has no path
parameter, as you can also read here:
The "cName" parameter is a required input and specifies the specific
file attachment that will be exported. Notice there is no path
parameter. There is in fact a "cPath" input to this function, but it
is no longer valid. If you try to use a path in this function, it will
fail and throw an exception. It doesn't matter what context the
function is called from because the "cPath" parameter was removed from
all usage.
Further references: