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 'unsafe-eval' #8

Open
nickclaw opened this issue Nov 9, 2015 · 2 comments
Open

Content security policy 'unsafe-eval' #8

nickclaw opened this issue Nov 9, 2015 · 2 comments

Comments

@nickclaw
Copy link

nickclaw commented Nov 9, 2015

This module can't be used in the browser when using a Content Security Policy without unsafe-eval set.

This is because unsafe-eval doesn't allow code to run that used eval(String), setTimeout(String), setInterval(String) or Function(String) (https://developer.chrome.com/extensions/contentSecurityPolicy#relaxing-eval).

Is there a reason error-factory requires using this method to create Errors? I realize that it's not actually unsafe in the context of this module, but it does force me to relax my entire webapps security to use.

@yanickrochon
Copy link
Owner

I'm sorry you get that restriction. The reason is more or less aesthetic. In the sense that

var CustomError = errorFactory('CustomError');

console.log(CustomError);
// -> [ function CustomError ]
console.log(CustomError.name);
// -> "CustomError"

etc.

To my knowledge, there is no way, in JavaScript, to dynamically create functions with arbitrary names other than to "eval" dynamically crafted statements and return that value. Even using Node's vm instead would've produced the same result, as browserify internally eval scripts within a created iframe, too.

I do understand the limitation and that it may be a real issue in some situation. I am an advocate for thin client, so this has never been a concern to me. I am not sure how this can be resolved without losing the benefit of a named function.

@yanickrochon
Copy link
Owner

The only thing I could find is this.

I need to upgrade this module up to speed with Node 4.x as soon as I can. I'll try to implement the ES6 solution then. It will get rid of the issue. However, it will result in having custom error constructors be anonymous until V8 implements the ES6 spec and Node follow. For the time being, there's no other solution I can offer. Just watch this repo until I update it. No ETA, yet, sorry.

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

2 participants