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

Content-Security-Policy violation while using 3.0.X #223

Open
ericlevine opened this issue Mar 21, 2019 · 4 comments
Open

Content-Security-Policy violation while using 3.0.X #223

ericlevine opened this issue Mar 21, 2019 · 4 comments

Comments

@ericlevine
Copy link

We recently upgraded our version of the redux-api-middleware from 2.3.0 to 3.0.1. However, our system stopped working entirely because we define a Content-Security-Policy that disables unsafe-eval.

After spending several hours going deep into what was going wrong, we tracked it back to the way the new version of redux-api-middleware is being built. By packaging it with rollup, it now includes a number of dependencies. One of the transitive dependencies is regenerator-runtime, which introduces such an unsafe eval. It has since been addressed here:

facebook/regenerator#346

However, this package will continue to have references to the offending line.

After forking the project and reverting to the old build mechanism with a similar babel config and removing rollup, I was able to get the new version of the package working as expected. This took quite a bit of time to track down and address, and still relies on a fork of this project as a result, so I'm documenting my investigation to hopefully save someone else hours of time tracking this down.

@nason
Copy link
Collaborator

nason commented Aug 7, 2019

Hi @ericlevine thanks for opening the issue. I have not used redux-api-middleware on a site with CSP enabled, and this should like a huge pain to debug!

Is your fork public? I'd love to see what you did, or a PR to get these changes upstream.

@ericlevine
Copy link
Author

@nason The fork is public and you can see the diff here. If I recall correctly, the bulk of the work was just reverting to the old build mechanism.

@karolis-sh
Copy link

I noticed, that the main issue is with umd bundle in our webpack build (using directly es module doesn't have this issue).
My current approach to bypass this is to completely ignore the "browser": "lib/index.umd.js", by a custom webpack resolving plugin:

function ReduxAPIMiddlewareCSPResolver(source, target) {
  this.source = source || 'resolve';
  this.target = target || 'resolve';
}

ReduxAPIMiddlewareCSPResolver.prototype.apply = function apply(resolver) {
  const target = resolver.ensureHook(this.target);
  resolver
    .getHook(this.source)
    .tapAsync(
      'ReduxAPIMiddlewareCSPResolver',
      function tapAsync(request, resolveContext, callback) {
        if (request.request === 'redux-api-middleware') {
          resolver.doResolve(
            target,
            {
              ...request,
              request: 'redux-api-middleware/es/index.js',
            },
            null,
            resolveContext,
            callback
          );
        } else {
          callback();
        }
      }
    );
};

module.exports = {
  resolve: {
    plugins: [new ReduxAPIMiddlewareCSPResolver()],
  },
  ...
};

Not the nicest solution, but get's the job done.

@reenan
Copy link

reenan commented Apr 22, 2021

@agraboso any plans on fixing this? Still an issue coming from the lib when updating to 3.x

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

4 participants