New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow user to set forbidden headers in XHR #2723

merged 7 commits into from Feb 5, 2018


None yet
4 participants

NoneGiven commented Nov 22, 2017

Even in WebExtensions, Firefox enforces per spec that Referer, Origin, and other headers may not be set by the developer on the XHR object. However, if the outgoing XHR is intercepted in the onBeforeSendHeaders event, it is possible to set these headers as desired.

This is a WIP This change currently looks for Referer and Origin and shows how GM can set the header values when the user supplies them the normal way, through the headers property of the object passed to GM.xmlHttpRequest. It's necessary for GM to add dummy headers to preserve the user's header values until onBeforeSendHeaders, at which point we can set the real header and delete the dummy.

Fixes #2599

NoneGiven added some commits Nov 22, 2017


This comment has been minimized.


xor10 commented Nov 22, 2017

Use originUrl to check if requests are from extension. :)
Should be allowed to modify the Host, Cookie and User-Agent headers too.

const extensionUrl = chrome.extension.getURL('');
function rewriteHeaders(detail) {
  // rewrite only requests from background script (GM.xmlHttpRequest)
  if (detail.originUrl && detail.originUrl.startsWith(extensionUrl)) {
    const newHeaders = [];

    return { requestHeaders: newHeaders };

  return { requestHeaders: detail.requestHeaders };

This comment has been minimized.


NoneGiven commented Nov 22, 2017

Thanks @xor10 ! I added the originUrl check and also rewrote the code to actually work (had some confusion over which objects were plain objects and which were arrays). I tested this with the modified GM code loaded into FF 58 and it works great.

Setting User-Agent is already possible. For the other two, maybe @arantius can decide on the final list of forbidden headers to support.

var prefixedHeader = getHeader(e.requestHeaders, dummyHeaderPrefix + name);
if (prefixedHeader) {
if (!getHeader(e.requestHeaders, name)) {
// only try to add real header if request doesn't already have it

This comment has been minimized.


Sxderp Dec 20, 2017


I'm not sure I understand the purpose of this conditional, could you provide an example of when getHeader may return true on line 147?

Further, under what condition would you not want to replace a header with the prefixed version?

This comment has been minimized.


NoneGiven Dec 23, 2017


It would return true for headers like Accept-Encoding and Connection that are always automatically set, if we were allowing the user to replace those.

under what condition would you not want to replace a header with the prefixed version?

I guess you wouldn't. Updated.

always replace headers; code style
Also `browser` -> `chrome`

@arantius arantius removed this from the 4.x milestone Jan 19, 2018

@soredake soredake referenced this pull request Jan 19, 2018


Работа с NoScript #1037


This comment has been minimized.


NoneGiven commented Jan 30, 2018

@arantius Anything I can do to move this PR along? Unlike that other one, this one works and has a legitimate goal (giving GM.xmlHttpRequest the same utility as the old GM_xmlhttpRequest).

Note: Will definitely want to include the Cookie header.


This comment has been minimized.


arantius commented Feb 5, 2018

Sorry! Merging now.

@arantius arantius added this to the 4.3 milestone Feb 5, 2018

@arantius arantius merged commit 885184c into greasemonkey:master Feb 5, 2018

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed

@NoneGiven NoneGiven deleted the NoneGiven:requestheaders-poc branch Feb 5, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment