Why does Google Analytics use a one-pixel picture to transfer data? - javascript

Google Analytics embeds a one pixel GIF with a URL like this:
http://www.google-analytics.com/__utm.gif?utmwv=5.1.5&utms=5&utmn=1532897343&utmhn=www.douban.com&utmcs=UTF-8&utmsr=1440x900&utmsc=24-bit&utmul=en-us&utmje=1&utmfl=10.3%20r181&utmdt=%E8%B1%86%E7%93%A3&utmhid=571356425&utmr=-&utmp=%2F&utmac=UA-7019765-1&utmcc=__utma%3D30149280.1785629903.1314674330.1315290610.1315452707.10%3B%2B__utmz%3D30149280.1315452707.10.7.utmcsr%3Dbiaodianfu.com%7Cutmccn%3D(referral)%7Cutmcmd%3Dreferral%7Cutmcct%3D%2Fgoogle-analytics-architecture.html%3B%2B__utmv%3D30149280.162%3B&utmu=qBM~
Why not use an AJAX call? What's the benefit of using a one-pixel GIF?

Because you can't really do cross domain AJAX (with the exception of CORS, but that's a different story, and a recent phenomenon with less than universal support.) AJAX is for same origin requests. Also, Google Analytics forks from Urchin, which actually predates AJAX technology's adoption.
Requesting an image is pretty standard practice for analytics services "requesting" something as a means of sending something to a third party server. The reason AJAX/CORS doesn't really make sense is that you're not actually requesting an important resource for use on the page, so you want the request itself to be as quick and overhead-less as possible.
The other two ways analytics services occasionally handle sending data from the client is:
Including an invisible iframe, with the query string on the iframe src passing the analytics data
Requesting an image, and instead of returning an image, returning an empty response with a HTTP 204 header.

To maximize compatability. A cell phone browser may not support AJAX, for example, and thus may provide inadequate results. But hey, Google does a lot of funky stuff that nobody can explain.

Related

How to prevent a DDoS on AJAX endpoints?

I try to wrap my head around how to really secure ajax calls of any kind that are publicly available.
Let’s say the JavaScript on a public page (so no user authentication of any kind) contains an AJAX call to a PHP script (REST API or just a script, it doesn’t matter) that does a lot of heavy lifting. So any user can just look into the source code, find the AJAX call, rebuild and execute it, and execute it again a million times in a second and DDoS your site that way - not so great. At first I thought a HTTP_REFERER check could be helpful, but as any header field, also this is manipulable (just use a curl request) so the gain of security wouldn’t be too high.
The next approach was about a combination of using session ids, cookies, etc. to build some kind of access key for every page viewer and when someone exceeds the limit the AJAX call would run into an error. Sounds great so far, but just by cleaning the cookies, etc. everything will be reseted. So also no real solution. But, of course! Use the IP! Great idea! Users in public networks, that use only one IP for internet access will be totally happy, if one miscreant will block the service for all of them by abusing the call... not. So, also no great solution.
So, I’m really stuck here and can’t think of any great answer for my problem.
I also thought about API keys, or something alike. But that is an information that is also extractable from the JavaScript source. So how to prevent other servers using your service in a proxy kind of manner serving your data to their users? (e.g. you implemented the GMaps API in your website (or any other API) and someone uses your script accessing the API with your key)
tl;dr
Is there any good way to really secure your publicly viewable AJAX calls from abusing them for DDoSing your site, presenting your data on other sites, etc.
I think you're overthinking what AJAX is. When your site makes an ajax request, server side, it's the same as any other page request (even if some scripts are more process intensive). You need to protect your entire site, and not just specific scripts. If your server does not have any DDoS protection, it can be attacked through any page. Look into services like CloudFare
As #Sage Mentioned it is similar to normal http request. You can use normal authentication as the http headers/cookie information will be passed on to the server every time you make ajax call. For clear view you can look into developer console on browser. Its the same as exposing you website root url. Just make sure you have authentications checks for ajax calls too.

Why doesn't google analytics code use AJAX

I was wondering how ga collected data and send it to their servers, then I found this answer on SO. Now I'm wondering why does GA uses this method rather than doing an AJAX request, is it cheaper?
It's not cheaper, per se, it is reliable. Unlike AJAX, you can include an image from any domain without running into cross-domain browser restrictions, this is why tracking pixels are used instead of ajax requests.
As Rob said, it's primarily to get around cross-domain issues not supported in older browsers. However, as of recently GA has added support for the navigator.sendBeacon() method, which actually is cheaper, allows for retries on error, and doesn't have the problem of failing when the page is being unloaded (like when trying to send an event when a user clicks on an outbound link). As browser support increases, this will likely become the default method for sending hits to GA.
Here's the documentation on how to use sendBeacon with analytics.js:
https://developers.google.com/analytics/devguides/collection/analyticsjs/field-reference#useBeacon

Javascript API hindered by Cross Domain API calls

I need to provide a functionality similar to "Share with Facebook" for my social networking site. Facebook uses nested iframes and also xd_receiver concepts. I want to write a JavaScript API(JS file hosted on my domain), which can be used by different sites to call my web server APIs in order to share, post or recommend on my social networking site. I have a few questions -
Even though I provide the JS API, and diff sites load the JS file using the source, if any API call is made, it will again be a cross domain call(If I am comprehending correctly) and will be rejected on the server?
How to overcome such situation?
Is there any other better mechanism to implement this functionality?
Please suggest so that I can proceed with the implementation.
I think the default way is to use jsonp to get around cross domain limitation. http://en.wikipedia.org/wiki/JSONP. It might require a change in your api though. A user requests your api through the src of a script tag passing in a function callback. Your api would return pass your json response to the function specified.
Do you know why they use iframes and not simple get requests with JSONP/Images/scripts?
The answer is security. I cannot write a script that clicks their button which will automatically "like" the page.
Using plain old JavaScript with a JSONP will allow the developer to automatically click the button. Do you want that to happen?
The requests are made by the browser and not from the JS file, so, your requests will be cross-domain every time they did from another domain site.
Your server will only reject cross-domain requests if you implement a referrer validation.
And you can use JSONP if your API needs custom contents from your site...
To allow cross domain requests, you need to set the following Header in your HTTP Response:
Access-Control-Allow-Origin: *
The implementation will vary depending on the back-end you are using.
If the host in the Origin header of the request is anything but the host of the request, the response must include the listed Origin in the Access-Control-Allow-Origin header. Setting this header to * will allow all origins.
For very specific information on cross origin resource sharing see http://www.w3.org/TR/cors/. If you're not big on reading w3c documents, check out MDN's primer.
Note: Internet Explorer does its own thing with regards to cross domain requests. This answer is a good start if you have issues with IE.

Cross-domain AJAX

For what I understand cross-domain AJAX calls are not possible for security reasons.
I've understood that's it's possible to do it by using JSON-P though.
My question: why are cross-domain AJAX calls forbidden, but actually possible in a less practical way? It would be simpler to just authorize it.
How are you supposed to do for those kind of simple scenarios:
geocoding a location by calling Google Maps webservice
fetching Flickr images through its webservice
ajax to a different domain but it's the same application (server farms for example?)
... (those are just examples)
If I have to wrap/proxy these calls with a server-side script, that's just boring and time lost... You can't make a full Javascript application in the end? (if you want to use external webservices I mean)
why are cross-domain AJAX calls forbidden
You are logged on to your bank, right? OK, I'll just make a Ajax request to your bank and read your account number, sort code, and so on.
How are you supposed to do for those kind of simple scenarios
Server side proxy
JSON-P
CORS
If I have to wrap/proxy these calls with a server-side script, that's just boring and time lost
Many things would be easier if we didn't have to worry about security. We wouldn't need locks on doors, passwords on accounts, etc, etc.

javascript which makes cross domain GET requests and assigns it to a variable

for quite a long time i am looking for a javascript code which can make cross domain GET requests..
i want to make a javascript which makes a GET request to google and fetches the page source and assigns it to a variable..
note:the get requests must be generated from the clients computer and to a different server(eg:google)
Not possible due to the same origin policy which restricts AJAX and iFrames.
However, afaik Google offers a very own AJAX API to fetch search results, thats maybe enough for your needs.
But unless the Google servers don't allow for cross-domain calls (which I don't believe) there is no way in fetching data via a pure client-side AJAX connection.
Disclaimer: it might be possible in some browsers by changing some core settings

Categories