So I'm using SVG sprites in my extension and it works in Firefox, but Chrome is blocking the asset because it's cross-origin.
and it's listed as a web accessible resource
"web_accessible_resources": [
"svgs/*.svg"
],
I'm not understanding why Chrome is blocking it.
To add, I'm using an SVG sprite in an <svg>/<use> element. It appears that Chrome blocks this, at least on sites with HTTPS:
Unsafe attempt to load URL chrome-extension://ainfdhapdnpfbjbnjojoediompjnmkom/svgs/fa-regular.svg#clock
However, Firefox does not block using SVGs in this way. I tested using a non-SVG sprite file for the body background image as demonstrated in Savaratkar answer and that worked while Chrome was blocking the SVG sprite used in the <svg>/<use> element
No, Chrome never blocks SVG file loading if it is enlisted in web_accessible_resources.
Please check the following:
svg file path/regex mentioned in web_accessible_resources is correct
you are fetching svg url via chrome.runtime.getURL
also, check the path inside chrome.runtime.getURL function
Problem is chrome always give same error message:
(index):1 Denying load of chrome-extension://pdlmeiogifooojmjbihodmcehpmjghho/Takkun.svg. Resources must be listed in the web_accessible_resources manifest key in order to be loaded by pages outside the extension.
...for any kind of issues related to web_accessible_resources.
I had some time and doubt about it, so I tested it on a simple chrome extension:
https://github.com/sonalsavaratkar/chrome-extension-seed/tree/so-48393958
It loads a svg file to the body element of any webpage as background-image.
Related
I am building a chrome extension which works on the Gmail site. As of now, there is no CSP in my manifest.json
I am in the middle of migrating it to manifest v3 from v2. I found out that remote loading is now not allowed in v3. So does that mean one cannot load fonts, CSS, and js from links like -#import url("https://fonts.cdnfonts.com/css/google-sans");
When I did this, I think the font was getting loaded but the console showed an error -
"Access to font at 'https://fonts.cdnfonts.com/s/14955/ProductSans-Regular.woff' from origin 'https://mail.google.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource."
"GET https://fonts.cdnfonts.com/s/14955/ProductSans-Regular.woff net::ERR_FAILED 503"
When I see the "Elements" tab in the dev tools, I can see -
font-family: "Google Sans",Roboto,RobotoDraft,Helvetica,Arial,sans-serif;
So, is the font getting loaded? If I deselect this CSS style from the elements tab, the font changes in my extension.
Apart from this, I am also loading images in my file -
<img src="https://img.icons8.com/ios/50/000000/table-properties.png"/>
These are loading perfectly. Why? Shouldn't this be blocked?
What is happening here?
What is the correct way of loading fonts, CSS and JS files in my chrome extensions?
If manifest v3 doesn't allow remote loading, what is the point of writing a custom CSP?
When you look at CSS you only see the text rule, not the actual resource being used. Look at the bottom of the "Computed" panel where it shows the actually used font.
Gmail already loads google-sans font, which is why the font changes when you deselect this CSS rule.
img.icons8.com are loading perfectly because the server sets Access-Control-Allow-Origin: * whereas fonts.cdnfonts.com doesn't as the error message says.
You can include the resources in your extension directory, expose them via web_accessible_resources, and add into the page.
what is the point of writing a custom CSP
Well, to make it even stricter. Yeah, funny, I know. ManifestV3 is inherently nonsensical because it's devised by impractical idealists, and it still has a lot of critical bugs, but hopefully it'll change in the future as we report the real use cases we encounter on https://crbug.com.
I'm developing a chrome extension that renders and sidebar iframe in Gmail.
A while back, we ran into a Content Security Policy issue that broke our extension and ran into a well-known error that shows up in your console as
Refused to frame '[OUR DOMAIN]' because it violates the following Content Security Policy directive: ...
To fix it, we had to rewrite the CSP header as explained in this blog post.
However, recently, we've been getting the same error, even after having implemented the fix suggested in the blog post.
As you can see, even though we added the chrome.webRequest.onHeadersReceived listener to overwrite the CSP header, our domain doesn't seem to be working. As a result, our sidebar does not load.
Notes and attempts:
Note that upon refreshing the entire page, the sidebar will sometimes load successfully %50 of the times, which leads me to believe that we're not adding the above event listener fast enough. To solve this, I pulled the event listener out of our background class and placed it at the top of the background js script. However, this issue seems to still persist.
We've tried to remove and re-add the extension but that didn't yield any permanent results.
Throughout testing, I also noticed that adding another extension that implements a similar override on the CSP header will cause our extension to break. Removing and re-adding our extension brings us back to the 50-50 issue in the first note.
[Update]
It seems that being able to reproduce it %50 of the times has to do with the version of chrome. After upgrading it to 72, I'm now able to reproduce the issue. However, doing a hard refresh on the page will sometimes allow the page to load.
More details on our setup: What we do is basically have a background.html which contains html templates and we have one template that contains an iframe tag. To get the template with the iframe, we do a sendMessage, grab the response, which is the template in string, convert it to DOM element via jquery, append it to body, and change the iframe's src attribute. What happens is the iframe loads fine initially, but when you click on any link in the iframe that would redirect to another page, the same error above shows up.
I can provide snippets and more info if needed.
First of all, is there another built in way to do this like webview is in phonegap, so I can load an external site into a div or div like element. I know webview exists for chrome apps, but i couldn't find anything for extensions.
Basically i want to show preview of pages on links..
To do that I am trying to load urls of links using by setting src of iframes using content script. However, for most urls, I get an error that xframe not allowed.
what are my options.
xframe is pretty full proof, however, if you aren't referring to specifically an iframe, you could always use a web-proxy such as node-unblocker for node.js, or miniProxy for PHP.
I have an iframe in my chrome extension that loads a website, I'd like to inject CSS and Javascript into the website but only when its loaded in my extensions iframe (so it doesn't get affected when the user browses to the site normally).
I was surprised that Chrome extensions have cross-domain security policies applied to them when they try to access the internals of an iframe even though they can make cross-domain XHR requests.
Is there an easy way to do this? I though I might be able to do it using executeScript but it requires a tab ID.
The only way to know if you are in an ifrmae is the window is not the top.
if (window == top) {
// Not in iframe
}
else {
// In an iframe
}
You can only do that for content scripts, not for stylesheets. What I usually do is within the content script, I check if it isn't in the top window, and then continue the script, otherwise I just end it.
Recap
Inject the Content Script for that URL
In the content script, check if the window property, if (window != top) { loadContentScript() }
Create the CSS in the JavaScript if you are too worried about it affecting. You shouldn't though if you use unique ids.
Hope that helped, I do that for a few extensions of mine.
When I go to our web site through HTTPS mode, Chome is reporting an error saying that the page contains secure and not secure items. However, I used Firebug, Fiddler, and HttpDebuggerPro, all which are telling me that everything is going through HTTPS. Is this a bug in Chrome?
Sorry but I'm unable to give out the actual URL.
A bit late to the party here but I've been having issues recently and once I had found a http resource and changed it was still getting the red padlock symbol. When I closed the tab and opened a new one it changed to a green padlock so I guess Chrome caches this information for the lifetime of the tab
Current versions of Chrome will show the mixed content's URL in the error console. Hit CTRL+Shift+J and you'll see text like:
"The page at https://www.fiddler2.com/test/securepageinsecureimage.htm contains insecure content from http://www.fiddler2.com/Eric/images/me.jpg."
I was having the same issue: Chromium showing the non-secure static files, but when everything was http://.
Just closing the current tab and re-opening the page in another new tab worked, so I think this is a Chromium/Chrome bug.
Cheers,
Diogo
Using Chrome, if you open up the Developer Tools (View > Developer > Developer Tools) and bring up the Console and choose to filter to warnings, you'll see a list of offending URLs.
You'll see something like the following if you do have insecure content
The page at https://mysite/ displayed insecure content from http://insecureurl.
For the best experience in finding the culprit, you'll want to start your investigation in a new tab.
It is possible that a non-secure URL is referenced but not accessed (e.g. the codebase for a Flash <object>).
I ran into this problem when Jquery was being executing a a few seconds after page load which added a class containing a non-secure image background. Chrome must continually to check for any non-secure resources to be loaded.
See the code example below. If you had code like this, the green padlock is shown in Chrome for about 5 seconds until the deferred class is applied to the div.
setTimeout(function() {
$("#some-div").addClass("deferred")
}, 5000);
.deferred
{
background: url(http://not-secure.com/not-secure.jpg"
}
Check the source of the page for any external objects (scripts, stylesheets, images, objects) linked using http://... rather than https://... or a relative path. Change the links to use relative paths, or absolute paths without protocol, i.e. href="/path/to/file".
If all that if fine, it could be something included from Javascript. For example, the Google Analytics code uses document.write to add a new script to the page, but it has code to check for HTTPS in case the calling page is secure:
<script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
</script>
On the release of Chrome version 53 on Windows, Google has changed the trust indications to initiate the circle-i. Afterward, Google has announced a new warning message will be issued when a website is not using HTTPS.
From 2017 January Start, Popular web browser Chrome will begin
labeling HTTP sites as “Not Secure” [Which transmit passwords / ask
for credit card details]
If all your resources are indeed secure, then it is a bug. http://code.google.com/p/chromium/issues/detail?id=72015 . Luckily it was fixed.