Docs claim that:
By adding hosts or host match patterns (or both) to the permissions section of the manifest file, the extension can request access to remote servers outside of its origin
My ≪manifest.json≫:
{"manifest_version":2,"name":"","version":"0","permissions":["http://example.org/"],"background":{"scripts":["asd"]}}
≪asd≫:
navigator.serviceWorker.register('sdf.js',{scope:'http://example.org/'}).then(x=>console.log('done', x))
≪sdf.js≫:
addEventListener('fetch', e=> e.respondWith(new Response('url: '+e.request.url,{headers:{'content-type':'text/html'/*, etc*/}})))
I loaded the code using ≪Load unpacked extension≫; It crashed without any error message:
Apparently the code "permissions":["http://example.org/"] crashed the extension.
How to set permissions for Chrome Extension cross-origin serviceworker? Is there a required Chrome flag?
As various folks have pointed out in the comments, it's not possible for a service worker to control a Chrome Extension, and it's not possible to register a service worker scoped to an https: origin within the context of a Chrome Extension.
Related
As stated in the title, I am trying to convert a web extension originally made for chrome to safari, using the tool documented at https://developer.apple.com/documentation/safariservices/safari_web_extensions/converting_a_web_extension_for_safari
The project is created, builds, and launches successfully, however when the extension is enabled in safari I get 2 errors:
"An extension with a non-persistent background page cannot listen to webRequest events."
"The service_worker script failed to load due to an error."
The first error is a general bug in chromium, which is fixed in v107 (verified in chrome canary), and the extension relies on this API to work.
I have no idea what to do with the second error, as it provides no information at all. The option to access the background page process is disabled in the Safari Develop menu with the message "service worker failed to load".
Here is my "manifest.json"
{
"name":"...",
"manifest_version":3,
"content_scripts":[{"all_frames":false,"js":["content.js"],"matches":["file://*/*","http://*/*","https://*/*"],"run_at":"document_idle","match_origin_as_fallback":true}],
"host_permissions":["<all_urls>"],
"permissions":["tabs","activeTab","storage","scripting","notifications","webRequest","downloads","alarms"],
"background":{"service_worker":"background.js"},
"content_security_policy":{"extension_pages":"script-src 'self' 'wasm-unsafe-eval'; object-src 'self'"},
"web_accessible_resources":[{"resources":["inject.js"],"matches":["<all_urls>"]}],
"action":{"default_popup":"popup.html"},
"icons":{"16":"resources/icons/16x16.png","32":"resources/icons/32x32.png","48":"resources/icons/48x48.png","128":"resources/icons/128x128.png"},
"commands":{"_execute_action":{"suggested_key":{"default":"Shift+Alt+C"},"description":"Start the extension"}},
"version":"0.7.5",
"description":"...",
"author":"..."
}
Does anyone have any good suggestions/knowledge on how to debug why the service worker doesn't load? The extension works without any errors or warnings in Google Chrome.
The webRequest api doesn't seem to be available in safari when using manifest v3, and is a blocking issue, meaning the problem cannot currently be solved.
Furthermore storage.session also caused the service worker to crash, but this could be mitigated by using storage.local instead.
Will have to wait and see if safari supports the webRequest API in the future.
When i debug javaScript on devtool.
chrome.runtime
see "http://www.qq.com",it show:
chrome.runtime is undefined. see http preview.
But when i debug it on https site (https://www.qq.com ).it work fine. see https preview.
tips: all script run on top frame.
Can i change "chorme:flags" to enable it ?
i got why now.
"chrome.runtime.sendMessage" not exist when no extension installed.---since chrome 66+.
see:https://bugs.chromium.org/p/chromium/issues/detail?id=835287
Comment 29 by rdevlin....#chromium.org, Apr 25 For at least some of
these cases from the duped bugs, I think this was caused by revision
39f8939309fe39bccc17fa1280b6c7f25c411947. This modified the
externally_connectable property of the cryptotoken component extension
(automatically built into Chrome) to only accept incoming connections
from https URLs, whereas previously it was all URLs. When it was set
to all URLs, chrome.runtime.sendMessage would always be available
because any URL could potentially send a message to the cryptotoken
component extension.
However, this is working as intended. The cryptotoken extension only
accepts connections from https origins (so any others would be
ignored), and sending a message to any other extension would require
the receiving extension to list the URL in the externally_connectable
options. Additionally, this means that before, any extension relying
on this behavior would likely have failed to send the message, but
done so asynchronously (once the message failed to find an appropriate
receiver) rather than synchronously (since runtime is undefined). If
the extension lists the URL in externally_connectable, then
chrome.runtime should still be present. If the extension does not
list the site in externally_connectable, then chrome.runtime not being
available is intended behavior.
Is there any case in which chrome.runtime is undefined for
non-sandboxed chrome-extension:// pages, or for web pages where an
installed extension specifies that web page's URL in the
externally_connectable field of the manifest? If so, please attach an
extension that demonstrates this issue. If not, this sounds like it's
WAI.
fix: add one extionsion with:manifest.
"externally_connectable": {
"ids": [
"*"
],
"matches": [
"http://test.yoursite.in:9090/*",
"*://*.chromium.org/*"
]
},
thinks all.
I'm working on a chrome extension which must get in touch with some apis.
The first version had this permission in the manifest :
"permissions": [ "API_1" ],
And I could contact this API:
var xhr = new XMLHttpRequest();
xhr.open('GET', "API_1" + someArguments, true);
xhr.onreadystatechange = function()
{
// ...
}
This version is already published, but now I need my extension to contact another API, so I'm using the same code with the new API:
var xhr = new XMLHttpRequest();
xhr.open('GET', "API_2" + someArguments, true);
xhr.onreadystatechange = function()
{
// ...
}
In this new version I don't have any warning or error whatever there is no permission for "API_2". If I add permission for API_2, installed extensions will be disabled on update. So my question is : Are permissions for API_1 and API_2 really mandatory?
If that's all you're using the API host permission for, it depends on exactly one thing: CORS policy of the remote server.
When making XHR requests, if the request is cross-domain (which, from an extension, always except for content scripts on that same domain) - Chrome will examine CORS headers in server's reply.
By default, if the server does not indicate anything, cross-domain requests are not allowed by the web security model. This is typical if you're requesting something that was never intended to be a public API. Listing the API match pattern in permissions overrides this.
However, for public API it is typical to include a permissive CORS header (after all, other web applications that may use this API cannot override the security model, only extensions can). In that case, the permission is not necessary.
Its hard to know without listing the API's, but google's documentation provides a simple way to check how new permissions will affect warnings:
If you'd like to see exactly which warnings your users will get, package your extension into a .crx file, and install it.
To see the warnings users will get when your extension is autoupdated, you can go to a little more trouble and set up an autoupdate server. To do this, first create an update manifest and point to it from your extension, using the "update_url" key (see Autoupdating). Next, package the extension into a new .crx file, and install the app from this .crx file. Now, change the extension's manifest to contain the new permissions, and repackage the extension. Finally, update the extension (and all other extensions that have outstanding updates) by clicking the chrome://extensions page's Update extensions now button.
Basically, create two test extensions, one being your original and another being your updated. Follow this process to go through a simulated update, and you will see what warnings you get, if any.
If you leave out API_2 permissions in the update and everything is fine, then its permissions are not mandatory to include in the manifest.
Source
I built a chrome extension. I don't want to host it (yet) in the chrome webstore. I want to self host it. I have packaged the .crx, and deployed it to my localhost. Here is the code I use to serve it:
app.get('/myext.crx', function(req, res){
var file = __dirname + '/public/myext.crx';
res.download(file);
});
Then I have an anchor tag that points to the file:
Install <strong>myExt for Chrome</strong>
When it downloads, it has the correct content-type header (per the instructions http://developer.chrome.com/extensions/hosting.html). Here is the info from the Network tab in Chrome Devtools when I click the anchor:
**Response Headers**
Connection:keep-alive
Content-Description:File Transfer
Content-disposition:attachment; filename=myext.crx
Content-type:application/x-chrome-extension
Date:Sat, 14 Dec 2013 07:09:46 GMT
Transfer-Encoding:chunked
X-Powered-By:Express
It all looks good, but Chrome still shows me the yellow banner error saying "Apps, extensions, and user scripts cannot be added from this website".
Am I missing a setting in the manifest? Can someone tell me what the issue is? Does it have anything to do with the fact that I am serving on localhost and the "homepage_url" and the "update_url" both point to my actual domain name?
Anyone, please.
UPDATE
It downloads the file, but gives me the aforementioned error. If I open Tools > Extensions and then drag the file from the bottom of Chrome onto the Extensions page, it won't install it. Nothing happens. HOWEVER, if I open a Finder window and drag it from the Finder window onto Tools > Extensions page, it installs fine.
Not sure if this info helps or not.
Chrome is starting to block extension installs that are not from the Chrome Web Store. If you don't want an extension to be fully published in the CWS, you can limit the audience with the publish to test accounts or accessible by URL only features.
I'm trying to use SignalR in a chrome extension on a background page.
Everything seems to work fine until it tries to call negotiate. It seems to be taking the caller (which is a chrome-extension background page) and trying to call negotiate against that, which gives me a 404 while trying to call this page:
chrome-extension://edcdcfjmmmchhgmomfemdkomibeoloko/signalr/negotiate?_=1372007788595
I'd imagine that it should be calling
https://myserver.com/signalr/negotiate?_=1372007788595
But I don't know how to override SignalR with a specific host. Can I override SignalR to work in a chrome extension on a background page
I assume it is javascript you are using? Try
$.connection.hub.url = "http://myserver.com/signalr";
This took me a couple hours to figure out but here's a few steps to get going on making signalr work with a google chrome extension.
Place within the javascript
$.connection.hub.url = "http://yoursever.com/signalr"`
Within the manifest.json file for the google chrome you must give permission to access the server. I would add something like this to make it easy.
"permissions": [
"http://*/*",
"https://*/*"
]
Within your global configuration you need to change allow cross domain requests. Change
RouteTable.Routes.MapHubs()
to
RouteTable.Routes.MapHubs(new HubConfiguration()
{
EnableCrossDomain = true
});