Adding support for JS prototyping using GraalJS

[jkiddo]

This pull request introduces a new feature that enables secure, server-side execution of administrator-vetted JavaScript scripts for transforming FHIR resources via the new R4 $execute-javascript operation. This is implemented using the GraalJS engine, is disabled by default, and includes comprehensive security measures such as sandboxing, strict script selection, and execution timeouts. The PR also adds configuration options and updates documentation and dependencies accordingly.

New Feature: Server-side JavaScript Execution for FHIR Resources

• Implementation of $execute-javascript Operation:

  • Adds JavaScriptExecutionR4OperationProvider, a new R4 system-level operation provider that executes administrator-installed JavaScript scripts (not user-supplied code) to transform FHIR resources.
  • Scripts are securely sandboxed (no host, filesystem, or network access) and run with a configurable timeout. Inputs can be inline resources or server-resolved references, and outputs are returned as FHIR resources.

• Security and Configuration:

  • Introduces new configuration options in application.yaml to enable the feature, specify the scripts directory, and set execution timeouts. The feature is disabled by default and requires explicit configuration to activate.
  • Ensures script names are strictly validated and only files in the configured directory can be executed, preventing path traversal.

Integration and Dependency Updates

• Integration with Server Startup:

  • Registers the new operation provider in the server configuration, ensuring it is only active when enabled. [1] [2] [3]

• Dependency Addition:

  • Adds the GraalJS JavaScript engine dependency (org.graalvm.js:js) to the pom.xml to enable script execution on stock JDKs.

Documentation

• README Update:
  • Documents the $execute-javascript operation, its security model, configuration, usage examples, and a quickstart for Docker-based testing.

[jkiddo]

One could consider to wrap the JS inside FHIR libraries

[jamesagnew]

A couple of initial thoughts - This is a really neat idea, but I don't think this implementation is the right approach:

• We shouldn't be defining functionality in this project - it should purely handle configuration and deployment concerns. If this is a useful feature, it should be built, documented, and tested in a hapi-fhir module, and instantiated in this project.
• It probably makes more sense to use GraalJS for the execution engine - Nashorn isn't being actively developed these days and is fairly behind.

[jkiddo]

I hear you on GraalJS (trifork@b8f7383) - but then we will also have to require a bump on the Java version to 21 (thats probably fine) soon ™️ .

On moving it to a module to HAPI FHIR ... - I guess... 🤔 - but I wouldn't know the proper encapsulation/abstraction. The reason why I put it here in its current form was because the simple abstraction of just wrapping it in a FHIR operation seemed fine for the purpose. If we move it and just retain (or close to) the signature of

executeJavascript(
			@OperationParam(name = "script", min = 1, max = 1) StringType theScriptName,
			@OperationParam(name = "resource", min = 0, max = OperationParam.MAX_UNLIMITED)
					List<IBaseResource> theInputResources,
			@OperationParam(name = "reference", min = 0, max = OperationParam.MAX_UNLIMITED)
					List<Reference> theReferences,
			RequestDetails theRequestDetails) 

Then I guess that could work just fine.

[github-actions]

This PR is stale because it has been open 45 days with no activity. Remove stale label or comment or this will be closed in 10 days.

[jkiddo]

Moved to here hapifhir/hapi-fhir#8237 as requested @jamesagnew ✔