#1 Edited by Jahed (2 posts) -

I realised the API key that's given is pretty lose, as in there's no authentication behind it (domain checks for example).

If say I use it in a web app to make AJAX requests, how would I prevent someone from grabbing the key from the script and (mis)using it themselves? Is there any consequences to my access to the API if such a thing happens?

Edit: Just to explain my current solution to this: I'm proxying requests through my server which adds the API key (and other common params) and does some basic referrer authentication.

#2 Posted by LordAndrew (14424 posts) -

Anything sent to the client can't be kept secret, period. Perform the API interaction from your server if you're concerned, and that seems to be what you're doing already.

#3 Posted by Jahed (2 posts) -

Right. I guess my real question was whether or not there's plans to do any authentication against the API keys. Like simply having a domain+secret combination on the server which is hashed and served as the API key so requests can be validated against the referrer.

I don't want to keep the API key a secret, but rather, restrict its use to a domain.

I was planning to make an open source web app which other people could use without having their own server. I wouldn't want their traffic to go through my server and I'd assume they wouldn't want to expose their API keys either.

But yeah, not a big deal for me. I realised I can also fix the lack of CORS headers using the server too so I don't have to rely on JSONP (which is convenient).

#4 Posted by LordAndrew (14424 posts) -

I'm not aware of any plans for that. The API's been around since I think 2008, and hasn't seen much change. It would be nice though.

#5 Edited by Laika (55 posts) -
@jahed said:

Right. I guess my real question was whether or not there's plans to do any authentication against the API keys. Like simply having a domain+secret combination on the server which is hashed and served as the API key so requests can be validated against the referrer.

That's not on the roadmap, to my knowledge. However, @jslack is putting some per-key and per-IP rate limiting in place to prevent API abuse, which probably makes the likelihood of an outright API key ban less likely.

#6 Posted by jSlack (98 posts) -

@jahed @lordandrew We put in an API limit per key. We are currently testing it (we use similar limits as Twitter/Facebook API), to see if it helps prevent abuse.

The API is getting a makeover, with V2. This will include new docs, and possibly some new features. More details coming soon. I've pasted over in CV about it, and I'll do the same here.

#7 Posted by TheFaxman (50 posts) -

@jslack: I think this is affecting my app's users - I've had multiple reports of failures due to rate limit errors. My app makes requests for about 5-6 resources at start up to populate its UI and it seems to hit the limit very frequently even though the usage patterns is not what I would call abusive (a dozen requests in the span of 10-15 seconds then nothing for a few minutes or longer). This can turn to 100s of requests per hour if people are really browsing around the app.

My app is a client application so there are potentially many hundreds of clients making requests at any given point in time. This seems to equate to the app being hit by rate limit failures most of the time and I'm not sure how to address it. Help is appreciated here - I have some upset users that need their Giant Bomb fix.

#8 Edited by ObjectiveCaio (22 posts) -

@jslack: @thefaxman: Same problem here. I've been getting many crash reports and user complaints due to the app reaching the rate limit. My app doesn't even rely on requests that much. During normal use, it only makes requests when searching and browsing games that haven't been opened, and once a day it refreshes the users' list of games (usually not too many), and that's when it hits the API a bit harder.

I've reduced API use for the next version as much as possible, adding some logic to searches and limiting users' ability to do manual list refreshes to one per day, but the app is just starting out, and as the userbase grows, I don't think this will make that much of a difference.

If we were able to see how hard we're hitting the API (with a dashboard on our GB profiles maybe), we'd be better equipped to find problems in our use of it.

#9 Posted by jSlack (98 posts) -

@thefaxman @objectivecaio I upped the limit yesterday (to double) while we test this.

I've been posting over in CV a bit but to recap; We're working on rolling out the new v2 API, in the mean time we added some basic API restrictions because we were getting slaughtered with some apps scraping us really hard. We are working on some new features, and de-coupling from the main site so the API requests don't affect site performance.

In the meantime we added per-key API limits (currently 400 requests every 15 minutes per API key), which I feel is quite generous. It's intended only to stop people who created apps with API keys hard coded, sometimes doing 5000 requests every 10 minutes.

#10 Edited by Chaser324 (6342 posts) -

From what I've seen, I think that probably applies to a huge portion of the apps that people have developed, and I've never read anything in the past advising developers to not hardcode API keys. Very few of them seem to be taking the route of going through http://www.giantbomb.com/boxee/ to get a user's individual key. Putting some sort of user authentication into the API itself (or at the very least making it more well known that the current process of obtaining a user's API key through the Boxee page exists) would probably deter developers from hardcoding API keys.

EDIT: Actually, does the Boxee process still work? Should devs direct users to directly retrieve and enter the API key? You should provide some guidance to devs on this subject.

EDIT 2: Also, didn't you have the data to know who would be affected by this? Why not give them some prior notice to allow them time to change their app? I'm not saying you had to directly e-mail them (although you do have their e-mail addresses), but a pinned post to the API developers page would have been nice.

#11 Posted by TheFaxman (50 posts) -

@jslack: The hard coded API key usage was the only guidance I've seen for client apps. I have no problems switching off of this but I'd like some guidance as to what I should be moving to? Should I ask for API keys from users directly? Use the /boxee/ code method? Something else?

I need to try to get a fix out as soon as possible since my users are blocked so I need to figure out a method fairly quickly.

#12 Posted by ObjectiveCaio (22 posts) -
#13 Posted by LordAndrew (14424 posts) -

I would be fine using users' API keys if there was a developer-friendly way of obtaining them. We have to ask the user for their login credentials, POST to the login form and hope that its fields don't change unexpectedly, scrape the link code from a web page and hope that its structure doesn't change unexpectedly, and then use that link code in a way that I've forgotten because it's not documented anywhere.I could skip several steps by insisting the user obtain and provide the link code themselves, but I still don't remember what to do with the link code once I have it.There is a lot of room for improvement here.

#14 Edited by Chaser324 (6342 posts) -

@lordandrew: Totally agree. If they want to stop allowing hardcoded keys, that's totally fine, but they need/needed to give devs a heads up and provide guidance on a recommended alternative. That Boxee authentication stuff isn't documented anywhere, scraping is a bad option, and asking a user to retrieve and enter their API key isn't a great option either.

#15 Posted by KamasamaK (2408 posts) -

@chaser324 said:

asking a user to retrieve and enter their API key isn't a great option either.

I don't think it's unreasonable. It is a one-time set-up step, and you can just give them the link and have them copy/paste the key. You may dissuade very lazy users, but it's their loss. Alternatively, giving their login credentials may also scare away people.