Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow for non-string objects in the content_security_policy field. #130

Open
buck-ross opened this issue Sep 5, 2021 · 4 comments
Open

Comments

@buck-ross
Copy link

In order to support the ongoing effort to migrate to Manifest v3 (see #107), the content_security_policy field of the manifest file needs to be formatted as an object, instead of a string like in the v2 specification.

Right now, there are a number of lines in the manifest processing script which operate under the assumption that the field will always contain a string value. This section will need to be re-written in order to accommodate object values when using the v3 spec.

Honestly, this doesn't seem like a very difficult thing to fix. I'd be happy to do in myself in a PR later this week.

@takayukioda
Copy link

Any update on this issue?

@buck-ross
Copy link
Author

@takayukioda I fixed this issue in #131, which was approved, but hasn't been merged yet. I haven't heard anything back from the dev team, so my guess would be that they're busy with other things. Hopefully they can address this soon.

@Lemon-cxh
Copy link

can this?

module.exports = {
  // ...
  pluginOptions: {
    browserExtension: {
      // ...
      manifestTransformer: (manifest) => {
        manifest.content_security_policy = {"extension_pages": "script-src 'self'; object-src 'self';"}
        return manifest;
      }
    }
  }
}

@buck-ross
Copy link
Author

@Lemon-cxh I'm not familiar with the manifestTransformer syntax, but on the surface of it, that looks like it could be an ok work-around. The one issue is that when build in development mode, script-src: 'self'; would need to become script-src: 'self' 'unsafe-eval';.

That said, I really don't think we should settle for a work-around solution here. The community is moving to manifest V3, and so this project should provide proper support for it, instead of requiring devs to work around a lack of support for it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants