I'm building JS-only plugin which will be implemented on multiple websites, each website having its own unique ID, which is passed to a Rails API along with some other data. My API will verify the hostname and ID provided by the JS plugin - but these things can of course be seen and used to fake impressions or events by anyone.
As far as I'm aware, there is no foolproof way of authenticating a website without an invisible, server-side key. That said, how does Google do it?
Analytics requires no server-side implementation, only an ID, which it of course checks against the hostname. Does this not mean that page views and events can be faked by a third party, and if so, why isn't it a prevalent issue?
Thanks in advance
Related
I'm going to make a project using the Google translate api and I'm thinking of uploading this project to a server and just sharing it with my friends. But unfortunately the Api Key that I will use in the project can be accessed clearly in the JavaScript file. This is a very bad situation. To prevent this, I have limited the Google Cloud Api and as far as I understand it is only allowed to be used on the links I allow. It cannot be used on other links. Now my main question is, is this method enough to protect Api from malicious people? Do I need to do anything else? Thank you in advance for your answers.
Best practice in these cases is to use .env files to keep data like API keys private.
You have to create a server for that which will perform OAuth and then send an API request to google.
You can get help about how to implement OAuth from this topic provided by google: https://developers.google.com/identity/protocols/oauth2/javascript-implicit-flow
If you send/attach your API key in frontend like javascript which is basically a frontend language then it can be used to:
Send fake requests which will use all of the bandwidth etc.
You should also consult the TOS.
On November 5th 2014 Google made some changes to the APIs terms of Service.
Like you I had an issue with the following line.
Asking developers to make reasonable efforts to keep their private
keys private and not embed them in open source projects.
That is however really only an issue if you are releasing the source code of your app as an Open source project for example.
If your just hosting this on a server then what you shoudl do is set up limitations for the api key adding_application_restrictions you can limit it so that the api key can only be used from your server and no where else.
Say I'm starting a site, refer.com, where I post items on an 'affiliation' basis. When users click on my links, they're directed to the site shop.com. If the user I redirect to shop.com makes a purchase, I need that conversion tracked.
I see two possibilities:
Creating a custom tracking library (probably JavaScript) where I
request URLs from refer.com to transfer information from shop.com. I guess PHP would work too, but reduces compatibility with clients.
I use Google Analytics cross-domain tracking to do this. I don't
want the refer.com GA account to interfere with the shop.com GA account, but as I understand it you can use several accounts on the
same page, giving them different identifiers.
I feel like I'm stuck with a narrow set of possibilities. Do I do both? Neither? I need it to be as easy to implement as possible for the client, while also providing relatively bullet proof tracking. What's the standard today? Affiliation services are everywhere, and this type of cross-domain tracking has to be a very used technique. Is there another preferred method of achieving this that I'm not aware of?
This question might seem highly theoretical. While that may be true, answers with code are highly appreciated too.
I have a way for this to work but it requires both your domains to have the Universal Analytics code installed. This will not work with the older GA code
https://support.google.com/analytics/answer/1032400?hl=en
You can install multiple instances of the Google Analytics tracking code on your web pages to send data to multiple properties in your account.
You can, for example, install multiple instances of the Universal Analytics tracking code (analytics.js) on your web pages but only one instance of the Classic Analytics code (ga.js).
So (provided they have your GA code installed) when you refer to shop.com what you should do is this
Parse your GA cookie. You can get to it by $_COOKIE['_ga']. The cookie holds a string that has four parts, broken up by periods. (i.e. GA1.3.367110421.1357220305). You want those last 2 numbers (in this example 367110421.1357220305)
Pass the parsed cookie data in your referral to shop.com
shop.com should store the parsed cookie in its session
Last but not least, when shop.com has your referral data it should load your GA code and set your sessions up like this
ga('create', 'UA-YOUR-GA-CODE', {'cookieDomain': 'shop.com', 'clientId': 'USERS-PARSED-SESSION'});
What this does is it passes your GA session to their domain. At this point, GA will keep their session going so you can track what happens on shop.com. Any conversion data they pass to their GA code should be passed to your GA as well.
Is it bulletproof? No. You have to trust shop.com to properly retain and show your referrred GA session ID. But I have to use this methodology to keep my sessions between my primary sites and the centralized checkout we use and it preserves my Adwords conversions, etc.
I feel like if you're looking for ease of use for the client, Google Analytics is a pretty solid option. It is a widely used tool, with lots of documentation and active forums for feedback. Also, from my research on the topicit seems that they've got this type of behaviour in mind already.
An alternate that comes to mind is that, when redirected from site A to site B, they should be forced to authenticate on site B. You could then setup an authentication form that is unique to this referral from site A, and will be filtered into your database separately from regular authentications on site B.
I want to collect statistic (views/clicks/browser info/etc.) for my javascript widget which installed on third party web-sites and after that provide analytics for each domain owner (such as: on my web site I will create interface in which domain's owner could login and see stats for his domain).
I assume that I need to integrate tracking pixel in my widget. And after that parse all request for that pixels.
I've got several question about architecture and implementation of stats/log collection:
When using tracking pixel do I need to add all stats as GET parameters? for example when browser loads my js-widgwt I could get all parameters in widget's javascript and after that make ajax request:
my-stats-domai.com/?widget_id=1&domain=example.com&browser=chrome&city=London&type=view....
or there is another way to get/send all parameters?
What is the easiest/fastest way to collect all users info (browser info, referer, url, get params, etc.)? Maybe there is common approach, logs format or specification for users/visitors log?
When tracking user clicks (or other actions) I assume that I need to use ajax request from onclick?
When using onclick do I need to append all browser info, refferer, etc. to url as GET parameters?
Is there any javascript/jquery plugin that could help me collect user stats on third-party sites? And maybe there is any open source php log-parser for my backend to send logs to datastore (mysql).
Maybe I should use piwik or other tracking systems, but I think that it will be kinda overhead. What is pros/cons of using piwik (or smth. else) for my task?
P.S. If there some useful reading about this theme please share a link.
try using microsoft clarity. They have small screen recordings of the widget and you can view errors, clicks, sites, backlinks and more
I have been working on a project that uses Backbone.js router and all data is loaded by javascript via restful requests. I know that there is no way to detect whether Javascript is enabled or not in server-side but here is the scenarios that I thought to make this website indexable:
I can append a query string for each link on sitemap.xml and I can put a <script> tag to detect whether Javascript is enabled or not. The server renders this page with indexable data and when a user visits this page I can manually initialize Backbone.js router. However the problem is I need to execute an sql query to render indexable data in server-side and it will cause an extra load if the visitor is not a bot. And when users share an url of the website somewhere, it won't be an indexable page and web crawlers may not identify the content of that url. And an extra string in web crawler's search page may be annoying for users.
I can detect popular web crawlers like Google, Yahoo, Bing, Facebook in server-side from their user-agents but I suspect that there will be some web crawlers that I missed.
Which way seems more convenient or do you have any idea & experience to make indexable this kind of websites?
As elias94xx suggested in his comment, one solid solution to this dilemma is to take advantage of Google's "AJAX crawling". In short Google told the web community "look we're not going to actually render your JS code for you, but if you want to render it server-side for us, we'll do our best to make it easy on you." They do that with two basic concepts: pretty URL => ugly URL translation and HTML snapshots.
1) Google implemented a syntax web developers could use to specify client-side URLs that could still be crawled. This syntax for these "pretty URLs", as Google calls them, is: www.example.com?myquery#!key1=value1&key2=value2.
When you use a URL with that with that format, Google won't try to crawl that exact URL. Instead, it will crawl the "ugly URL" equivalent: www.example.com?myquery&_escaped_fragment_=key1=value1%26key2=value2. Since that URL has a ? instead of a # this will of course result in a call to your server. Your server can then use the "HTML snapshot" technique.
2) The basics of that technique is that you have your web-server run a headless JS runner. When Google requests an "ugly URL" from your server, the server loads up your Backbone router code in the headless runner, and it generates (and then returns to Google) the same HTML that code would have generated had it been run client-side.
A full explanation of pretty=>ugly URLs can be found here:
https://developers.google.com/webmasters/ajax-crawling/docs/specification
A full explanation of HTML snapshots can be found here:
https://developers.google.com/webmasters/ajax-crawling/docs/html-snapshot
Oh, and while everything so far has been based on Google, Bing/Yahoo also adopted this syntax, as indicated by Squidoo here:
http://www.squidoo.com/ajax-crawling
I want to create a web widget that will display information from my site.
The widget will be included in the client's website HTML using JavaScript, and should only be usable for my clients -- web sites that were registered at my site.
The information in the widget should be specific to the user who is currently visiting the client's site.
So, I need to authenticate both the client (website owner) and the resource owner (website visitor). This seems to map nicely to OAuth 2.0, but I couldn't find a complete example or explanation for such an implementation.
Any resources or pointers to such information will be appreciated.
Update: I've stumbled upon this article, which provides an outline for an approach that uses OAuth. However, it is not detailed enough for me to really understand how to use this with OAuth 2.
There are many large organizations that have done this, and I'm sad to see no other answers for this question since it's such an important web pattern.
I'm going to presume that you are not rolling your own OAuth 2.0 provider from scratch, if you are - well done otherwise you should be using something kickass like Doorkeeper to do this for you.
Now, in OAuth 2.0 you have the following entities:
Users registered on your website
Applications registered on your website (who subscribe to your oauth2)
User Permissions which is a list of Applications that a user has 'allowed'
Developer (who is consuming your auth API / widgets and building an Application)
The first thing to note is you must have a domain name associated with each Application. So if a developer registers for a API token / secret on your website, the Application he creates is mapped to a unique domain.
Now, I presume that the flow for an application to authenticate users via your website is already clear. That being said, you don't need to do much for this to work.
When an Application sends the user to your website (in order to sign in) you place a session cookie on the user's computer. Lets call this "Cookie-X".
Now the user is authenticated by your website and goes back to the Application. There we want to show a custom widget with information pertaining to that user.
The developer will be need to copy paste some code into this app.
The flow is like this:
The code will contain a url to your website with his Application ID (not secret) which he got when registering his application on your website.
When that code runs, it will ping your website with his appId. You need to check that AppID with your database, and additionally check that the referrer url is from the same domain as that which is registered in your website for that AppID. Edit: Alternatively or additionally, the code can check for document.domain and include it in the ping to your website, allowing you to verify that the request has come from the domain that has registered with the given AppID.
If that is correct, you reply back with some JS code.
Your JS code looks for the session cookie your website had set when the user had signed in. If that cookie is found, it pings back to your website with the session and your website responds with the custom view content.
Edit: as rightfully mentioned in a comment, the cookie should be HttpOnly to safeguard against common XSS attacks.
Additional Notes
The reasons this is a secure approach:
The AppId and domain name are a good enough combination to verify that other people are not fetching this information. Even thou the appId is visible in the applications html source, the domain name would have to be spoofed by anyone attempting to use someone else's AppID.
Presuming someone takes an AppID which is not his, and writes code to spoof the domain name of the referrer when requesting for your widget, he still won't be able to see any information. Since you are showing user specific information, the widget will only render if your website can find the session cookie it placed on the users browser which can't really be spoofed. There are ways around like session-hijacking, etc. But I think that's beyond the scope of this question.
Other Methods
Just by looking at Facebook's Social Plugins, you can tell that there are other options.
For example, one might be to use an Iframe. If you ask the developer to add an Iframe to his application, you can even reduce a few of the steps mentioned above. But you will have to add JS along with it (outside the iframe) to grab the correct domain, etc. And ofcourse from an accessibility and interface standpoint I'm not very found of Iframes.