1

I have a controller that I'm using specifically for AJAX stuff, i.e. jquery makes a call to a particular URL and it passes back some json. However, some of the actions in this controller make use of services that we pay for and I don't want other people to be able to call these outside of my app.

I've seen this question which restricts access to a controller by IP which is all well and good, but since technically this will be called client-side I can't use this kind of restriction.

So how do I go about doing this? Or am I going about it the wrong way?

Edit: Would doing it as a POST rather than a GET be better?

Edit2: I think I need to explain more. The ajax call is to a URL in my web app. That controller is for an action which then (server-side) calls the web service from the lookup service.

Community
  • 1
  • 1
Piers Karsenbarg
  • 3,105
  • 5
  • 31
  • 67
  • it really makes no difference whether they use AJAX to call your action methods - it is still a client sitting behind an IP address. So fundamentally the link you posted should work, providing you know your client's IP. – Ben Foster Oct 27 '11 at 09:34
  • I presume you are using $_POST? right? or $_GET [in php] which is the post request. why not grab/filter the post first info you need, and unset/discard the rest of it. you can do the same on your URL... – Val Oct 27 '11 at 09:36
  • That's the thing, this is a public facing website, so I won't know the client's IP address. – Piers Karsenbarg Oct 27 '11 at 09:36
  • I didn't say you was, but you can find the equivalent of that to the language you are using. POST Requests aren't PHP orientated they are just inputs that a browser passes to the server. – Val Oct 27 '11 at 09:43

2 Answers2

1

First you need to recognize that there is literally no way to keep someone from attempting to call your web service. Even with an IP restriction it is still possible for someone to trigger the method by masquerading the IP address which someone might do if they just feel like messing with you.

At first, you might think this presents as deterrent for using an MVC approach for a web application but that really isn't the case. While it is certainly easier for someone to poach any web functionalities from an MVC web application since the method is capable of simply returning the data desired, there is nothing stopping someone from crawling through a rendered HTML response of a server side script either.

With that in mind there are a number of approaches you can use to limit access to this particular functionality but they are no different than any other web application MVC or not. However, which one you use depends entirely on the type of data being provided by this 3rd party service.

  1. If your website is strictly public, no usernames or passwords, one option would be for the web method to not always grab a "live value" of whatever data you happen to be polling from the 3rd party system. You could have the web method check when the last time the data was polled and if it's under some arbitrary limit set by you, simply return the cached value that you've saved on your server somewhere.
  2. If your site has a username and password mechanism in place, it is possible to limit the number of times per hour the service may be accessed by a particular user. Of course it is possible mechanisms could be devised to create multiple accounts automatically but a Captcha mechanism can assist you with this problem.
  3. Creating a Captcha mechanism for the service itself may be an option as well. While this won't help you with limiting the number of requests from a specific individual it will help ensure that a human must type in a response each time which would at least slow down the number of times the service is hit.

If you can give me a little more background on what it is that these services do I may be able to provide a more specific solution.

EDIT: Using POST or GET methods makes absolutely no difference in this situation.

Spencer Ruport
  • 34,865
  • 12
  • 85
  • 147
  • It's a post code finder and we get charged for each call we make, so I don't want anyone to go to /controller/action, POST their Post Code (excuse the pun) and get back the results. I don't want to post back the whole form when someone genuine uses it though. Admittedly, I can't see why someone would use this to get a list of post codes, but in case I'm asked if it's secure then I'm covering my back. – Piers Karsenbarg Oct 27 '11 at 09:54
  • As you so rightly pointed out, it's nigh on impossible to keep someone who REALLY wants to hack like this, I just wondered if it was. – Piers Karsenbarg Oct 27 '11 at 09:56
  • Hm. I've used services like this in the past and the ones I'm familiar with would provide entire postal code lists updated every month or so rather than charging per look up. Are you sure the service your company is using doesn't provide a similar option as well? – Spencer Ruport Oct 27 '11 at 10:00
1

So it sounds like you are using an external postcode lookup service (where I assume you pay-per-request) and you don't want someone else to make postcode lookup requests by piggy-backing on your service, where you will get charged?

The first thing you should do is check whether your service provider allows you to specify a whitelist of referrers. Since many of these apis mean your "api key" is in javascript somewhere, this is often used to only allow service requests (using your key) from a specific host or ip address.

With this done, you'll want to ensure that your post code lookup action is only called from pages within your site.

You can do this with some kind of anti forgery token on the client. Phil Haack posted recently about getting this to work with AJAX posts.

Ben Foster
  • 34,340
  • 40
  • 176
  • 285