Sentry is showing that certain Facebook users are receiving the error:
FBInstant is not defined
My HTML file includes scripts like so just after the opening <body> tag:
<script src="https://connect.facebook.net/en_US/fbinstant.6.2.js"></script>
<script src="js/jquery-3.3.1.min.js"></script>
<script src="js/app.js"></script>
In app.js, FBInstant.initializeAsync is only called after the entire page has loaded:
window.onload = function() {
FBInstant.initializeAsync().then(function() {
//Load stuff, etc.
});
}
Is fbinstant.6.2.js not being loaded for some reason? This is working for the vast majority of people. It seems to be mostly Chrome users, with a smaller portion of Firefox users as well.
You should always check if it exists before using it, i had the same problem with the JS SDK of Facebook and found out that those people just installed a browser plugin like Ghostery to disable third party plugins.
I'm trying to embed "Authentication via Google" to a simple web app I am working on. I used following code to do this.
<html>
<head>
<title> Home </title>
<script src = "https://apis.google.com/js/platform.js?onload=onLoadCallback" ></script>
<script>
function changePage() {
if (!gapi.auth2.getAuthInstance().isSignedIn.get()) {
window.location.href = "login.jsp";
}
}
</script>
<script>
gapi.load('auth2', function () {
gapi.auth2.init().then(changePage);
});
</script>
<script>
</script>
<script>
var user;
function signOut() {
var auth2 = gapi.auth2.getAuthInstance();
user = auth2.signOut().then(changePage);
}
;
</script>
<meta name="google-signin-client_id" content="xxxxxxxxxxxx">
</head>
<body style="background-color:azure;">
<div class="vertcal-center">
<div class="myclass">
<h1>Welcome to home page
</h1>
<button type="button" class="button" onclick="signOut()">Log Out</button>
</div>
</div>
</body>
</html>
However, when I ran ZAP analysis on my code, it gives me a Low Risk alert saying "The page includes one or more script files from a third-party domain" . It points to following line as the line with the issue.
<script src = "https://apis.google.com/js/platform.js?onload=onLoadCallback" ></script>
I refer OWASP tutorial which describes about this issue, and I understand that this can introduce the 3 risks they have mentioned which are
The loss of control over changes to the client application.
The execution of arbitrary code on client systems.
The disclosure or leakage of sensitive information to 3rd parties.
However, I also understand that if I am going to use Google authentication, I'll have to trust Google and assume that they won't do anything bad here.
Is there any better way to do this in my code so that ZAP will not warn me?
Is it okay to ignore this alert?
What ZAP looks at is the hostname of your web page and the hostname of the embedded javascripts.
Since your website hostname will not be google.com anyway, ZAP will always complain.
Only thing is we are trusting the external JS.
But you can download the external JS file and host it within your web app.
That way you are calling your own JS file and then ZAP will ignore it.
However, if google modifies the JS file after that, your local JS file won't get the new modifications. So my opinion is you can justify this and ignore the issue in ZAP report.
When you are using external javascripts, make sure to check if they have any reported known vulnerabilities. You can refer [1] to know more information for a similar topic.
[1] https://medium.com/#PrakhashS/using-retire-js-with-zap-to-identify-vulnerabilities-in-javascript-libraries-7baad56690aa#.cotei58mk
The way this rule works is described in the help that comes with ZAP, which is also available online: https://github.com/zaproxy/zap-core-help/wiki/HelpAddonsPscanrulesPscanrules#cross-domain-script-inclusion :
Cross Domain Script Inclusion
Validates whether or not scripts are included from domains other than the domain hosting the content. By looking at the "src" attributes of "script" tags in the response. Allowed Cross-Domain scripts:
Any script with a non-empty "integrity" attribute is ignored - the
integrity value is not checked as this will be checked by the browser
At MEDIUM and HIGH thresholds if a script URL falls within a context that also includes the URL of the base message no alerts will
be raised.
So you can either specify an 'integrity' attribute or create a context and include in it all of the domains you trust.
If i use the aframe js locally i am able to switch to stereoscopic mode directly on page load using :
if (scene.hasLoaded) {
scene.enterVR();
}
i have two js files on my website, aframe and bmfont:
<script src="https://aframe.io/releases/0.3.0/aframe.min.js"</script>
<script src="https://rawgit.com/bryik/aframe-bmfont-text-component/master/dist/aframe-bmfont-text-component.min.js"></script>
So if i reference the local file of aframejs, bmfont doesn't work.
And if i use the remote copy.. or the online version.. enterVR mode doesn't work.
https://github.com/smsejwan/aframe
enterVR() requires a user action because of browser security.
Maybe using it locally rather than on a webserver bypass that but then you encounter other problems (e.g. assets not loading).
There are ways to trick the browser (e.g. assign a shortcut then use a script like AHK to periodically call it) but it's not recommended.
I'm using phonegap to develop an application on android, when I test it on my phone I get this error Application Error Is a directory (file:///#android_asset/www/index.html)
I only get this error when I don't have internet connection on my phone.
any suggestions?
This means, in your index.html, you are using a resource that requires internet access. See your index.html and look for any CSS, javascript or Cordova file that is linked directly from the internet. If so, you must download the related file and make it local.
I had this same problem when I linked my Jquery mobile JS file directly like this:
<script type="CSS/javascript" src="http://code.jquery.com/mobile/1.3.0/jquery.mobile-1.3.0.js">
what I did was, downloaded the jquery.mobile-1.3.0.js file and had it placed locally inside my www folder. That fixed my problem.
I found the answer here:
http://dev.wavemaker.com/wiki/bin/wmdoc_6.5/PhoneGap?xpage=print#HTheconnectiontotheserverwasunsucessful28file3A2F2F2Fandroidasset2Fwww2Findexhtml29
6.1 The connection to the server was unsucessful (file:///android_asset/www/index.html)
WHERE: When launching the application on an Android device.
Anything you place within your index.html file that requests a remote
resource will cause the above error to be thrown for android devices,
and your application will then die. The Weinre debugger is a common
cause of this error.
Solution: Move the loading of remote resources out of index.html and
into your application where it will fail quietly.
you only have to rename your 'index.html' to 'main.html' for example, and create a new (dummy) 'index.html' that only have to redirect to the 'main.html'
Content of the new 'index.html':
<!doctype html>
<html>
<head>
<title>Title</title>
<script>
window.location='./main.html';
</script>
</head>
<body>
</body>
</html>
I found the answer.
Include the phonegap.js inside your <head> tag. It is required by phonegap during build time.
<head>
<script src="phonegap.js"></script>
</head>
You don't need to download the phonegap.js. All you just need is to include the code as shown. During build phonegap will look for it and include it automatically. If not, when you run your Native application, the application will be looking for phonegap.js on the phonegap server and this takes too long. Eventually your application load will time out with the error message you are seeing.
Wow! I can believe this. I ran into this problem and I got discouraged and almost gave up using phonegap. However, I read it in Phonegap's website about phonegap.js under the sub-heading below
https://build.phonegap.com/docs/app-overview
"Making Sure You can Still Access the PhoneGap API"
"Once you've deleted the phonegap.js you'll need to make sure that your application can still access the PhoneGap API.
To do so, simply ensure that the following reference is made in your index.html"
<script src="phonegap.js"></script>
This is like magic. It works.
Cheers everyone.
I follow the "quick started guie" and I have the same problem.
But I resolved it.
My problem was a discordance between the downloaded phonegap and the guie followed.
You must be sure this details:
- Into intex.html you link correct js script version (for example: cordova-2.7.0.js)
- It must matchs downloaded phonegab version.
phonegab version and js script linked must match.
I hope this help you.
A blank access tag allows access to all external resources.
<access origin="*" /> - a wildcard access tag allows access to all external resource.
Otherwise, you can specify specific domains:
-->
<access origin="127.0.0.1*"/> <!-- allow local pages -->
<!--
<access origin="http://phonegap.com" /> - allow any secure requests to http://honegap.com/
<access origin="http://phonegap.com" subdomains="true" /> - same as above, but including subdomains, such as http://build.phonegap.com/
<access origin="http://phonegap.com" browserOnly="true" /> - only allows http://phonegap.com to be opened by the child browser.
-->
Hope this helps.
Make sure you had included phonegap.js or cordova.js script in your page.
This will work only on your mobile device.
You should use:
file:///android_asset/www/index.html
as the URL
There are a few ways to include jQuery and jQuery UI and I'm wondering what people are using?
Google JSAPI
jQuery's site
your own site/server
another CDN
I have recently been using Google JSAPI, but have found that it takes a long time to setup an SSL connection or even only to resolve google.com. I have been using the following for Google:
<script src="https://www.google.com/jsapi"></script>
<script>
google.load('jquery', '1.3.1');
</script>
I like the idea of using Google so it's cached when visiting other sites and to save bandwidth from our server, but if it keeps being the slow portion of the site, I may change the include.
What do you use? Have you had any issues?
Edit: Just visited jQuery's site and they use the following method:
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.3/jquery.min.js"></script>
Edit2: Here's how I've been including jQuery without any problems for the last year:
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.4.3/jquery.min.js"></script>
The difference is the removal of http:. By removing this, you don't need to worry about switching between http and https.
Without a doubt I choose to have JQuery served by Google API servers. I didn't go with the jsapi method since I don't leverage any other Google API's, however if that ever changed then I would consider it...
First: The Google api servers are distributed across the world instead of my single server location: Closer servers usually means faster response times for the visitor.
Second: Many people choose to have JQuery hosted on Google, so when a visitor comes to my site they may already have the JQuery script in their local cache. Pre-cached content usually means faster load times for the visitor.
Third: My web hosting company charges me for the bandwidth used. No sense consuming 18k per user session if the visitor can get the same file elsewhere.
I understand that I place a portion of trust on Google to serve the correct script file, and to be online and available. Up to this point I haven't been disappointed with using Google and will continue this configuration until it makes sense not to.
One thing worth pointing out... If you have a mixture of secure and insecure pages on your site you might want to dynamically change the Google source to avoid the usual warning you see when loading insecure content in a secure page:
Here's what I came up with:
<script type="text/javascript">
document.write([
"\<script src='",
("https:" == document.location.protocol) ? "https://" : "http://",
"ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js' type='text/javascript'>\<\/script>"
].join(''));
</script>
UPDATE 9/8/2010 -
Some suggestions have been made to reduce the complexity of the code by removing the HTTP and HTTPS and simply use the following syntax:
<script type="text/javascript">
document.write("\<script src='//ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js' type='text/javascript'>\<\/script>");
</script>
In addition you could also change the url to reflect the jQuery major number if you wanted to make sure that the latest Major version of the jQuery libraries were loaded:
<script type="text/javascript">
document.write("\<script src='//ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js' type='text/javascript'>\<\/script>");
</script>
Finally, if you don't want to use Google and would prefer jQuery you could use the following source path (keep in mind that jQuery doesn't support SSL connections):
<script type="text/javascript">
document.write("\<script src='http://code.jquery.com/jquery-latest.min.js' type='text/javascript'>\<\/script>");
</script>
One reason you might want to host on an external server is to work around the browser limitations of concurent connections to particular server.
However, given that the jQuery file you are using will likely not change very often, the browser cache will kick in and make that point moot for the most part.
Second reason to host it on external server is to lower the traffic to your own server.
However, given the size of jQuery, chances are it will be a small part of your traffic. You should probably try to optimize your actual content.
jQuery 1.3.1 min is only 18k in size. I don't think that's too much of a hit to ask on the initial page load. It'll be cached after that. As a result, I host it myself.
If you want to use Google, the direct link may be more responsive. Each library has the path listed for the direct file. This is the jQuery path
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.1/jquery.min.js"></script>
Just reread your question, is there a reason your are using https? This is the script tag Google lists in their example
<script src="http://www.google.com/jsapi"></script>
I wouldn't want any public site that I developed to depend on any external site, and thus, I'd host jQuery myself.
Are you willing to have an outage on your site when the other (Google, jquery.com, etc.) goes down? Less dependencies is the key.
Pros: Host on Google has benefits
Probably faster (their servers are more optimised)
They handle the caching correctly - 1 year (we struggle to be allowed to make the changes to get the headers right on our servers)
Users who have already had a link to the Google-hosted version on another domain already have the file in their cache
Cons:
Some browsers may see it as XSS cross-domain and disallow the file.
Particularly users running the NoScript plugin for Firefox
I wonder if you can INCLUDE from Google, and then check the presence of some Global variable, or somesuch, and if absence load from your server?
There are a few issues here. Firstly, the async load method you specified:
<script type="text/javascript" src="https://www.google.com/jsapi"></script>
<script type="text/javascript">
google.load('jquery', '1.3.1');
google.setOnLoadCallback(function() {
// do stuff
});
</script>
has a couple of issues. Script tags pause the page load while they are retrieved (if necessary). Now if they're slow to load this is bad but jQuery is small. The real problem with the above method is that because the jquery.js load happens independently for many pages, they will finish loading and render before jquery has loaded so any jquery styling you do will be a visible change for the user.
The other way is:
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.1/jquery.min.js"></script>
Try some simple examples like, have a simple table and change the background of the cells to yellow with the setOnLoadCallback() method vs $(document).ready() with a static jquery.min.js load. The second method will have no noticeable flicker. The first will. Personally I think that's not a good user experience.
As an example run this:
<html>
<head>
<title>Layout</title>
<style type="text/css">
.odd { background-color: yellow; }
</style>
</head>
<body>
<table>
<tr><th>One</th><th>Two</th></tr>
<tr><td>Three</td><td>Four</td></tr>
<tr><td>Five</td><td>Six</td></tr>
<tr><td>Seven</td><td>Nine</td></tr>
<tr><td>Nine</td><td>Ten</td></tr>
</table>
<script src="http://www.google.com/jsapi"></script>
<script>
google.load("jquery", "1.3.1");
google.setOnLoadCallback(function() {
$(function() {
$("tr:odd").addClass("odd");
});
});
</script>
</body>
</html>
You (should) see the table appear and then the rows go yellow.
The second problem with the google.load() method is that it only hosts a limited range of files. This is a problem for jquery since it is extremely plug-in dependent. If you try and include a jquery plugin with a <script src="..."> tag and google.load() the plug-in will probably fail with messages of "jQuery is not defined" because it hasn't loaded yet. I don't really see a way around this.
The third problem (with either method) is that they are one external load. Assuming you have some plugins and your own Javascript code you're up to a minimum of two external requests to load your Javascript. You're probably better off getting jquery, all relevant plug-ins and your own code and putting it into one minified file.
From Should You Use Google's Ajax Libraries API for Hosting?:
As to load times, you're actually
loading two scripts - the jsapi script
and the mootools script (the
compressed version from above). So
that is two connections, rather than
one. In my experience, I found that
the load time was actually 2-3 times
slower than loading from my own
personal shared server, even though it
was coming from Google, and my version
of the compressed file was a couple of
K larger than Google's. This, even
after the file had loaded and
(presumably) cached. So for me, since
the bandwidth doesn't matter much,
isn't going to matter.
Lastly you have the potential problem of a paranoid browser flagging the request as some sort of XSS attempt. It's not typically a problem with default settings but on corporate networks where the user may not have control over which browser they use let alone the security settings you may have a problem.
So in the end I can't really see me using the Google AJAX API for jQuery at least (the more "complete" APIs are a different story in some ways) much except to post examples here.
In addition to people who advices to host it on own server, I'd proposed to keep it on separate domain (e.g. static.website.com) to allow browsers to load it into separate from other content thread. This tip also works for all static stuff, say images and css.
I have to vote -1 for the libraries hosted on Google. They are collecting data, google analytics style, with their wrappers around these libraries. At a minimum, I don't want a client browser doing more than I'm asking it to do, much less anything else on the page. At worse, this is Google's "new version" of not being evil -- using unobtrusive javascript to gather more usage data.
Note: if they've changed this practice, super. But the last time I considered using their hosted libraries, I monitored the outbound http traffic on my site, and the periodic calls out to google servers were not something I expected to see.
I might be old-school about this, but I still frown on hotlinking. Maybe Google is the exception, but in general, it's really just good manners to host the files on your own server.
I will add this as a reason to locally host these files.
Recently a node in Southern California on TWC has not been able to resolve the ajax.googleapis.com domain (for users with IPv4) only so we are not getting the external files. This has been intermittant up until yesterday (now it is persistant.) Because it was intermittant, I was having tons of problems troubleshooting SaaS user issues. Spent countless hours trying to track why some users were having no issues with the software, and others were tanking. In my usual debugging process I'm not in the habit of asking a user if they have IPv6 turned off.
I stumbled on the issue because I myself was using this particular "route" to the file and also am using only IPV4. I discovered the issue with developers tools telling me jquery wasn't loading, then started doing traceroutes etc... to find the real issue.
After this, I will most likely never go back to externally hosted files because: google doesn't have to go down for this to become a problem, and... any one of these nodes can be compromised with DNS hijacking and deliver malicious js instead of the actual file. Always thought I was safe in that a google domain would never go down, now I know any node in between a user and the host can be a fail point.
I just include the latest version from the jQuery site: http://code.jquery.com/jquery-latest.pack.js It suits my needs and I never have to worry about updating.
EDIT:For a major web app, certainly control it; download it and serve it yourself. But for my personal site, I could not care less. Things don't magically disappear, they are usually deprecated first. I keep up with it enough to know what to change for future releases.
Here some useful resource, hope can help you to chose your CDN.
MS has recently add a new domain for delivery Libraries trough their CDN.
Old Format: http://ajax.microsoft.com/ajax/jQuery/jquery-1.5.1.js
New Format: http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.5.1.js
This should not send all cookies for microsoft.com.
http://www.asp.net/ajaxlibrary/cdn.ashx#Using_jQuery_from_the_CDN_11
Here some statistics about most popular technology used on the web across all technology.
http://trends.builtwith.com/
Hope can help you to choose.
If I am responsible for the 'live' site I better be aware of everything that is going
on and into my site. For that reason I host the jquery-min version myself either on the same server or a static/external server but either way a location where only I (or my program/proxy) can update the library after having verified/tested every change
In head:
(function() {
var jsapi = document.createElement('script'); jsapi.type = 'text/javascript'; jsapi.async = true;
jsapi.src = ('https:' == document.location.protocol ? 'https://' : 'http://') + 'www.google.com/jsapi?key=YOUR KEY';
(document.getElementsByTagName('head')[0] || document.getElementsByTagName('head')[0]).appendChild(jsapi);
})();
End of Body:
<script type="text/javascript">
google.load("jquery", "version");
</script>
I host it with my other js files on my own server, and, that's that point, combine and minify them (with django-compresser, here, but that's not the point) to be served as just one js file, with everything the site needs put into it. You'll need to serve your own js files anyway, so I see no reason to not add the extra jquery bytes there too - some more kbs are much more cheaper to transfer, than more requests to be made. You are not dependent to anyone, and as soon as your minified js is cached, you're super fast as well.
On first load, a CDN based solution might win, because you must load the additional jquery kilobytes from your own server (but, without an additional request). I doubt the difference is noticable, though. And then, on a first load with cleared cache, your own hosted solution will probably always be much faster, because of more requests (and DNS lookups) needed, to fetch the CDN jquery.
I wonder how this point is almost never mentioned, and how CDNs seem to take over the world :)