4

I'm having this problem.

This IP has exceeded the request-per-day limit

I hardly believe that with StackPrinter, I'm depleting 10.000 requests per-day, per-site :).
Could you please verify?

EDIT:
it's started to work again

EDIT:
down again :(

Improve this question

1 Answer 1

Reset to default
2

There are a number of [app]s using Google App Engine, like StackPrinter.

Unfortunately, you're all using the same pool of IPs. Thus, you're all on the same quota.

If you can introduce a proxy or forwarder of some manner to your [app], you can solve this problem.

Improve this answer
10
  • @Kevin Uh..why the same quota since we have different keys?
    – systempuntoout
    Commented Oct 19, 2010 at 21:33
  • @systempuntoout - because you have the same IP. keys aren't meaningfully secret, so giving them different quotas would just be a way of eliminating quotas altogether.
    – Kevin Montrose
    Commented Oct 19, 2010 at 21:41
  • @Kevin Why would just be a way of eliminating quotas altogheter?
    – systempuntoout
    Commented Oct 19, 2010 at 21:51
  • 1
    @systempuntoout - because its trivial to harvest/generate keys. It would take no effort to use a few hundred keys for a single [app], thereby illicitly increasing your quota. This is why we throttle based on IP.
    – Kevin Montrose
    Commented Oct 19, 2010 at 22:01
  • @Kevin again I don't get it (00.10 a.m.). It could be trivial but that generated keys would be not registered. Don't you check if a key is registered on API calls?
    – systempuntoout
    Commented Oct 19, 2010 at 22:07
  • @systempuntoout - you generate a key by registering an [app]. How can we tell if a key is being used by a single [app] or a bunch of [app]s? Of course we check the validity of a key, but it doesn't really mean anything from a throttle perspective.
    – Kevin Montrose
    Commented Oct 19, 2010 at 22:09
  • 7
    @Kevin, probably you need to make some changes to how you identify clients for the API. As I know, App Engine provides clear way to distinguish the source of a request (by embedding the app ID in the referer header). You definitely should fix this issue with applications on App Engine. We've worked hard to build our apps that help grow the Stack Exchange and now we have to stop because you can't figure out how to identify App Engine apps
    – Vladyslav Tserman
    Commented Oct 19, 2010 at 23:28
  • @Vladislav - app IDs are trivial to forge, that's not a solution. The actual solution is to get on an unshared IP, at least for read-only access. Identity is a very difficult problem, that isn't really tractable with anonymous access (which is all API access, right now).
    – Kevin Montrose
    Commented Oct 19, 2010 at 23:32
  • @Vladislav I asked a proper question about this topic at stackapps.com/questions/1713
    – systempuntoout
    Commented Oct 20, 2010 at 8:46
  • Surely apps will only use multiple API keys if they use a lot of bandwidth, so you'd only have to keep track of apps-that-use-a-lot-of-bandwidth's keys? If a user has 2 keys and both are use a lot of bandwidth then, unless they very obviously have 2 known highly used apps, it's likely they are using multiple keys for one app. And if a user who has not been active in sum/low rep has a high usuage API key then it can be assumed the account is a clone to get another API key. I'm sure that other websites have similar situations and have a solution for this. I've never heard of this before.
    – Jonathan.
    Commented Oct 20, 2010 at 15:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .