Develop Reference

Chrome extension for blocking websites based on database blacklist

We have a database with millions of domain categorizations (storing it client side is not an option) and we want to make a chrome extension to blacklist sites based on how they are categorized in the Mysql database.
The server side stuff is easy, we post the domain, and return the category.
The tricky part is blocking requests based on the categorization. Here are a few potential implementations and why they won't (quite) work.
Idea 1:
Redirect all traffic using Chrome.webRequest to mysite.com/script.php?url=www.theoriginalurl
This script checks the database's category & either redirects them to the theoriginalurl.com or denies the request, redirecting them to www.youGotBlocked...
Have the chrome extension check the http referrer header to make sure that they came from mysite.com (unless the url is mysite.com, then do nothing).
Problems:
It doesn't seem like we can set the referrer header in PHP, so we have no way of knowing that they came from mysite.com. It seems like maybe we should be passing info via a cookie, but I haven't thought of an elegant solution involving cookies.
Idea 2:
Every time Chrome.webRequest fires make an AJAX POST request to mysite.com/categorizeURL.php with the URL to get the category. Block or allow based on the server's response.
Problems:
Either we make the request asynchronous and we can't get the response in time (their is no way that we have found to delay the callback until the server responds -- more on that here). Or we make the request synchronous, and IT WORKS!!! Except for the fact that if they can't reach our server, their entire browser locks up and they essentially need to refresh the extension to be able to access the internet again.
Other ideas?
Does anyone have other ideas for creating a blacklist via a Chrome extension? I simply refuse to believe that it is not possible.

Benefits / disadvantages to a cross origin domain proxy?

I'm struggling at the moment with the idea of creating a cross-origin request proxy or not.
I have a jQuery application that interacts with an API, making at least 4 requests to that server on the initial page load. Both servers are completely under my control, but they are on different subdomains. For that reason, I've been heading toward the approach of using JSONP to get around the cross-origin request policies.
However, I'm really missing out on one feature in particular: getting HTTP status codes for the requests. The way JSONP + jQuery work, the request works or it doesn't. If it doesn't, I specify a timeout for the request and if that timeout is reached I assume a failure (there's no way to know otherwise). I'd really like to be able to respond to a 404 vs a 500 error from the API server.
This led me to thinking a local proxy may work better - but it would then tie up server-side resources (server that holds the jQuery application + Sinatra application) instead of client resources (the browser). That can certainly add up when each page load is 4+ requests to the API server, even though it wouldn't block the application from loading.
I understand this is not a true "question" - so feel free to flag this / close it if inappropriate. However, I'd really like to get some opinions on the subject. I'm introducing some complexity by developing a local proxy in Ruby.

I'd stick to JSONP and the direct communication between the subdomains.
Also, you might want to check out (hacky) methods of using iframes for communication. Iframes are not subject to the inter-subdomain restriction. They can communicate as long as both subdomains belong to the same top domain.

JSONP has some limitations and is not your only option. Since you control both domains have you considered using CORS? If not, check it out: http://www.html5rocks.com/en/tutorials/cors/
You can read about JSON-P vs. CORS here: http://json-p.org/

How to access the data from different server through AJAX call without JSONP?

I'm working on the project where the client has the back-end code in ServerA, and my front-end code, which is supposed to talk to back-end via AJAX requests is on ServerB, and they are in different domains. Because of the same origin policy, I'm not able to make those requests successfully (neither POST nor GET). Is it possible to enable it somehow without changing the back-end code to handle the JSONP? eg., white list that particular domain, or something?
I tried to emulate this in my local network where the back-end code is running on 10.0.1.4 (different machine), and I'm accessing it from localhost (apache), but couldn't figure out anything that doesn't require using jsonp. When calls are made, I'm not even seeing anything in the logs in the back-end, but it works fine from the REST client and by just loading the URL for GET requests. How are public API requests implemented that are not using JSONP?
I need at least one method (POST or GET) to work. Thanks.

Is it possible to enable it somehow without changing the back-end code
to handle the JSONP? eg., white list that particular domain, or
something?
Yes, you could write a server side script on your domain that will serve as a bridge between your and the remote domain and then send an AJAX request to your script.
Don't expect miracles. If you don't have control over the remote domain you are busted. The same origin policy restriction that's built into browsers for security reasons busts you. Well, you could always write your own browser that doesn't implement this policy, but I think you get my point.
Common workarounds include JSONP and CORS but they involve control over the remote domain. If you don't have control then read the my previous sentence as well as my first sentence.
Here's a nice guide I invite you consulting that covers some common techniques allowing to achieve cross domain AJAX with jQuery. Then adapt the one that fits best your scenario. And there's always the heavy artillery solution that involves bridging the 2 domains with a server side script which works bullet-proof in 100% of the cases if none of the other workarounds help you.

Is it possible to enable it somehow without changing the back-end code to handle the JSONP? eg., white list that particular domain, or something?
Hmmm, mostly no. You must allow JSONP or "white list" things via CORS (which is very easy to do). Or you can use YQL as a cross-domain proxy.

Three solutions posted here:
http://devlog.info/2010/03/10/cross-domain-ajax/
I've tried the third option since it just worked for me.. and I didn't have to go through any extra stress as it just handled things just like a regular ajax call.
Updating answer as this was posted 2 years ago:
LINK ABOVE NO LONGER WORKS.
Server side proxy:
the old page also talks about using a server side proxy, which means your server makes a call to another server, grabs all the data and sends it off to a page resting on that server. There is no problem for one server to fetch data from another server. So then your page can make a regular ajax call to that server. I didn't go with this option as it required more manual labor. So I'd suggest going with the option detailed here:
JSONP with jQuery
Make sure the provider supports JSONP.
Set the dataType option to jsonp, and if the provider uses a different GET param other than 'callback', specify the jsonp option to that parameter name.
$.ajax({
// ... Use the AJAX utility as you normally would
dataType: 'jsonp',
// ...
});
jQuery will generate a unique callback name for this request (something like json1268267816). Thus, the reply from a web service would be something like:
json1268267816({'uid': 23, 'username': 'Chroder', 'name': 'Christopher Nadeau'});
But jQuery handles it all seamlessly, so you as the developer just handle it like a normal AJAX request using the same jQuery success/failure/complete callback hooks.
Drawbacks:
The first limitation to this method is that you have to rely on the provider to implement JSONP. The provider needs to actually support JSONP -- they need to wrap their JSON data with that callback function name.
Then the next limitation -- and this is a big one -- is that JSONP doesn't support POST requests. Since all data is passed in the query string as GET data, you are severely limited if your services require the passing of long data (for example, forum posts or comments or articles). But for the majority of consumer services that fetch more data than they push, this isn't such a big problem.
However,
Using a library like jQuery that supports JSONP, these details of inserting the special script tag and creating the special callback function are all taken care of automatically. Using a JS library, usually the only difference between JSONP and real AJAX is that you enable a 'jsonp' option.

Security Issues with JSONP in jQuery

I am writing an app right now that uses jQuery and JSONP to get JSON from 3rd party servers. The main idea behind my app is that it is a Front End with only GUI logic and 3rd party servers can be written by anyone to use the Front End.
I have no idea what security issues could arise from this but I definitely see it as a potential issue. What are some steps I can take to make sure that a 3rd party server doesn't completely crash my site that will be running the GUI?

JSONP means that you execute third-party javascript which should return a Javascript object. The script you load with JSONP can do anything a local script could, thus it is an XSS attack vector in two ways: either if the third party you request the JSONP data from is evil, or if the data is changed with a man-in-the-middle attack.
The second type of attack can be avoided by only doing JSONP over secure connections (or can be disregarded if your own page is sent over an insecure connection, in which case there are easier ways to do a man-in-the-middle attack); the first type is inherent to JSONP and cannot be avoided. You should only use JSONP when you trust the source. Otherwise, you can either set up an AJAX gateway on your own server and request JSON data through that (this will only work if the JSONP service does not require authentication), or use cross-domain AJAX requests (which do not work in older browsers, and require certain permissions from the JSONP server).

If the third-parties aren't trustworthy, you have a large problem here. Instead of sending JSONP code, they could send any JavaScript they want, potentially damaging your site or stealing users' information.
JSONP works by just including the remote data on your page with <script> tags. It is designed to avoid the browser's security restrictions, and so should only be used with trustworthy sources.
A client-side only solution to this problem does not exist.
EDIT: Oh, I misread your question. I thought the client was going to be receiving the JSON.
JSONP is just a JSON object wrapped in a javascript function call. Normally if you were operating from a server you would just request the unwrapped JSON object itself, but even with the JSONP object it's difficult to hurt yourself unless you are running eval() on it.
Are you using an existing JSON library? If so, you should be fine.
Are you parsing it yourself? If so, avoid eval and you should be fine.

Well, JSON describes an object, not an executable function. What JSONP is doing is rendering that result of a GET request as a function on your client and executing it. This would suggest that the biggest security concern you would consider is what your code is doing with the data.

Why are AJAX requests limited to same domain?

Something I find really confusing, is why are AJAX requests limited to the same domain? What is the reasoning behind this?
I don't see any problem with requesting files from external locations, also servers making XMLHTTP requests seem to get and post to external locations fine.

Picture this :
You come on my fabulous website www.halfnakedgirls.com. You have fun watching what looks like technical documentation on human physiology, but behind your back, some lines of JavaScript are executing some request to another domain, let's say www.yourpaypallike.com.
Requests like http://www.yourpaypallike.com/account/transfer?to=badguy#evilwebsite.com&amount=984654 or http://www.mymailprovider.com/mails/export?format=csv.
Do you now see why it is forbidden ? =)

Tom, it is not "Ajax request limited". AJAX is based on JavaScript. For security reason JavaScript is prohibited access on cross domains. If you really want to do cross domain Ajax, you can do a hack.
YourPage(Ajax) ----> YourServer ----> ExternalDomain
You can call a page in your server using Ajax, Your domain will call to external domain using server side , and get the result then return to you as Ajax response.
Of course the request done to the ExternalDomain server will be called WITHOUT sending cookies for ExternalDomain that reside in your browser's memory. That's because the request is done by your server and not your browser.

It's for security purposes - if a website could execute AJAX calls to any domain they wanted on the client side, it poses a serious risk.
There are ways around this though - you could have your AJAX call a PHP script on the same domain, which in turn can call a script from another domain and return it. This wouldn't be using the browser as the communication medium though, it'd be using your web server.

Here is some information to satisfy your question:
http://en.wikipedia.org/wiki/Same_origin_policy