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).
Related
I'm reading about chrome extension API feature to read or block network requests. I want to create an extension that will give to the user the ability to add sites to a list of restricted websites and that will block each request to each site that user add into this list.
If I understand I need to create some static ruleset files, but this means that I need to bundle the list with the extension and this isn't exactly what I want to achive.
In mv2 extensions there was the ability to block requests dynamically, but is this possible with mv3?
Is there any way with chrome api to block requests to a website using a local dynamic list of sites that is saved in local storage?
Into the docs isn't explained clearly how chrome will update the rules. My idea is to have a context menu that add a rule.
I am having a SharePoint-based application, using which I need to perform load testing.
But When I m recording the script, the response is not as same as the browser, and thus unable to get what needs to be done
And in first 2 requests:
get page
post login
in these, there is no dynamic value, so I am not able to understand it.
First of all add HTTP Cookie Manager to your test plan
Second check all fields of the request from the browser (i.e. using browser developer tools) and JMeter and pay attention to URL and Headers
And last but not the least very often Sharepoint installations are protected using NTLM or Kerberos, if this is the case you will need to add properly configured HTTP Authorization Manager, see Windows Authentication with Apache JMeter article for more details.
I'm trying to use the auth0-chrome package to authenticate my users. I've followed their "Using the Library" section (set up a new native type application in my tenant and configured the Allowed Callback URLs and Allowed Origins). When emitting my authenticate event to my background script and calling the authenticate() method on the new Auth0Chrome instance, I get the error
Authorization page could not be loaded
My current theory is that since the allowed origin's format in the example is https://<extension-id>.chromiumapps.org and I can't currently access that page. Is there a certain visibility level for a Chrome extension to have a valid URL (e.g. atm for a privately published extension, the *.chromiumapp.org URL is invalid).
I thought a code example is not needed, since I'm literally using the default example's code with my extension ID replaced.
I have double checked and my ID is the same for the auth0 application config, my unpacked extension in my browser and for the configured code. I'm using a manifest key to persist the extension ID if that's of any value.
So turns out the documentation lists the callback url example as https://<yourchromeappid>.chromiumapps.org/auth0, but it should be https://<yourchromeappid>.chromiumapp.org/auth0 - without the s at the end of chromiumapp.
That was the only change required to making it work. I've proposed an update for their documentation as well.
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.