I'm looking for a solution where I could restrict which local files will be opened by Prince (including images, external CSS and script, fonts, etc).

I know about the --no-local-files CLI flag, and also the recommended suggestion of creating a restricted chroot environment, but I'm in a situation where I don't know in advance which files could possibly be requested, and I want to run each filename to be opened through a series of filtering rules.

It seems the Control Protocol (https://www.princexml.com/doc/server-integration/#prince-control-protocol) would be a good fit for such a feature. A job description could enable a "sandboxing" mode, where Prince would stop everytime it tries to open an external file (or an arbitrary URL), sending back a chunk with the requested file name/URL, and the caller would reply with a chunk to grant or deny access. This could even be extended so that the caller could reply with a redirection to another file/URL, or even pass the target content inline with a "dat" chunk. This would completely virtualize the access to the file access, allowing the caller to e.g. fetch data on demand from an external system or even synthesize complex document fragments "on demand".

Can we imagine having something like that, or another solution that would achieve the same goal, in a future release?

(Note that the job-resource stuff could be implemented emulated "caller-side" on top of such a system.)

I suppose one approach would be to allow JavaScript to intercept and rewrite document requests for resources, although that might not be flexible enough if it needs to check external systems as well.

The issue is that one wants to protect about fragments of the input HTML that we don't necessarily trust, and those fragments could perhaps override any JavaScript interception. Moreover, indeed, the actual filtering is, in our case, implemented by the caller application, and that logic could not be reimplemented in Javascript (needs access to external data, etc).