Search API Not Secure For Premium Blocking?

For my application, I'm going to bundle it with a newly-created basic account's API key and then offer users authentication to then retrieve their premium key which should allow the API calls to include premium videos etc.

However, I've noticed that the search API actually returns results for premium videos. For example: http://www.giantbomb.com/api/search/?api_key=[freeaccountapikey]&format=json&resources=video&query=scanlon

This is returning Metal Gear Scanlon results which are correctly not viewable on the website when logged-in with a non-premium account. On the other hand, the /videos feed does seem to honour the fact that a basic account key is being used though and doesn't return premium videos.

What is the workaround for this? Am I using the API incorrectly somehow? This does seem to be a big issue. Non-premium members could just register for a free account and grab the URLs for premium videos via the API...

@davidfox1983: Hey there,

So yes, we do return the video results in that feed, since we have no reason to protect that data, the stream itself is the only thing worth protecting.

As far as building in an API key into your app: no go. First, that's against the terms of the API. API keys are to be generated, and used on a per user basis. You will have to allow your app to take the user's API key. Second, the rate limiting will prevent that idea from working, as you will be limited to a certain amount of requests per hour, also number of IPs per API key. We actively monitor abuses, as we have a very generous API, and also very generous API limits for all of our users - as we do not currently offered a tiered usage system. In order to continue offering this generous API we have to make sure it doesn't get abused.

As far as returning results, we return "video_type" in that json feed you entered. You can use that to filter whether or not it's a premium video. You'll want to ingest our feed, do you own parsing, then storing the results in a local storage (if iOS use Core Data, SQLite or PLists).

If you'd like to talk more about application design/strategy, I'd be more than happy, as an app developer.

Thanks so much for the reply @jslack. So this makes more sense now. Although I think your data is still at risk as although the pages will still require auth, the user can just copy/paste the mp4 URLs into a browser to view premium stuff...

In your case that an app must require an API on a per-user basis, how are currently existing apps like "Giant Bomb Video Buddy" etc working? You are able to download that app, view videos etc without having logged-in or anything and then, optionally, generate an API via auth to view premium content. This is the kind of functionality I'm after.

To not have this is kind of a deal-breaker as far as an app goes as. With the approach you mentioned, surely it's impossible to create any kind of app without auth as all calls require a key to be sent as a parameter... It would make for a poor user experience to automatically tell the user to go to www.giantbomb.com/boxee on startup, grab the code and enter it and then send it to https://www.giantbomb.com/api/validate?link_code=xxx, using the result in further calls.

It's a real issue as I'm almost finished developing this app and, although I got in contact with edgework a while ago with some questions like this, I haven't heard back from him in a while and I don't feel like I could release an app with the above UX flow so all this work seems like it will have been wasted. If there's some other approach, I'd love to hear it.

Thanks again,
Dave

@davidfox1983: Yes, we are doing many things from the security front, and more is coming on that.

Just like GiantBomb video buddy works, you can allow the user to input his own existing API KEY into the settings page of your app (then of course you store it permanently in your local device storage), or you can do a request to the generation page, and just generate, and grab the token after the user auths, and then you'll be able to take that key and use it.

Otherwise, Video Buddy uses it's own cache for results, so it's not having to do unique hits on every request. You can cache responses if you wish (as long as it's non premium), which will allow for extremely fast searches that don't have to hit our API. You can pre-populate this cache by using your own user account API if you'd like. For example, take the first 10 pages of video results, and build a cache DB. That's 1000 videos - cool!

Additionally, we are working on coming up with new solutions for our API users, involving oath tools and solutions to make API interactive easier. First priority is us fixing some current performance issues and fixing API abuses, so we can make sure to scale.

@jslack: Thanks man. I'm not sure this answers how Video Buddy is getting results *before* the user enters their auth code. Even with some cache, it's bound to be hitting your API during search or looking at recent videos. What API key is it using for that? Have you given a special key to them for initial fetches before the user enters their personal key? I think you're saying that they proxy requests through their own server and cache global searches which allows them to just return those results if they're not stale before deciding to query the GB API but that still doesn't explain what auth key they're using. Surely the traffic would still be high enough to hit your rate limit? No?

Thanks for your time,
Dave

@davidfox1983: Yes, more or less. We do not have special access API keys yet, so everyone is on an even playing field - except they started using the API before we started adding some of the limits, so they were able to get around some of the restrictions initially - not a great answer for you, but it's the truth. To my knowledge, they did the population from their own cron servers, instead of doing on every client request, sharing an API key.

As long as you stay within reasonable usage limits with the API key, you will be ok, just rather you don't hardcode it into your distributed app, as you can understand, we can detect how many IPs are being used per API key, and those get marked for abuse. I'd rather you set up some kind of worker box with your own api key, and fill up your data cache that way. That way, you only have 1 IP per API key, and its much more reasonable for us, from a denial of service and security perspective. We officially support 200 requests per 15 minutes, and unofficially support up to 400 requests per 15 mins - which is a hell of a limit, if you rate limit your requests it will not take long for you to fill up the cache. Run it over a period of 48 hours, and it should be totally fine.