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?
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?