"Punish" with SpikeArrest?

guycrets
Participant IV

Hi Apigee users,

Get a question to throttle users extra who generate many bad requests, to "punish" them.

Is it possible to add extra SpikeArrest policy/call after having determined that call is a bad request?

Also in response flow?

Can't find much information about applying multiple SpikeArrest policies in single API proxy.

Many thanks, kind regards, Guy Crets

0 3 116
3 REPLIES 3

Trying to better understand what you're actually trying to do..

When you say throttle users/add extra spike arrest, do you mean you would like to use a more aggressive SpikeArrest for certain requests?

Is a bad requests determined only by your backend or are there other ways to determine this?

Is your API anonymous or are your consumers using some kind of apikey, or something else?

Is this trying to address general api abuse from random users or from particular consumers or some other use case?

Thanks for your interest. Below answers to your questions:

  • Yes, I would like to apply penalty for user if (s)he makes bad request.
  • Wat is bad: some errors like malformed JSON can be determined by Apigee. That would already be a good start. Even better if I could take certain back-end errors into account as well.
  • Users are (strongly) authenticated and I can derive client ID from their access token.

Is this a sensible idea overall to "give penalties" via SpikeArrest policies?

Maybe quota policy an option if I only call the quota policy in case of bad requests. And set upper limit on number of bad requests in an hour or so.

It's possible to enforce a quota with a just-in-time determined threshold.

You could have a flow sequence like this;

  • VerifyAccessToken
  • LookupClientScore - this is a JS or ServiceCallout that calls to an external service to determine the current score, and thus quota, for a particular client.
  • Quota - applying the result of the previous, or some default quota

Separately you would need to update the score on the client for significant events. For example, malformed JSON, or too many requests in a given period (quota violation attempt), or other. The external score service would need to track those significant events, and also perhaps apply an expiry on each event. The expiry might not necessarily delete event records, but instead would affect the score of the client. Maybe only events over the past 8 weeks would count for the score.

If the client behaves well then the score is high and the default quota gets enforced. If the client has a recent history of "poor behavior" then the "score" is low and a lower quota gets enforced.