I'm getting the following Content Security Policy error in chrome when running my React app. I tried googling this for a long time, but I couldn't find enough information about how to fix this when using create-react-app. I would appreciate any help very much.
After a bit search about your issue, I ended up here in MDN. I will shortly define what the problem is but for more information I strongly suggest you read the provided link.
So what is happening here exactly?
This is because the website is configured to use Content Security Policy(CSP) to protect against someone maliciously loading code from a third party. The Content-Security-Policy meta-tag allows you to reduce the risk of XSS attacks by allowing you to define where resources can be loaded from, preventing browsers from loading data from any other locations. This makes it harder for an attacker to inject malicious code into your site.
How to solve this then?
According to the MDN link that I provided, we should solve this by adding the following meta tag to our index.html.
<meta http-equiv="Content-Security-Policy" content="default-src 'self' *.trusted.com">
NOTE: *.trusted.com should be the trusted site or list of them.
Then what should it happen on your own localhost?
I have faced several issues like yours and then found out when this error has shown up on your console, this is not necessarily showing you have this exact problem on your project, and the other problems in your main code could cause such an error. I just found some similar issues that will share below:
Same issue on angular
Same issue on ionic
Same issue on react
and so on
So what you have to do?
First of all, please check all your existing codes and paths in your project and make sure there are no errors in neither of them. When you get rid of all your errors this should be gone as usual, but if the problem insists to exist please make sure to disable all your extensions in your browser (you can safely test it on incognito without disabling anything) and then run the project and see if the error is gone or not.
So there is two-step at all to get rid of that:
Get rid of all your project and pathing errors
Make sure all your extensions are disabled
Related
I can see in Sentry report that,
Along with my vendors~main-6319dfea084cb55e85bf.js,main-6319dfea084cb55e85bf.js and other resource.scripts and resource.css files i can see https://localhost:49506/7pp3ab609c5236b3bf34c2b621ac79ba.js script is been injected and also- GET https://localhost:49506/storage/userId and GET https://localhost:49506/storage/pendingRequests api calls has been triggered.
The attacker tried this from EDGE browser.
The application was developed with typescript and Reactjs.
My questions are,
What type of attack it is?
How can i handled this?
Also if any additional info, please post here.
Thanks in advance.
React-hook-form and polyfill.io causing page to crash Z.current.unMount is not iterable.
To re-create:
On IE11 you can go to polyfill.io and download the minified code. Or simply paste this into IE11 https://polyfill.io/v3/polyfill.min.js and you will get the required code. Create a React project and create a basic form using React-form-hook. Next import the polyfill and this will result in the page crashing: Z.current.unMount is not iterable. As soon as you remove the polyfill the form works as expected.
Background:
These polyfill's/ponyfill's are needed as still supporting IE11... yeah... we use polyfill.io to get the required polyfills. We load this polyfill on every page. Wondering if anyone else has come across this issue usig polyfills and react-hook-form and has a good work around?
This issue seems to have come from version 6.8.4 of React-hook-form and above.
Without polyfill
With polyfill - This error is inside of the React-form-hook library
We ran into this problem too, and discovered like you that polyfill was the issue. I'm not sure if our issue is exactly the same, because we've only just seen this issue show up, while you reported this issue 4 months ago. That leads me to think our issues are not the same, but posting just in case.
What seems to be happening for us is that when you use the polyfill service but don't specify a version, sometimes the js file you get back contains js content, and sometimes doesn't (try the url in your browser with a hard refresh). In our case, I'm assuming that the case where it does not return a js bundle is the desired behaviour because the browser doesn't need any polyfilling.
Specifying a version for the file seems to fix the issue for us. Doesn't seem to matter what version, just specifying a version itself seems to ensure that it returns the correct bundle content every time. E.g.:
https://polyfill.io/v3/polyfill.min.js?version=3.110.1
Have posted a bug report here: https://github.com/Financial-Times/polyfill-service/issues/2699
I have a react app that has several pages. When I refresh the page, I can successfully link to one other page. Subsequent links update the url address with the reference to the new page, but only load after the page refreshes.
Error messages in different browsers differ.
In chrome:
In firefox:
In safari:
I have seen this post which has very long, complicated suggestions about routing. I'm not sure if this is my problem yet, so have not yet explored the ideas set out as solutions.
2nd screenshot shows that something tries to load /your-path-to-fontawesome/css/all.css and most probably you don't have that file at that location (therefore receiving html instead). You need to config something somewhere in code, connected to fontawesome
Two separate issues here:
First, the combination ERR_BLOCKED_BY_CLIENT and ERR_UNSAFE_REDIRECT are usually the result of a browser extension, or the browser itself, blocking cross-site tracking. This would also make sense why you're only seeing it in a particular browser.
Second, the invalid MIME type for your CSS typically comes from one of two things. The most common, and easiest to fix, is that the path to that file is wrong. In this case, the server responds with a 404 page, giving you the invalid MIME type of text/html.
Another possibility is a library adding comments to the top of a CSS file that is meant to be minified before being sent to the client. Here's a more in-depth post about this issue. Would definitely double-check the file path, though, before digging deeper into this possibility. An easy way to check would just be to take that URL from the MIME type error and navigate to it in your browser to see what you get.
I have an isomorphic/universal React app, meaning it is rendered on the server by the same JS that powers the client-side, Single Page App user experience.
I configure this app's DNS using Cloudflare, and use their "orange cloud" feature to accelerate and protect my site's traffic, as explained in the following graphic and in their support article:
From the linked-to article: "Cloudflare can operate in two modes - DNS only (unproxied; 'grey cloud') and as a HTTP proxy ('orange cloud') with our security, CDN & performance features."
I have discovered that running my app with React 15 and Cloudflare's "orange cloud" HTTP Proxy feature results in an error:
reactProdInvariant.js:31 Uncaught Error: Minified React error #32; visit http://facebook.github.io/react/docs/error-decoder.html?invariant=32&args[]=2 for the full message or use the non-minified dev environment for full errors and additional helpful warnings.
The text of the linked-to bug:
Unable to find element with ID 2.
This ID probably refers to the head tag of my page:
<!doctype html>
<html lang="en-us" data-reactroot="" data-reactid="1" data-react-checksum="-1233854461"><head data-reactid="2">...
I do NOT get this issue with React 14.
I do NOT get this bug when using the raw, un-DNS-ed address of my app, nor do I get it when I switch to the "grey cloud" to use Cloudflare as only a DNS service.
I do NOT get this issue when I disable server-side rendering.
When I google the text of the linked-to "actual" error, I find this Github thread that confirms that this has something to do with server-side rendering.
However, my situation differs slightly: that thread's author encounters the error with an "unable to find element" ID referring to a style tag, whereas in my case the unfound element ID refers to the head tag.
When I google the text of the production "wrapped" error, I find this Github thread that confirms that this has something to do with Cloudflare's HTTP Proxy. This comment says: "If you're using CloudFlare, please disable auto-minification of HTML."
So far, I can't figure out how to do that. It's hard for me to find good information on what exactly Cloudflare does with their HTTP Proxy, and how I can configure it.
Questions:
Why exactly does this bug happen?
Where can I find information about what exactly the "orange cloud" does?
What is the best way to fix this problem while maintaining the benefits of Cloudflare's HTTP Proxy?
React on the server needs to render the application to a string of HTML that makes sense to the browser. At the same time, React in the browser needs to read this HTML and understand it in relation to your JS code: it needs to identify which DOM tree came from which React component, in a very detailed way. Thus, in effect, the intermediate HTML is a serialization format between React on the server and React on the client with an additional requirement for it to make sense for the browser even in the absence of React.
When you enable advanced Cloudflare functionality, it treats the HTML as a “regular” HTML, not fancy server-side rendered compnents. My baseless speculation on one thing that could be going wrong is stripping HTML comments. In general, this is a natural thing to do for minification. But React uses HTML comments to put a <!-- empty --> placeholder where a React component returns null. Naturally, stripping these breaks React.
Cloudflare is there to make serving websites faster at a lower cost. They have a wide variety of tools to achieve that, see their introduction guide. Minifying HTML is completely natural and it is unfortunate it breaks your use case, but this is what we get when the meaning of nodes and attributes and flexibility changing them in our HTML is not strictly defined.
I think the most straight-forward way for you to move forward for now is to disable HTML minification in Cloudflare settings.
I did my research and it's still not clear to me. It seems it once did, when Chrome Apps were still called Chrome Packaged Apps.
Is it navigation a no-no for Chrome Apps? It doesn't sound right to me. The use of views seems the way to go...
Trying to use ngView I got the following error:
XMLHttpRequest cannot load chrome-extension://opjofdlbcghpdgfhmpdfmadlnmnblijo/views/main.html. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null' is therefore not allowed access.
The error persists even using:
$compileProvider.aHrefSanitizationWhitelist(/^\s*(https?|ftp|mailto|chrome-extension):/);
(this line is in an related answer, I'll try to get the link here later)
Inline templates don't do it either. Apparently.
So, I'm looking for up-to-date info on this subject. The following article is great: http://www.ng-newsletter.com/posts/chrome-apps-on-angular.html. But the code available on Github is not so complete as stated so I had a little trouble trying to test it.
Of course it's possible do go with ngHide, ngShow, ngIf etc... But having templates in seprate files is much much better...