Setting HTTP headers from a Firefox extension - firefox

How can I set HTTP headers in my Firefox extension?
I'll make it so these are only sent while hitting my site so I can detect if the plugin is installed or not and not promote the plugin if it is.

Here's the most compact way I found to make this work:
Components.classes["#mozilla.org/observer-service;1"].getService(Components.interfaces.nsIObserverService ).addObserver({
observe : function(subject, topic, data) {
var channel = subject.QueryInterface( Components.interfaces.nsIHttpChannel );
if ( /mysite/.test( channel.originalURI.host ) ) {
channel.setRequestHeader("x-mysite-extended", "true", false);
}
}
},"http-on-modify-request",false);

There are a few existing Firefox extensions that modify HTTP headers en route to the server, and at least one of them, modifyheaders, has open source code.
Or, of course, there's the relevant page in the Mozilla Developer Center, Setting HTTP request headers.

Related

Chromecast Failed to play hls encrypted custom asset

CustomReceiverApplication : CastReferencePlayer-master (github)
SenderApplication : CastVideosSample (github)
With the above applications chrome cast is able to play un-encrypted custom asset, but failed to play encrypted asset.
Modification in CastReferencePlayer-master::player.js
below lines are added.
host.licenseUrl = "http://192.168.6.135/mpeg/key123";
host.updateSegmentRequestInfo = function (requestInfo)
{
requestInfo.withCredentials = true;
requestInfo.headers = {};
requestInfo.headers['origin'] = info.message.media.customData.origin;
requestInfo.headers['content-type'] = info.message.media.contentType;
requestInfo.headers['accept-encoding'] = 'gzip';
}
Errors from chrome-cast debug log.
Refused to set unsafe header "origin"
Refused to set unsafe header "accept-encoding"
Please find below link to download the logfile.
https://drive.google.com/open?id=0B1Nd3ciEQ3CIeGdVM2FsYVNGWk0
According to this link, usually it appears only in Webkit based browsers. Basically a browser like Google Chrome will not change certain http headers in an XMLHttpRequest using setRequestHeader(). Make sure you check your sources before you use things like external scripts. Try to set the header to Access-Control-Expose-Headers: Content-Length.

Firefox Add-on SDK extension with Websocket doesn't work for Facebook/Twitter

I'm developing a Firefox extension based on Addon SDK.
Inside my content script, I need to create WebSocket connection to my localhost server using wss.
In my addon script (index.js), I use "sdk/tabs" to inject content script.
var tabs = require("sdk/tabs");
tabs.on("ready", function(tab){
var worker = tab.attach({
contentScriptFile: ["./websocket.js"]
});
});
data/websocket.js looks like:
websocket = new WebSocket("wss://localhost:8443/WebsocketServer/");
websocket.onopen = function(evt){
console.log("connection open");
websocket.send("connection established!");
};
websocket.onmessage = function(evt){
console.log("message received: "+evt.data);
};
I open firefox and open a page with https://localhost:8443/ and accept the certificate. So the certificate won't be a problem here.
I can open a normal http page and this addon works perfectly, talks to my websocket server. Also I can make it work if I open https://google.com.
But when I open https://www.facebook.com or https://www.twitter.com, the websocket connection cannot be established.
When I turn on developer console, i can see error message:
Content Security Policy: The page's settings blocked the loading of a
resource at wss://localhost:8443/WebsocketServer/ ("connect-src
https://graph.facebook.com https://*.giphy.com https://pay.twitter.com
https://analytics.twitter.com https://media.riffsy.com
https://upload.twitter.com https://api.mapbox.com https://twitter.com").
Content Security Policy: The page's settings blocked the loading of a
resource at wss://localhost:8443/WebsocketServer/ ("connect-src
https://*.facebook.com https://*.fbcdn.net https://*.facebook.net
https://*.spotilocal.com:* https://*.akamaihd.net wss://*.facebook.com:*
https://fb.scanandcleanlocal.com:* https://*.atlassolutions.com
https://attachment.fbsbx.com ws://localhost:* blob:").
After I check, find facebook and twitter both implement the content script policy in their http header:
https://developer.mozilla.org/en-US/docs/Web/Security/CSP/Introducing_Content_Security_Policy
But I think this policy should be exempted for addon. How could I bypass this check and make my websocket connection also work on facebook and twitter also?
I found there is one link that uses XPCOMM to hyjack http header and bypass the CSP check, but this is not I'm looking for, as XPCOMM will be deprecated by firefox. Is there a more proper way of doing this?
Thanks a lot!

Detect data URI in links support with Modernizr

Using data URI in links (<a href="data:) is not supported in IE and Microsoft Edge (Data URI link <a href="data: doesn't work in Microsoft Edge).
I'm trying to use Modernizr to detect data URI in links support.
Modernizr.datauri is not quite what I'm looking for, as it does not tell anything about support data URI in links, e.g. for Microsoft Edge it returns object {over32kb: true}
How can I detect using Modernizr if data URI in links is supported in browser?
I had the same need for feature detection but I am not using Modernizr. My use case is that I'm generating a pdf on the client side with the makePDF library and was not able to open the PDFs using data URIs in IE or Edge. Unfortuantely, all the feature detection scripts I could find were testing for support of data URIs for images (which is supported by MS browsers) so I had to write my own. Here's the code (thanks to BoltClock's comment above for the idea):
checkDataURISupport(function (checkResult) {
if (checkResult) {
alert('Files in data URIs are supported.');
} else {
alert('Files in data URIs are NOT supported.');
}
})
function checkDataURISupport(callback) {
try {
var request = new XMLHttpRequest();
request.onload = function reqListener() {
callback(true);
};
request.onerror = function reqListener() {
callback(false);
};
request.open('GET', 'data:application/pdf;base64,cw==');
request.send();
} catch (ex) {
callback(false);
}
}
checkDataURISupport()
I tested in in IE 11, Edge 25, Firefox 46, and Chrome 49.
As a side note, another SO answer (https://stackoverflow.com/a/26003382/634650) suggested using:
supportsDataUri = 'download' in document.createElement('a');
This works in IE but not Edge.
Update
The SO answer above also includes a link to a SO answer referencing a Modernizr issue about feature detection for data URI in iframe support. Opening a data URI in an iframe is basically the same thing as opening one in a new windows and the Microsoft browsers which do not support data URIs in iframes don't support opening them in new windows. Additionally, the test for the iframe support mentioned in those locations is synchronous so I would recommend using it instead of my async solution.
It is weird that even Microsoft Edge is not supporting the data URI. Older versions of IE only allows base64 encoded images of up to 32KB. I had come across a reference link lately which relates to the similar issue you have mentioned with Moderinzr.
Does modernizr check for data uri's?#294
It appears they have added a patch for the issue. It is a data URI test.
This post has the similar answer regarding the issue. I hope these fixes should work throughout.

Cross-subdomain AJAX works in Chrome, not IE

I have a local build of my site running at local.mydomain.com. I'm making ajax requests to api.mydomain.com which is running on an AWS server and returns JSON. In Chrome, I can call the API no problem. But in IE, I get Access Denied.
After researching, it seems to be a cross-(sub)domain restriction. But I was under the impression that this restriction would apply to both browsers. Can anybody see what might be going wrong here and why it might work in some browsers and not others?
It looks like the problem was in the transport object that IE8+ wants you to use. jQuery uses either ActiveXObject (for IE) or XMLHttpRequest (all others), but IE 8 and above requires XDomainRequest for ajax.
What you can do is return a custom xhr object via $.ajaxSettings.xhr like this,
// override xhr for browser that use XDR
if ('XDomainRequest' in window && window.XDomainRequest !== null) {
// override default jQuery transport
jQuery.ajaxSettings.xhr = function() {
try { return new XDomainRequest(); }
catch(e) {
console.log('test');
}
};
// also, override the support check
jQuery.support.cors = true;
}
I pulled this code from a discussion on the subject here:
http://graphicmaniacs.com/note/getting-a-cross-domain-json-with-jquery-in-internet-explorer-8-and-later/
Definitely take a look at that if you think you're experiencing the same problem.

IE6+, how to change User-Agent for Ajax requests too?

I want to make own browser application with own value of User-Agent.
Browser based on CHtmlView. MFC.
But exist strange problem with User-Agent from Ajax requests...
I did:
User-Agent value is used as argument to Navigate(). A Navigate() requests use right User-Agent.
Overload of OnAmbientProperty() method of CHtmlView class.
BOOL MyHtmlView::OnAmbientProperty(COleControlSite *pSite,
DISPID dispid, VARIANT *pvar)
{
USES_CONVERSION;
// Change user agent for this web browser host during hyperlinks
if (dispid == DISPID_AMBIENT_USERAGENT)
{
pvar->vt = VT_BSTR;
pvar->bstrVal = ::SysAllocString(m_userAgent);
return TRUE;
}
return CHtmlView::OnAmbientProperty(pSite, dispid, pvar);
}
This solve problem with hyper link.
But I have to use this browser for some Ajax application.
And here is problem. For Ajax requests it use original IE User-Agent value.
My PC is WinXP based with IE7.
Any idea how to solve this?
How to change User-Agent for any request from my browser?
Thanks!
On ajax request, you can set the HTTP header "User-Agent" : http://www.w3.org/TR/2007/WD-XMLHttpRequest-20070618/#dfn-setrequestheader
I solved problem with UrlMkSetSessionOption(), it changed IE settings for current session only:
const char ua[] = "My user agent string";
HRESULT rez = UrlMkSetSessionOption(URLMON_OPTION_USERAGENT, (LPVOID)ua, sizeof(ua), 0);
Just one but, it change settings for once. Another calls return no error and no changes.
Some references:
Changing the user agent of the WebBrowser control

Resources