I according to the chrome.webRequest I want to change data-urls responseheaders.But I can't capture data request in chrome.webRequest.onHeadersReceived.
Am I wrong ?
chrome.webRequest.onBeforeRequest.addListener(
function (details) {
const url = details.url
if(url == 'http://www.example.com/api/getUsers') {
return {
redirectUrl: 'data:application/json; charset=utf-8,' +
JSON.stringify({"a":1, "b": 2})
}
}
return {cancel: false}
},
{urls: ["<all_urls>"]},
["blocking"]
)
chrome.webRequest.onHeadersReceived.addListener(
function (details) {
console.log(details) // can't capture data-urls
return {responseHeaders:details.responseHeaders};
},
{urls: ["<all_urls>"]},
["responseHeaders","blocking"]
)
You can't capture data: URLs with webRequest API, since data: is not a supported scheme for host permissions.
As such, even with <all_urls> permission/filter you won't get events for data:
Documentation quote:
The webRequest API only exposes requests that the extension has permission to see, given its host permissions. Moreover, only the following schemes are accessible: http://, https://, ftp://, file://, ws:// (since Chrome 58), wss:// (since Chrome 58), or chrome-extension://.
I'm pretty sure there's already a feature request for this, but I can't currently find it.
Related
I can't see an answer to this in the Developer's Guide, though maybe I'm not looking in the right place.
I want to intercept HTTP requests with a Chrome Extension, and then forward it on, potentially with new/different HTTP headers - how can I do that?
PS: I am the author of Requestly - Chrome/Firefox extension to modify HTTP requests & responses.
It was certainly not possible when OP asked the question but now you can use WebRequest API with Manifest V2 and DeclarativeNetRequest API with Manifest V3 to write your own extension to modify Request & Response Headers.
Manifest V2 code
chrome.webRequest.onBeforeSendHeaders.addListener(
function(details) {
for (var i = 0; i < details.requestHeaders.length; ++i) {
if (details.requestHeaders[i].name === 'User-Agent') {
details.requestHeaders.splice(i, 1);
break;
}
}
return { requestHeaders: details.requestHeaders };
},
{urls: ['<all_urls>']},
['blocking', 'requestHeaders' /* , 'extraHeaders' */]
// uncomment 'extraHeaders' above in case of special headers since Chrome 72
// see https://developer.chrome.com/extensions/webRequest#life_cycle_footnote
);
Google Chrome is deprecating webRequest Blocking APIs in the Manifest V3. As per the official statement from Google on 28th Sep 2022, all extensions with Manifest v2 won't run on Chrome from June 2023 onwards. Here's an approach to Modify Request & Response headers with Manifest v3 - https://github.com/requestly/modify-headers-manifest-v3
Manifest V3 Code:
rules.ts
const allResourceTypes =
Object.values(chrome.declarativeNetRequest.ResourceType);
export default [
{
id: 1,
priority: 1,
action: {
type: chrome.declarativeNetRequest.RuleActionType.MODIFY_HEADERS,
requestHeaders: [
{
operation: chrome.declarativeNetRequest.HeaderOperation.SET,
header: 'x-test-request-header',
value: 'test-value',
},
]
},
condition: {
urlFilter: '/returnHeaders',
resourceTypes: allResourceTypes,
}
},
{
id: 2,
priority: 1,
action: {
type: chrome.declarativeNetRequest.RuleActionType.MODIFY_HEADERS,
responseHeaders: [
{
operation: chrome.declarativeNetRequest.HeaderOperation.SET,
header: 'x-test-response-header',
value: 'test-value',
},
]
},
condition: {
urlFilter: 'https://testheaders.com/exampleAPI',
resourceTypes: allResourceTypes,
}
},
];
background.ts
import rules from './rules';
chrome.declarativeNetRequest.updateDynamicRules({
removeRuleIds: rules.map((rule) => rule.id), // remove existing rules
addRules: rules
});
The complete source code is available in the GitHub repo - https://github.com/requestly/modify-headers-manifest-v3
If you want to use an existing Chrome/Firefox/Edge Extension, you can use Requestly which allows you to modify request and response headers. Have a look at this snapshot:
Modifying request headers ( https://developer.chrome.com/extensions/webRequest ) is supported in chrome 17.
You are looking at the right place, but intercepting HTTP requests does not exist yet, but the extension team is aware that it's a popular request and would like to get to it sometime in the near future.
Keep in mind that starting from chrome 72, some headers are not allowed unless you add extraHeaders in opt_extraInfoSpec
So the above example in #sachinjain024's answer will look something like this:
chrome.webRequest.onBeforeSendHeaders.addListener(
function(details) {
for (var i = 0; i < details.requestHeaders.length; ++i) {
if (details.requestHeaders[i].name === 'User-Agent') {
details.requestHeaders.splice(i, 1);
break;
}
}
return { requestHeaders: details.requestHeaders };
},
{urls: ['<all_urls>']},
[ 'blocking', 'requestHeaders', 'extraHeaders']
);
For more info, check the documentation Screenshot from the documentation https://developer.chrome.com/extensions/webRequest#life_cycle_footnote
For extensions using manifest version 3, you can no longer use chrome.webRequest.onBeforeSendHeaders.*. The alternative is chrome.declarativeNetRequest
Make the following changes in your manifest.json:
{
...
"manifest_version": 3,
"background": {
"service_worker": "background.js"
},
"host_permissions": ["<all_urls>"],
"permissions": [
"declarativeNetRequest"
],
...
}
💡 "<all_urls>" is for modifying all outgoing urls's headers. Restrict this for your scope of your work
Make the following changes in your background.js:
// ...
const MY_CUSTOM_RULE_ID = 1
chrome.declarativeNetRequest.updateDynamicRules({
removeRuleIds: [MY_CUSTOM_RULE_ID],
addRules: [
{
id: MY_CUSTOM_RULE_ID,
priority: 1,
action: {
type: "modifyHeaders",
requestHeaders: [
{
operation: "set",
header: "my-custom-header",
value: "my custom header value"
}
]
},
condition: {
"resourceTypes": ["main_frame", "sub_frame"]
},
}
],
});
Result
Read the docs https://developer.chrome.com/docs/extensions/reference/declarativeNetRequest/
You could install ModHeader extension and add headers:
You can use WebRequest API which is now deprecated it allows you to modify request/response headers.
You can upgrade your extension to Manifest V3 to be able to use DeclativeNetRequest which also supports modifying request/response headers.
Or you can install Inssman chrome extension.
It allows you to modify HTTP(S) request/response headers, reqirect and block request, return custom data like HTML/CSS/JS/JSON and more.
And it is open source project
I am developing a Chrome extension which makes requests from certain websites to an API I control. Until Chrome 73, the extension worked correctly. After upgrading to Chrome 73, I started getting the following error:
Cross-Origin Read Blocking (CORB) blocked cross origin response
http://localhost:3000/api/users/1 with MIME type application/json
According to Chrome's documentation on CORB, CORB will block the response of a request if all of the following are true:
The resource is a "data resource". Specifically, the content type is HTML, XML, JSON
The server responds with an X-Content-Type-Options: nosniff header, or if this header is omitted, Chrome detects the content type is one of HTML, XML, or JSON from inspecting the file
CORS does not explicitly allow access to the resource
Also, according to "Lessons from Spectre and Meltdown" (Google I/O 2018), it seems like it may be important to add mode: cors to fetch invocations, i.e., fetch(url, { mode: 'cors' }).
To try to fix this, I made the following changes:
First, I added the following headers to all responses from my API:
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: Content-Type
Access-Control-Allow-Methods: GET, POST
Access-Control-Allow-Origin: https://www.example.com
Second, I updated my fetch() invocation on the extension to look like this:
fetch(url, { credentials: 'include', mode: 'cors' })
However, these changes didn't work. What can I change to make my request not be blocked by CORB?
Based on the examples in "Changes to Cross-Origin Requests in Chrome Extension Content Scripts", I replaced all invocations of fetch with a new method fetchResource, that has a similar API, but delegates the fetch call to the background page:
// contentScript.js
function fetchResource(input, init) {
return new Promise((resolve, reject) => {
chrome.runtime.sendMessage({input, init}, messageResponse => {
const [response, error] = messageResponse;
if (response === null) {
reject(error);
} else {
// Use undefined on a 204 - No Content
const body = response.body ? new Blob([response.body]) : undefined;
resolve(new Response(body, {
status: response.status,
statusText: response.statusText,
}));
}
});
});
}
// background.js
chrome.runtime.onMessage.addListener(function(request, sender, sendResponse) {
fetch(request.input, request.init).then(function(response) {
return response.text().then(function(text) {
sendResponse([{
body: text,
status: response.status,
statusText: response.statusText,
}, null]);
});
}, function(error) {
sendResponse([null, error]);
});
return true;
});
This is the smallest set of changes I was able to make to my app that fixes the issue. (Note, extensions and background pages can only pass JSON-serializable objects between them, so we cannot simply pass the Fetch API Response object from the background page to the extension.)
Background pages are not affected by CORS or CORB, so the browser no longer blocks the responses from the API.
See https://www.chromium.org/Home/chromium-security/extension-content-script-fetches
To improve security, cross-origin fetches from content scripts are disallowed in Chrome Extensions since Chrome 85. Such requests can be made from extension background script instead, and relayed to content scripts when needed.
You can do that to avoid Cross-Origin.
Old content script, making a cross-origin fetch:
var itemId = 12345;
var url = "https://another-site.com/price-query?itemId=" +
encodeURIComponent(request.itemId);
fetch(url)
.then(response => response.text())
.then(text => parsePrice(text))
.then(price => ...)
.catch(error => ...)
New content script, asking its background page to fetch the data instead:
chrome.runtime.sendMessage(
{contentScriptQuery: "queryPrice", itemId: 12345},
price => ...);
New extension background page, fetching from a known URL and relaying data:
chrome.runtime.onMessage.addListener(
function(request, sender, sendResponse) {
if (request.contentScriptQuery == "queryPrice") {
var url = "https://another-site.com/price-query?itemId=" +
encodeURIComponent(request.itemId);
fetch(url)
.then(response => response.text())
.then(text => parsePrice(text))
.then(price => sendResponse(price))
.catch(error => ...)
return true; // Will respond asynchronously.
}
});
Allow the URL in manifest.json (more info):
ManifestV2 (classic): "permissions": ["https://another-site.com/"]
ManifestV3 (upcoming): "host_permissions": ["https://another-site.com/"]
Temporary solution: disable CORB with run command browser
--disable-features=CrossSiteDocumentBlockingAlways,CrossSiteDocumentBlockingIfIsolating
Example run command on Linux.
For Chrome:
chrome %U --disable-features=CrossSiteDocumentBlockingAlways,CrossSiteDocumentBlockingIfIsolating
For Chromium:
chromium-browser %U --disable-features=CrossSiteDocumentBlockingAlways,CrossSiteDocumentBlockingIfIsolating
Similar question.
Source.
I follow the tutorial here https://developer.chrome.com/apps/app_identity and use the api here https://developer.chrome.com/apps/identity but with no luck. Could anyone point out is anything wrong in this code?
function onGoogleLibraryLoaded() {
var redirect_uri = chrome.identity.getRedirectURL("http://qqibrow.github.io");
var full_url = "https://stackexchange.com/oauth/dialog?client_id=4716&redirect_uri=" + redirect_uri;
console.log(redirect_uri);
console.log(full_url);
chrome.identity.launchWebAuthFlow({
'url': full_url,
'interactive': true
}, authorizationCallback);
}
var authorizationCallback = function (data) {
// should print out redirect_uri with auth_token if succeed.
console.log(data);
};
// manifest.json
// ...
"permissions": [
"activeTab",
"identity",
"https://ajax.googleapis.com/",
"https://stackexchange.com/*",
"https://stackexchange.com/oauth/*",
"http://qqibrow.github.io/*"
],
"web_accessible_resources": [
"http://qqibrow.github.io/*",
"https://stackexchange.com/*",
],
// ...
If i try https://stackexchange.com/oauth/dialog?client_id=4716&redirect_uri=http://qqibrow.github.io it does work. But with above code, I always got a error page from stackexchange, saying that:
Application Login Failure error description: Cannot return to provided redirect_uri.
This is a creative usage of chrome.identity.getRedirectURL().
It does not allow you to redirect to an arbitrary domain; you can provide a path, but the domain for chrome.identity will be https://<app-id>.chromiumapp.org.
So, your call returns https://<app-id>.chromiumapp.org/http://qqibrow.github.io which is not a valid URL, and your auth fails.
I recommend re-reading the launchWebAuthFlow documentation.
I am working with ArcGIS, Esri request and I am trying to get a data from a webserver, but everytime I got the same "unexpected token : " error even when my response is correct.
Thanks in advance.
Here's my code:
require(["dojo/dom", "dojo/on", "dojo/dom-class", "dojo/_base/json", "esri/urlUtils", "esri/config", "esri/request", "dojo/domReady!"], function(dom, on, domClass, dojoJson, urlUtils, esriConfig, esriRequest) {
// fallback to proxy for non-CORS capable browsers
// esri.config.defaults.io.proxyUrl = "/arcgisserver/apis/javascript/proxy/proxy.ashx";
esriConfig.defaults.io.proxyUrl = "/proxy/proxy.ashx";
dom.byId("url").value = "http://api.citybik.es/v2/networks/dublinbikes";
dom.byId("content").value = "";
//handle the Go button's click event
on(dom.byId("submitRequest"), "click", getContent);
function getContent(){
var contentDiv = dom.byId("content");
contentDiv.value = "";
domClass.remove(contentDiv, "failure");
dom.byId("status").innerHTML = "Downloading...";
// //get the url
// var url = urlUtils.urlToObject(dom.byId("url").value);
// console.log("EL URL path",url.path)
// console.log("EL URL query",url.query)
// var requestHandle = esriRequest({
// "url": url.path,
// "content": url.query
// });
// requestHandle.then(requestSucceeded, requestFailed);
function requestSucceeded(data) {
console.log(data);
}
function requestFailed(error) {
console.log("Error: ", error.message);
}
var request = esriRequest({
url: "http://api.citybik.es/v2/networks/dublinbikes",
content: {
format: "json"
},
handleAs: "json",
callbackParamName: "retrive"
});
request.then(requestSucceeded, requestFailed);
}
}
);
Im getting:
Uncaught SyntaxError: Unexpected token : dublinbikes:2
The root problem is that you're getting esri.request a bit confused with what you're asking for, and what the server is giving back. Because you're making a request on a different domain (api.citybik.es) from where you're running the code (whatever your host is), you need to use either:
CORS
JSONP
a proxy
to get around the browser's security restrictions. There's plenty of detail on SO about these, I won't dribble on further.
Your code has two methods configured - the callbackParamName tells esri.request to use JSONP, and you've also got a proxy set just in case. The callbackParamName tells it to only use JSONP though, so the proxy is ignored.
Now the real problem, as I noted in a comment above, is that v2 of the CityBikes API doesn't actually seem to support JSONP, so your callback parameter is ignored and the server gives you back straight JSON. esri.request is expecting JSONP, and voila - unexpected token :. Requesting
http://api.citybik.es/v2/networks/dublinbikes?callback=stackoverflow
returns:
{
network: {
company: "JCDecaux",
href: "/v2/networks/dublinbikes",
....
See? No mention of our stackoverflow variable. If you look at v1 of the API instead, that DOES support JSONP. Requesting
http://api.citybik.es/dublinbikes.json?callback=stackoverflow
returns:
stackoverflow(
[
{
bikes: 1,
name: "Fenian Street",
idx: 0,
....
...and there is our stackoverflow variable. OR you can remove the callbackParamName from your esriRequest, and see if your proxy will process the JSON from the v2 address.
Based on this documentation: https://developer.chrome.com/extensions/webRequest.html#event-onHeadersReceived
I tried to display the response via the console like:
console.log(info.responseHeaders);
But its returning undefined.
But this works though:
console.log("Type: " + info.type);
Please help, I really need to get the responseHeaders data.
You have to request the response headers like this:
chrome.webRequest.onHeadersReceived.addListener(function(details){
console.log(details.responseHeaders);
},
{urls: ["http://*/*"]},["responseHeaders"]);
An example of use. This is one instance of how I use the webRequest api in my extension. (Only showing partial incomplete code)
I need to indirectly access some server data and I do that by making use of a 302 redirect page. I send a Head request to the desired url like this:
$.ajax({
url: url,
type: "HEAD"
success: function(data,status,jqXHR){
//If this was not a HEAD request, `data` would contain the response
//But in my case all I need are the headers so `data` is empty
comparePosts(jqXHR.getResponseHeader('redirUrl')); //where I handle the data
}
});
And then I silently kill the redirect while scraping the location header for my own uses using the webRequest api:
chrome.webRequest.onHeadersReceived.addListener(function(details){
if(details.method == "HEAD"){
var redirUrl;
details.responseHeaders.forEach(function(v,i,a){
if(v.name == "Location"){
redirUrl = v.value;
details.responseHeaders.splice(i,1);
}
});
details.responseHeaders.push({name:"redirUrl",value:redirUrl});
return {responseHeaders:details.responseHeaders}; //I kill the redirect
}
},
{urls: ["http://*/*"]},["responseHeaders","blocking"]);
I actually handle the data inside the onHeadersReceived listener, but this way shows where the response data would be.