We Keep Coding

Authorization header using OAuth1.0A for Twitter API v1.1

I am building a search engine as a start-up project in Web Development. The search engine takes a string and queries the Wiki and Twitter API. I have been working on it for days and, I believe, I have found a nice, clean way to implement it.
BoyCook's TwitterJSClient
In his code (which is beautifully written) he has set up a Twitter function which takes in a config variable and sets up the authorization for us. Is there something it is missing? I have been through it and it all looks great. I am new to Javascript and might be missing something..
My code:
var error = function (err, response, body) {
console.log('ERROR [%s]', err);
};
var success = function (data) {
console.log('Data [%s]', data);
};
var config = {
"consumerKey": "{Mine}",
"consumerSecret": "{Mine}",
"accessToken": "{Mine}",
"accessTokenSecret": "{Mine}",
"callBackUrl": ""
}
var Twitter = require('twitter-node-client').Twitter;
var twitter = new Twitter(config);
twitter.getSearch({'q':'Lebron James','count': 10}, error, success);
Can anyone help? Have you done this before and know an easier way? Has anyone been able to get it working using postMessage()?
And yes... the origin is using HTTPS protocol. See: JBEngine. My app permission (on Twitter) is set to read only.
[EDIT] Should probably also mention that I glob'd it all together with browserify and am running the script client-side.

"SCRIPT5: Access is denied" error when accessing web sites using LocalStorage

One of our client is getting ""SCRIPT5: Access is denied" error when accessing web sites on Windows 8.1/IE11. Only one client is having this issue not all.
when we looked at the error message it turns ut it failed when tried to access
_global.localStorage
Client said its working fine if they add our site in "Trusted Site".
the problem we having is that none of our dev/test environments has this issue.we are running same version of OS and IE as client. so we are having bit difficulty trying to reproduce this issue.
sa mentioned here
Access Denied for localstorage in IE10
i have tried turn on/off DOMStorage/Enhance Protection Mode/Protection Mode but still no luck.
our best guess so far is there must be some setting/group policy which applied by Client's IT dept which causes this issue rather code issue as it works for all other clients.
so my question here is
which setting/group policy/domain setting i can check so that i can reproduce this error.
How can i fix the issue w/o making any code change as client has more than 1000 users so only changing the policy by IT dept is the only option here rather asking every user to add to "Trusted Site"
is there anything that i missed to check.
any help would be awesome.

I had the same issue and solved it in the next way:
let storage;
try {
storage = localStorage; // throws error if not supported by browser
} catch(e) { // caching this error and assigning fallback
let innerStorage = {};
storage = {
getItem: function(e) {
return innerStorage[e]
},
setItem: function(e, i) {
return innerStorage[e] = i
},
removeItem: function(e) {
delete innerStorage[e]
}
}
Best regards,
Aleh

Capture screen -- chrome.desktopCapture.chooseDesktopMedia fails -- PNacl extension

I'm trying to use the desktopCapture API in the following manner.
chrome.desktopCapture.chooseDesktopMedia(
["screen", "window"], onAccessApproved);
chrome.desktopCapture shows as undefined when I set a breakpoint and inspect it. Permissions in my manifest file are as follows:-
"permissions": ["desktopCapture", "notifications" ]
Common causes for failure of this API are listed here as
a permission is missing in the application's manifest.json file
the API is defined on a newer version of Chrome then the current runtime
docs inherited from ChromeApi
And I don't have those problems.
My Chrome version is 43.0.2357.124 m
Pepper version is 43
FYI, I am trying to develop a Chrome extension to capture the screen using PNacl, and have borrowed from the media_stream_video example downloaded from here. But I haven't even gotten to sending a message to the pexe side yet. I'm still stuck at chrome.desktopCapture.chooseDesktopMedia returning undefined.

You need to call chrome.desktopCapture.chooseDesktopMedia from the background script running in the context of the extension. This Sample shows a simple method to use the extension to get screen media.
Keep in mind that this is callback based, so you get access to the stream id from the callback.
This runs in the context of your page (see full example here):
// check that the extension is installed
if (sessionStorage.getScreenMediaJSExtensionId) {
// send a message to your extension requesting media
chrome.runtime.sendMessage(sessionStorage.getScreenMediaJSExtensionId,
{type:'getScreen', id: 1}, null,
function (data) {
if (data.sourceId === '') { // user canceled
// handle error
} else {
constraints.video.mandatory.chromeMediaSourceId = data.sourceId;
getUserMedia(constraints, callback);
}
}
);
}
And this run in the context of your extension (see full example here):
chrome.runtime.onMessageExternal.addListener(function (message, sender, callback) {
switch(message.type) {
case 'getScreen':
var pending = chrome.desktopCapture.chooseDesktopMedia(message.options || ['screen', 'window'],
sender.tab, function (streamid) {
// communicate this string to the app so it can call getUserMedia with it
message.type = 'gotScreen';
message.sourceId = streamid;
callback(message);
return false;
});
return true; // retain callback for chooseDesktopMedia result
}
});

Modifying the Referer request header through a Google Chrome extension

I've got the following code which attempts to ensure that a Referer header is set when issuing requests:
chrome.webRequest.onBeforeSendHeaders.addListener(function (info) {
var refererRequestHeader = _.find(info.requestHeaders, function (requestHeader) {
return requestHeader.name === 'Referer';
});
var refererUrl = info.url.substring(0, info.url.indexOf('/embed/'));
if (_.isUndefined(refererRequestHeader)) {
info.requestHeaders.push({
name: 'Referer',
value: refererUrl
});
} else {
refererRequestHeader.value = refererUrl;
}
return { requestHeaders: info.requestHeaders };
}, {
// Match on my specific iframe or else else this logic can leak into outside webpages and corrupt other YouTube embeds.
urls: ['*://*.youtube.com/embed/?enablejsapi=1&origin=chrome-extension:\\\\jbnkffmindojffecdhbbmekbmkkfpmjd']
},
['blocking', 'requestHeaders']
);
This code works great 99% of the time. However, on some PCs, it fails. I am attempting to investigate why this is happening, but I don't have very many leads to go on.
My questions are:
Does this code look appropriate for what it is attempting to achieve? I attempt to find an existing Referer requestHeader. If found, I set the header's value to the given URL. If the header is not found, I push it.
I've done some reading on the "handlerBehaviorChanged" method exposed through chrome.webRequest.handlerBehaviorChanged, but I'm still unsure if this is something which could resolve my issue. I found this post: How to clean chrome in-memory cache? which hints at intermittent errors with chrome.webRequest... however, I didn't see anything conclusive. Would it be prudent to call handleBehaviorChanged after setting my listener?
What other options might I have for debugging this issue? Has anyone experienced intermittent failures in related scenarios?

The request is too large for IE to process properly

I am using Websync3, Javascript API, and subscribing to approximately 9 different channels on one page. Firefox and Chrome have no problems, but IE9 is throwing an alert error stating The request is too large for IE to process properly.
Unfortunately the internet has little to no information on this. So does anyone have any clues as to how to remedy this?
var client = fm.websync.client;
client.initialize({
key: '********-****-****-****-************'
});
client.connect({
autoDisconnect: true,
onStreamFailure: function(args){
alert("Stream failure");
},
stayConnected: true
});
client.subscribe({
channel: '/channel',
onSuccess: function(args) {
alert("Successfully connected to stream");
},
onFailure: function(args){
alert("Failed to connect to stream");
},
onSubscribersChange: function(args) {
var change = args.change;
for (var i = 0; i < change.clients.length; i++) {
var changeClient = change.clients[i];
// If someone subscribes to the channel
if(change.type == 'subscribe') {
// If something unsubscribes to the channel
}else{
}
}
},
onReceive: function(args){
text = args.data.text;
text = text.split("=");
text = text[1];
if(text != "status" && text != "dummytext"){
//receiveUpdates(id, serial_number, args.data.text);
var update = eval('(' + args.data.text + ')');
}
}
});

This error occurs when WebSync is using the JSON-P protocol for transfers. This is mostly just for IE, cross domain environments. Meaning websync is on a different domain than your webpage is being served from. So IE doesn't want do make regular XHR requests for security reasons.
JSON-P basically encodes the up-stream data (your 9 channel subscriptions) as a URL encoded string that is tacked onto a regular request to the server. The server is supposed to interpret that URL-encoded string and send back the response as a JavaScript block that gets executed by the page.
This works fine, except that IE also has a limit on the overall request URL for an HTTP request of roughly 2kb. So if you pack too much into a single request to WebSync you might exceed this 2kb upstream limit.
The easiest solution is to either split up your WebSync requests into small pieces (ie: subscribe to only a few channels at a time in JavaScript), or to subscribe to one "master channel" and then program a WebSync BeforeSubscribe event that watches for that channel and re-writes the subscription channel list.
I suspect because you have a key in you example source above, you are using WebSync On-Demand? If that's the case, the only way to make a BeforeSubscribe event handler is to create a WebSync proxy.

So for the moment, since everyone else is stumped by this question as well, I put a trap in my PHP to not even load this Javascript script if the browser is Internet Destroyer (uhh, I mean Internet Explorer). Maybe a solution will come in the future though.