The addon should create a blueprint config/content-security-policy.js with default values on installation. This will make it much more obvious for consumers how to customize the policy.
We have two options how to deal with legacy configuration:
Not create a config/content-security-policy.js if legacy configuration exists.
Migrate legacy configuration from config/environment.js to config/content-security-policy.js as part of the blueprint.
It will be difficult to do the later one in a safe way if the existing configuration depends on environment, environment variables etc. It would require AST parsing for sure in this cases. It will also be difficult to make sure that all legacy configuration is removed. In some cases that might even be impossible.
I'm tending towards option 1 as it's less complex and we already have legacy support in place.
Ya, agree. Let's go with option 1 for now, it will help all new users (quite a bit) and we will have to write a detailed upgrade guide (if we haven't already) for the legacy config -> new config anyways.
The addon should create a blueprint
config/content-security-policy.js
with default values on installation. This will make it much more obvious for consumers how to customize the policy.We have two options how to deal with legacy configuration:
config/content-security-policy.js
if legacy configuration exists.config/environment.js
toconfig/content-security-policy.js
as part of the blueprint.It will be difficult to do the later one in a safe way if the existing configuration depends on environment, environment variables etc. It would require AST parsing for sure in this cases. It will also be difficult to make sure that all legacy configuration is removed. In some cases that might even be impossible.
I'm tending towards option 1 as it's less complex and we already have legacy support in place.