Heroku Node.js sample facebook app does not work in Google Chrome - node.js

The Heroku app i'm trying to get to work (code here):
https://github.com/heroku/facebook-template-nodejs
"Unsafe Javascript attempt to access frame with URL" errors occur when the page is loaded in chrome.
The login button takes you to facebook but does not actually log you into the app and gives the same errors.
Has anyone got this app to work on Chrome or can anyone advise as to how to patch it up?
P.S. it seems to work fine on Mozilla.

Almost certain this is a cross domain policy issue, as stated above. Generally speaking, you just need to add the correct header info to the response.
Access-Control-Allow-Origin: *
In Node, I think it is just a matter of adding it as another header in the response, using
response.writeHead
See http://nodejs.org/api/http.html#http_response_writehead_statuscode_reasonphrase_headers
Oh, and there's explicit instructions on how to do it if you're using Express. I see no reason why it can't work using plain old node then.
http://enable-cors.org/server_expressjs.html
So I looked at your link, in your case I think you just have to enter the header info prior to using any other express app methods.
As to why it works in Firefox and not Chrome, not sure. Both support CORS many versions back. Maybe you have some Chrome extension that's interfering.

Related

Cypress issue with connection to the site is not secure?

I'm testing the website which have request to optimizely api to do some checking.
It request to url like https://cdn.optimizely.com/datafiles/XXX.json I suppose that this site required secure network.
I tried to open the url in cypress chrome and I get this error
This page isn’t workingcdn.optimizely.com didn’t send any data.
ERR_EMPTY_RESPONSE
But when I tried with the same network in chrome, I get fine response.
I need to be able to load the url to test my site.
Is there any solution to this matter. Please advice.
The resource returns 403 status code, that most likely indicates you don't have sufficient rights to see it:
Your Chrome outside Cypress runs might be set up differently, might already have session cookies.
You most likely need to figure out how to log into some account on the site throught Cypress.
Since cypress will not load optimizely neither nor google-analytics or any . My work around solution is by using cy.intercept() function in before/beforeEach
The code looks something like
cy.intercept('https://cdn.optimizely.com/datafiles/XXX8.json', {
"version": "4"
}
Reference: cypress-example-recipes

source URI is not allowed in this document

I am working on a website on my localhost and suddenly I'm now getting this errors.
I get this error on Firefox
<script> source URI is not allowed in this document
And nothing on chrome,` but if I try using the files code, I get:
Application Error: There was a problem getting data for the application you requested. The application may not be valid, or there may be a temporary glitch. Please try again later.
It is basically for: https://connect.facebook.net/en_US/sdk.js.
The browser doesn't even send a GET request for the file.
Everything used to work perfect before. Not sure why I'm getting this.
I had an extension installed on both of my browsers. It was preventing it from loading.
If you have any VPNs, hide-tracking extensions, then it needs to be disabled.
In my case it was Disconnect firefox/chrome extension.

How do I properly set link prefetch headers in Express 4?

According to MDN the correct approach is to send the header:
Link: </images/big.jpeg>; rel=prefetch
So my express syntax is:
res.header('Link', '</images/big.jpeg>; rel=prefetch');
and I see it land in my browser as:
Link:</images/big.jpeg>; rel=prefetch
But chrome never attempts to download the image.. The meta and link approaches work fine..
Am I setting the header wrong or is the browser failing to process the header value?
UDPATE: Okay so it looks like I'm doing things right but Chrome 43 & Chromium 43 on Linux/Ubuntu doesn't have support for this yet. This is working fine in Firefox 38..
Could it be that Chromium is just not showing the prefetching in the Network tab?
UPDATE 2: So it does look like Chrome/Chromium is hiding the file transfers from the Network tab. If someone can confirm this I'd appreciate it..
To set prefetch for one file in Express 4+..
res.set('Link', '<static/js/file1.js>; rel=prefetch');
For multiple files.
res.set('Link', '<static/js/file1.js>; rel=prefetch, <static/js/file2.js>; rel=prefetch');
Do NOT attempt to test this in Chrome, Chrome will lie to you and show it as not working if you investigate under Network tab. Always test with Firefox.
You can see me implementing this in a larger project in context here.

Why does the Foursquare API JS not work with HTTPS?

In a system I have to maintain (didn't build it, just inherited it) we have a Foursquare implementation that hasn't been used in quite a while. Trying to revive it failed, because our page is now loaded via HTTPS, which it didn't used to be.
We are using the "Save to Foursquare" button as well as the API request to retrieve the number of Check-ins. I already switched all the JS includes and intent links from http to https and at least now it shows the number and the button correctly.
However, I can't click the button and checking the browser's console I found that it added a script tag to the head of this page which tries to access http://platform.foursquare.com/js/modules/widgets.asyncbundle.js. The browser obviously blocks this, because it's not using HTTPS.
The file we are explicitly loading is https://platform.foursquare.com/js/widgets.js. It seems to me like this script is not reacting correctly to HTTP vs. HTTPS. There is probably a very simple solution to this, so what am I missing?
I don't know if you've tried it yet but the foursquare website says this on the matter:
Change the source of the JavaScript file to https://platform-s.foursquare.com/js/widgets.js
Add {"secure":true} to the global configuration block (window.___fourSq)`
The same link (see below) has all the different ways to call the Save To Foursquare function using its .saveTo() function.
https://developer.foursquare.com/overview/widgets
I hope this information and links helps! Cheers.

QUnit and PhantomJS testing of AJAX requests only works through proxy

I'm attempting to use grunt-contrib-qunit to run a pre-existing suite of qunit tests (testing parsing of ajax request results) in headless mode with Phantom on Windows 8.
The tests complete fine in these scenarios:
When the remote page is accessed directly from any browser without Fiddler or another proxy running
When Phantom runs the tests from a command prompt with Fiddler open and running
Oddly if I don't have fiddler open monitoring the requests, the AJAX requests I'm testing never seem to initialize. I've checked my default IE LAN Settings and there is no proxy enabled, I've also tried flipping the Auto Detect Settings checkbox there and no change.
Any thoughts??
Details on my setup:
Node v0.10.4
Latest grunt-contrib-qunit
Windows 8
QUnit is divided into 4 or 5 modules with setup and teardown tasks in some modules, asynchronous and synchronous tests, and autorun is set to false.
Update:
If I turn off the options in Fiddler for "Reuse client connections" and "Reuse connections to servers" I seem to get the same failure behavior as when Fiddler is off. This led me to believe its a problem with connections being closed prematurely, so I tried setting a custom keep-alive header -- but it still errors out.
Update 2:
I still question this because the page itself loads fine, but the requests fail, but it looks like this could possibly be related to NTLM authentication. Fiddler might somehow facilitating the handshake. There is an open issue for NTLM on the Phantom github page.
Update 3:
After continued troubleshooting this evening it looks like the issue is only with authentication on POST requests. GET requests seem to work fine. I'm working around this for now by routing all requests through an ASHX handler and thus dropping the auth component. Only thing I had to change was to disable web security on phantom to allow the cross-domain requests through.
I was going to say you need to turn off security, which is done by passing --web-security=no to phantomjs. This will sort out the CORS issues. However I see in your Update#2 that you've already discovered this.
For the POST authentication problem, I blogged about the workaround here:
http://darrendev.blogspot.jp/2013/04/phantomjs-post-auth-and-timeouts.html
I've heard the most recent version has fixed this, so upgrading might be the actual answer?
BTW, be careful with auth in PhantomJS, as the auth details are sent on all requests. E.g. if your test page fetches JQuery from a CDN, the CDN will be sent your authentication headers. (SlimerJS has some new features in place for getting around this; AFAIK PhantomJS does not yet.)

Resources