I see that there is no way to inspect the body with declarativeNetRequest.
https://developer.chrome.com/docs/extensions/mv3/mv3-migration-checklist/ indicates I should replace webRequestBlocking with declarativeNetRequest permission. But it doesn’t say that chrome.webRequest API is deprecated in v3 (it looks like it is) or how long will it continue to work with manifest v2.
Should I stick with manifest v2 even though I don’t know how long it will last?
Google says they made this change for privacy reasons but I don’t see them removing content scripts...
Related
I am in the process of migrating from Manifest V2 to V3, from Web Request API to Declarative Net Request API. Using Web Request, I modify the "content-security-policy" header by adding a domain into the list of various directives (default-src, frame-src, etc). I tried using the "append" operation in the rule action. Is it possible to target a directive? What if the directive does not exist? Does append just add the supplied string to the end? With Web Request, I was able to examine each directive and update each accordingly, before returning the new value. This allowed me to inject a script that is needed into each frame.
Instead, would it be possible to continue to use the Web Request API with V3? In my setup, I have my chrome extension "Published - unlisted". I do use the force install option when deploying the extension to our internal users, and the only reason I have it unlisted and not private is so that the users who have the extension can get updated whenever a new version is released. Would it be possible to have users updated without having the extension listed? Perhaps by hosting the extension in my own server? Please advise on what can be done to have the ability to update the response header, specifically the "content-security-policy" header the way I have done before, and whether I can continue to use Web Request API going forward (using V3). In the Chrome dev website, there's a mention about continuing to use Web Request if force install is used, and only if its "deployed to a given domain or to trusted testers", but I'm not sure what that actually means. What would I need to do to meet the criteria?
I tried using the append operation in the rule action via the Declarative Net Request API, but its not working as expected. I dont see the security policy being updated when I inspect the response header in dev tools. I also get errors stating that many scripts, images, etc violate the security policy for websites that did not have one to begin with (My extension targets any website).
I am trying to override navigator.useragent with a chrome extension. I see examples where people call the script to run in v2 extensions, but I don't know with CSP if that is possible with v3. I have a v3 extension and want to add this new feature, but I don't know if the content script can redefine it, if I need to inject a script somehow (and get it past CSP), or if there is something else to do.
I would like to append the word "Test" to the user agent retrieved in the app by navigator.useragent and also in the headers that get sent, but I am focused on the first half of the problem first.
I am trying to implement a Google+ sign in option as part of a chrome extension using the one-time code flow as described here.
While making a request using the javascript Google API package a popup opens with an "origin_mismatch" error. This is obviously since I need to add my origin to the relevant Client Id on the Google API console.
My origin is : chrome-extension://<my extension id> however when trying to add that on the API console I get an error saying "Invalid URI: chrome-extension://..." which probably means this scheme is not supported.
Any idea what I can do instead?
I've faced the same problem. I think Google has changed the validation for javascript origins and doesn't allow origins from chrome-extension any more. Google gives you the Chrome Identity API instead (https://developer.chrome.com/apps/app_identity)
But there is a workaround. If you already have at least one chrome-extension://[ext_id] origin in your client ID and you have for example the older version of your extension with this extension ID, you can:
install this extension
go to C:\Users\username\AppData\Local\Google\Chrome\User Data\Default\Extensions (for windows)
find your extension there and open the manifest.json
copy the line "key":"[your_key]" and paste it into your developed manifest
and after next build you should get the extension with the same id as it was in the working one. Also it won't change any more.
Old Opera 12 had an easy option to build own ad-blocking extension: http://dev.opera.com/articles/view/extensions-api-urlfilter/
My question is: Is there a similar thing in google chrome extension format ? (also this should apply for new opera series)
(This is a question also about how various adblocks for chrome are made. I mean do these extensions actually block traffic before the browser sends request ? Is this capacity available in chrome extensions ?)
There are two APIs that can be used for blocking web content:
The chrome.webRequest API.
The chrome.declarativeWebRequest API.
The declarativeWebRequest is currently only available on the dev channel, but I expect that it will become available on the stable channel within a few releases. Although it's possible to block requests using the webRequest API, I recommend to use the declarative one, because it's more efficient, in two ways: it allows you to use event pages instead of background pages, and the filters are fully implemented in native code.
The format of the URL filters of the declarativeWebRequest API are very expressive, its format can be found at https://developer.chrome.com/extensions/events.html#type-UrlFilter.
The format of the URL filter in the declarativeWebRequest API follows the format of a match pattern (similar to Opera's url filter).
I've posted a simple example of both APIs at Block URL with a specific word somewhere in the subdomain. Don't forget to declare the right permissions in the manifest file. Either "declarativeWebRequest" or "webRequest", "webRequestBlocking". To block an URL using the webRequest API, you must also request permissions to access the URLs you want to block in the manifest file.
I have developed a Google Chrome extensions that uses YouTube Data API v2. My permission field in the manifest looks like this, because the script is injected in pages under youtube.com and I also need access to tabs:
"permissions": ["tabs", "*://*.youtube.com/*"]
This also works when I do a request to YouTube Data API v2 because the request is done to http://gdata.youtube.com/, so it is the same domain. But now I am migrating to YouTube Data API v3, and the requests must be done to http://www.googleapis.com/youtube/v3/ (note HTTPS instead of HTTP also). However, surprisingly, my requests are working perfectly without adding any new permission.
I know, I am asking something that doesn't seem to be a problem, but personally I consider any behavior that I don't understand in my software a problem. Why does this happen? Am I not supposed to add a permission such as "*://*.googleapis.com/*" in order for my XMLHttpRequest requests to the API to work?
I also have some king of guess about this: HTTP Access Control headers. My requests do send a Origin header with value chrome-extension://myExtensionId. And the answer from the API also contains the following header:
Access-Control-Allow-Origin: chrome-extension://myExtensionId
But could this be the reason Chrome is allowing me to do a cross-origin XMLHttpRequest without any extra permission defined in the manifest? Not sure, and apparently this is not documented anywhere in Google APIs, YouTube Data API v3 or Chrome Extensions developer documentation.
If Chrome does not find the permission in the manifest, it treats a request as a normal request. This means that a request will still succeed when the right CORS headers are set. Otherwise, a request will fail because of the same origin policy.
The Google API JavaScript library explicitly mentions support for CORS:
Making a request: Option 3
Google APIs support CORS. Please visit the CORS page for more information on using CORS to make requests.
If possible, I still recommend adding the permission to the manifest file. For simple requests, this does not bring any advantages. For non-simple requests, this will half the number of requests: Non-simple requests are always preceeded by a preflight (OPTIONS) request which checks if the client is permitted to access the source.
By adding the permission to the manifest file, Chrome will not fall back to CORS, and always use one network request to complete the request. Great!
However... you might think again if you're the author of an already-deployed extension. When new origin permissions are added to the manifest file, the extension will be disabled until the user approves the extension. The dialog box shows "Remove extension" and "Enable" next to each other, so there's a chance of loosing the user.
If you wish, you can overcome this problem by using an optional permission, activated at the options page. Clearly explain in layman language that the option will improve the speed of the extension, and don't forget to mention that additional permissions will be requested.