in recaptcha document, it says that if a site key exceeds 1000 QPS, then some requests may not be processed, I am wondering how I can identify this error if this happens? I assume a http code of 429 is thrown by google server?
The reCAPTCHA-specific quota page links to a more general Google API quota page that says
If you exceeded a quota with an HTTP/REST request, Google Cloud returns an HTTP 429 TOO MANY REQUESTS status code.
If you exceed a quota with an API request, Google Cloud returns an HTTP 413 REQUEST ENTITY TOO LARGE status code.
If you exceeded a quota using gRPC, Google Cloud returns a ResourceExhausted error. How this error appears to you depends on the service.
If you exceeded a quota using a Google Cloud CLI command, the gcloud CLI outputs a quota-exceeded error message and returns with the exit code 1.
Since you mention HTTP, I imagine you're in one of the first two categories. If you're going through their REST interface, you'll get 429. If you're going through the API, you'll get 413.
Related
Our team is developing a simple Angular website that sends a form data to our backend via API. This website will be published under a public IP, so the interaction will be protected with Google reCAPTCHA v3.
Recently we decided to run some stress tests in a pre-productive environment in order to see if everything is stable and works correctly. So we set up a simple JMeter tests group with 100 users and 100 loops. This way we had 10000 requests in total to our API. So, having all that configured, we ran the frontend in order to generate a reCAPTCHA token, executed the action which sends the data to the API and copied the generated token into the JMeter configuration.
The API, before passing the form data to the backend, checks if the token is valid by making a request to “https://www.google.com/recaptcha/api/siteverify”, specifying this token and the secret key generated in the reCAPTCHA admin console.
After executing the JMeter tests, we saw that a certain amount of requests bypass the validation of the token and end up in the backend, while the token has already been used.
What we tried?
Stress test of our API with 10k requests in order to try the validation of an already used reCAPTCHA token.
What we expected to happen?
All the requests to return an error code of 401, beacause the reCAPTCHA token has already been used before and those tokens are single use only (the 401 code is returned by our API if the request to "/siteverify" returns a "success:false" in the response body or a status code other than 200).
What actually resulted?
5% of the requests bypassed the validation and ended up in the backend.
JMeter results
(The 400 bad request errors are returned by the backend, after the validation of the token has already been done, meaning that the token was assumingly valid)
We chequed the logs of our API and we've been able to verify that, in fact, the "/siteverify" requests return a status code of 200 and a response body of "success:true" in those 5% of the tests.
To me, it seems like some kind of balancing problem, maybe some node didn’t have enough time to replicate the status of that token? Or maybe the problem comes from our implementation… Hopefully someone could give us a hint!
I have a web api which is deployed on IIS.
Api's are going through load test using load runner and almost on all alternative api call, getting 403 error response code, struggling to identify the issue, call is not going to the API, its returned back from IIS
I am doing bearer token authorization, somehow token which were incoming with each request were not valid, that is why the issue was occurring, to overcome this we have increased the lifetime of token to 1 hour and request load test team to generate the token once and send that token only with each request so that we can now see the proper execution time for each end point.
403 error indicates that access to the requested URL by the client is Forbidden for some reason. you need to provide detailed error message snapshot and what is the sub status code. and check that you assign this permission to the site folder:1) IIS_IUSRS,2)NETWORK SERVICE,3)IUSR
Is there a way to configure rate limit rule on a specific API action on Azure API management. The desired solution is to return HTTP 429 (too many request) if the end user receives a certain response from the backend, after X attempts.
See increment-condition on rate-limit-by-key policy: https://learn.microsoft.com/en-us/azure/api-management/api-management-access-restriction-policies#LimitCallRateByKey
In Azure APIM, rate limiting can be done based on a key or subscription. So rate limit based on the back end response over a number of times is not possible.
It is also not a good practice to keep track of response status between the calls.
You can possibly make use of retry policy to verify the response from back end service. https://learn.microsoft.com/en-us/azure/api-management/api-management-advanced-policies#Retry. You can use the retry result to send back 429 response.
So my colleague ran into this error while attempting to add http referrers to our javascript maps api key. Our app needs to be able to hit the api from our client domains, and there are well over 1200 of them. Has anyone hit this limit, if so, how have you surpassed it?
I'm getting the following error intermittently when invoking the custom search api from a server side setup:
HttpError 403 when requesting https://www.googleapis.com/customsearch/v1?q=John+Doe+john%40simpler.com&alt=json&cx=&key= returned "There is a per-IP or per-Referer restriction configured on your API key and the request does not match these restrictions. Please use the Google Developers Console to update your API key configuration if request from this IP or referer should be allowed.
I'm using a server api key, and have confirmed that the configured server ip address is correct. And about 50% of the time my request come back fine, too. I'm issuing the request from the server like this:
service = build("customsearch", "v1",
developerKey=api_key)
custom_search_context = <my_context>
res = service.cse().list(
q=search_query_string,
cx=custom_search_context,
).execute()
My requests per sec are well with in the configured limit of 10/sec and daily purchased limit of 5000 requests.
One more thing I noticed is that Google counts a forbidden request towards the daily limit, too.
Any pointers on why I'm being presented with the error only intermittently would be very helpful
The error can be raised when you're exceeding a request/second limit. Can you confirm that your request rate is below your configured user rate limit? It might be worth noting that the limit is enforced even if you don't explicitly provide a user value in your requests.