Ajv loading requires `unsafe-eval` policy for `script-src` Content-Security-Policy

[clayroach]

Is your feature request related to a problem? Please describe.
For secure environments, the content security policy requires the unsafe-eval policy directive for the script-src policy. This requirement is primarily due to the use of Ajv's use of the Function constructor per ajv-validator/ajv#406

Describe the solution you'd like
The best resolution to this is to enable pre-compilation of the JSON schemas so that they don't have to be compiled at runtime. This can be accomplished using ajv-pack https://github.com/epoberezkin/ajv-pack

Describe alternatives you've considered
Alternatives or workarounds is to lazy load the Ajv validator so that it only loads when JsonForms components are rendered. This would allow compiling a version that disables jsonforms for environment with strict CSP's.

Describe for which setup you like to have the improvement
Framework: Material-UI (or any of the others, this should apply)

Additional context
See screen shots below for some examples of this error

[Lily418]

I like the look of ajv-pack, this is also related to a potential performance enhancement discussed here. Pre-complilation is great because avoids a penalty for doing this at runtime which is non-trivial for large schemas.
https://spectrum.chat/jsonforms/general/performance-enhancements-for-ref-resolving~4fb7b288-ddad-43b4-9697-07e923a1e667

Although ajv-pack does not support recursive references which is a feature the eclipsesource team are currently looking to support. #1476

I wonder if its possible to use ajv-pack already by passing an object to init which implements the methods of ajv that JSON Forms uses but uses ajv-pack instead
Take a look a the init action
https://github.com/eclipsesource/jsonforms/blob/master/packages/core/src/actions/index.ts#L83

and example of use
https://github.com/eclipsesource/jsonforms-react-seed/blob/master/src/index.tsx

Something like

{
 compile: () => prepackedAjvModule
}

[Lily418]

An inital test suggests more compatibility work would be required to use ajv-pack.

I used the validate function created by dispatching init action

import validate from "../validate_schema.js"

store.dispatch(Actions.init(defaultData, schema, uischema, { compile: validate } as any))

First big difference is that I only see 1st error, not array of errors from the function created by ajv-pack.

Second difference which breaks the displaying of validation errors is that dataPath is missing

Ajv-pack validate

{
  "keyword": "required",
  "dataPath": "",
  "schemaPath": "#/required",
  "params": {
    "missingProperty": "name"
  },
  "message": "should have required property 'name'"
}

AJV default validation (I removed schema and data properties)

{
  "keyword": "required",
  "dataPath": "name",
  "schemaPath": "#/required",
  "params": {
    "missingProperty": "name"
  },
  "message": "is a required property"
}

[Lily418]

Okay first issue is fixed by compling schema with --all-errors flag

ajv compile -s schema/Formulary/SchemaFlat.json -o validate_schema.js --all-errors

[sdirix]

Thanks @Lily418 for the great responses.

I think it makes sense to support ajv-pack, either directly or at least as some sort of configuration option in the future. We should also check whether we can reduce the bundle size for people who want to use Ajv this way.

I checked the code for the usages of Ajv and found:

1. Actions: Ajv.compile(schema) is called during init, setSchema and setAjv. All of these actions are only called from the outside so you know which schemas are coming in
2. Combinators: Ajv.compile(schema) is also called in the cases of oneOf,anyOf and allOf for each of the subschemas
3. Rules: To evaluate rules we create a new Ajv instance and call validate on it, which also calls compile.

These three places need to be modified for a proper support of ajv-pack. Items 1 & 2 could be configured using @Lily418's suggestion with a custom Ajv "mock" (assuming a packed validate behaves the same as the normal one). With item 3 however you will run into the error once you start using rules.

We would welcome a PR providing a configuration option for ajv-pack.

[Lily418]

My issue was caused by not compiling schema with correct flags. I added error-data-path

ajv compile -s schema/Formulary/SchemaFlat.json -o validate_schema.js --all-errors --error-data-path=property

Here's a little script based off the one provided by ajv-pack to compile schema with default Json Forms Ajv options

https://gist.github.com/Lily418/0fb96b6dd4ae87885f0c788b070383ac

[sdirix]

Thanks again @Lily418 for your great input.

@clayroach when using this compile script and creating your own "Ajv mock" as outlined above, you should be able to use JSON Forms (except for the Rule support) without hitting an error caused by the configured policies.

[clayroach]

@Lily418 @sdirix Thanks for jumping on this. I will try out the suggestion above and open a PR on this for any changes.

[sdirix]

This issue will be closed as it has been open for a long time with no activity. Feel free to reopen this issue if needed.

[DBosley]

@sdirix This is still a real issue. If you could re-open that would be amazing. I'm using JSON forms for a project right now and just ran into this. I see ways it can be resolved and I think I may be able to create a PR at some point in the next few weeks or so.

I found that using the method suggested by @Lily418 above to generate the ajv-pack'ed module, setting up my own instance of AJV and replacing the ajv.compile function with something like ajv.compile = () => myPackedModule gets me 90% of the way there. There are just some issues with the way AJV is used in the @jsonforms/core package. One main issue that means this method doesn't work 100% is that createAjv uses addMetaSchema which triggers an unsafe eval, and this function is called on file load by /packages/core/src/util/runtime.ts. If this instead was able to use the injected ajv instance instead of one it creates on file load I could hack it all together in a way that works for me.

Ideally, it would be amazing if we could inject the ajv-pack'd module as is so it could be used instead of ajv altogether. I'm contemplating cloning the core package into my project's repository and making the tweaks I need to get this working, then building a PR from there, but I need to talk to my team first.

EDIT: After digging in a bit further, it looks like the main issue with createAjv is that it adds a custom meta-schema for draft 4 that only adds 2 lines:

      "id":{
         "type":"string",
         "format":"uri" // This one
      },
      "$schema":{
         "type":"string",
         "format":"uri" // and this one
      },

If JSON Forms could function with the default draft-4 schema, and add it with getSchema('http://json-schema.org/draft-04/schema#') instead of addMetaSchema, there would be no unsafe evals outside of ajv.compile calls (as far as I can tell). I guess my question is: how important is it to JSON Forms that the draft-4 schema forces "id" and "$schema" to be URI formatted strings? If I understand how this works correctly, this just allows AJV to output a more useful error when they aren't URIs.

[sdirix]

Hi @DBosley, thanks for your message. I agree we should keep this issue open.

I'm absolutely fine with changing runtime.ts as I don't like that we construct an own Ajv instance here anyway. I would prefer reusing the Ajv instance from the state/context. The easiest way to achieve this would be to just add Ajv as a parameter to all exported functions. Maybe we can think of a slightly nicer pattern.

Regarding the API support: Maybe it would be easiest to just provide a wrapper util for packed modules which mocks / delegates all Ajv functions which JSON Forms uses. The usage would be straightforward and we don't need to distinguish between "normal" Ajv and "packed" Ajv in the core module, reducing complexity. Do you see any problems with that or is there something we would miss out upon with this approach?