Hi I got this error in one of my ETE tests which exercises login functionality and start up behavior for my angular app.
The appears to be triggered by logging in using
await this.angularFireAuth.auth.signInWithEmailAndPassword(uname, pw);
where angularFireAuth is an injected instance of AngularFireAuthfrom '#angular/fire/auth';
I checked the Firestore quotas here but I can't find a reference to a quota for verifying passwords. Can anybody point me to what the quota is?
The console error reported looks like this:
zone-evergreen.js:659 Unhandled Promise rejection: Exceeded quota for verifying passwords. ; Zone: ProxyZone ; Task: Promise.then ; Value: u
The problem resolves after a few minutes and then test runs as expected.
I have found the message you are receiving being handled in this github thread.
Here are some of the important comments from the thread:
For the error you are facing "Exceeded quota for verifying passwords", this usually happens when one sends requests for verifying passwords or password login requests too many times at once (more than 20 requests per second per IP address or 25 requests per 10 min per account). When we get a huge amount of requests in a short period of time, the limit is applied automatically to protect our servers.
This is an internal quota (regardless of pricing plans) enforced by Firebase Authentication to prevent abuse when making authentication requests, for this reason the quota can change without notice.
In order to avoid triggering this alert, you can use a different IP address or
back off the number of requests per minute to something like 10-20, to avoid triggering the automated abuse detection.
If you are sending too many requests in a short period of time from the same IP address, then there is an expectation that you will get throttled at some point. This may prevent you from getting successful integration tests but there is a security benefit that comes with that. The easier it is for you to test, the easier it is for malicious scripts to be written too against your project. We have similar integration tests in other firebase auth libraries (client and admin) and we try to work with the limit.
If you have a legitimate need to increase the limit, then you can file a bug with support and make a case for that. You could even file for a feature request to whitelist calls from certain IP addresses.
Related
In testing code that uses the SendGrid Email Activity API, I have received "too many messages" errors. I have examined the "rate limit" response headers and it appears that I am being limited to 10 requests per 5 minute block in the day. That is, the first 5 minutes of every hour can have 10 requests, the next 5 minutes can have 10 requests, etc.
I asked SendGrid support about this. The first response was pretty generic, but seems to indicate that the threshold is correct and says I really should be using webhooks to get the status. I haven't found anything in the documentation saying this and I haven't seen anything the specifies what the rate limits are.
For those of you using the Email Activity API, are you limited to 10 requests per 5 minutes? If yes, what do you do with the API?
Here's an snippet of what I ended up using with requests, tenacity and ratelimit:
from ratelimit import limits, sleep_and_retry
import requests
import tenacity
#sleep_and_retry
#limits(calls=2, period=60)
#tenacity.retry(
retry=tenacity.retry_if_exception_type(requests.exceptions.HTTPError),
stop=tenacity.stop_after_attempt(10),
wait=tenacity.wait.wait_fixed(60),
)
def _call_api(headers, params):
response = requests.get(
"https://api.sendgrid.com/v3/messages",
json={},
headers={},
params={},
)
try:
response.raise_for_status()
except requests.exceptions.HTTPError:
logger.info(f"Request failed {response.headers}, retrying in 1 minute")
raise
return response
I received a response from SendGrid support that says:
Your findings are correct in that we do limit this endpoint to 10 requests per 5 minutes. This is a hard limit that we do not have the means of raising. The Email Activity Feed as well as the Email Activity API endpoint are meant for troubleshooting specific issues and attaining detailed message metadata.
I previously found the rate limit to be 10/5min but it appears that SendGrid have changed the rate limit to 2 requests every 60 seconds sometime in the past week. Can anyone confirm this?
I'm using the webhook to report non-delivery back to my application but I also need to use the activity API to resolve async bounce notifications. Async bounces are when a destination mail server accepts a message during the smtp session but subsequently sends a bounce notification email. When this occurs, SendGrid do not provide the detail of the bounced message in the webhook and the message is incorrectly reported as delivered in the SendGrid app. When asked, they respond that there's nothing they can do about it, even though I have explained to them how I use their activity api to resolve this.
I pay extra to use the activity API to fix a problem that they should address themselves, so I'm very frustrated that they apply such restrictive rate limits, then change them without notice.
The Current Quotas table on the Quotas for Google Services page shows a feature called "Email read/write (excluding send)," which is limited to 50,000 / day for G Suite Business customers.
I have several Google Apps Scripts that use MailApp to send emails, and today users of my scripts started getting the error: "Service invoked too many times for one day: email"
When I ran MailApp.getRemainingDailyQuota() it showed -1, confirming that the quota had been exceeded.
When I checked Google Vault to see how many messages my account had sent between yesterday and today, it showed about 3,294.
When I reached out to G Suite Support to ask about this, they directed me to the G Suite Admin Email sending limits page, which shows that G Suite accounts are limited to sending 2,000 messages per rolling 24-hour period.
3,294 is greater than 2,000, but both are well below 50,000, so I'm wondering what actually counts against the 50,000 quota.
What mail-related operation does "read/write" pertain to?
We also use gsuite and Google script to send lots of mails. And also have lots of questions about quotas. The results of my observation is that limits applied with some lag. I can send over limit mails (some amount), before limitation will apply. Amount is vary and bit unpredictable, but almost always if I do sime pause before sending over limit mails - I got quota errors :(
I can't comment, thats why updating answer. Just try to add few mails into bcc :) and check metrics
In our design we have something of a paradox. We have a database of projects. Each project has a status. We have a REST api to change a project from “Ready” status to “Cleanup” status. Two things must happen.
update the status in the database
send out an email to the approvers
Currently RESTful api does 1, and if that is successful, do 2.
But sometimes the email fails to send. But since (1) is already committed, it is not possible to rollback.
I don't want to send the email prior to commit, because I want to make sure the commit is successful before sending the email.
I thought about undoing step 1, but that is very hard. The status change involves adding new records to the history table, so I need to delete them. And if another person make other changes concurrently, the undo might get messed up.
So what can I do? If (2) fails, should I return “200 OK” to the client?
Seems like the best option is to return “500 Server Error” with error message that says “The project status was changed. However, sending the email to the approvers failed. Please take appropriate action.”
Perhaps I should not try to do 1 + 2 in a single operation? But that just puts the burden on the client, which is worse!
Just some random thoughts:
You can have a notification sent status flag along with a datetime of submission. When an email is successful then it flips, if not then it stays. When changes are submitted then your code iterates through ALL unsent notifications and tries to send. No idea what backend db you are suing but I believe many have the functionality to send emails as well. You could have a scheduled Job (SQL Server Agent for MSSQL) that runs hourly and tries to send if the datetime of the submission is lapsed a certain amount or starts setting off alarms if it fails as well.
If ti is that insanely important then maybe you could integrate a third party service such as sendgrid to run as a backup sending mech. That of course would be more $$ though...
Traditionally I've always separated functions like this into a backend worker process that handles this kind of administrative tasking stuff across many different applications. Some notifications get sent out every morning. Some get sent out every 15 minutes. Some are weekly summaries. If I run into a crash and burn then I light up the event log and we are (lucky/unlucky) enough to have server monitoring tools that alert us on specified application events.
Regarding this API: https://developers.google.com/admin-sdk/email-audit/#accessing_account_information
I have been using the Admin SDK to retrieve login history for users in our Google Apps for Business setup. When I request individual users at a time, the request sometimes takes a few hours to process (in which the state is PENDING). However, when those few hours pass, I still get the login history that I need.
The problem continues as I begin requesting more users. We have around 750 users, and of those 750~ requests I made, 725 gave me an error after waiting ONE WEEK for my requests to be processed. Even worse, the ones that did not error out are still pending! Here is the response I get when I check the status of a request that errored out:
{'status': 'ERROR', 'adminEmailAddress': '***#etsy.com', 'requestDate': '***', 'requestId': '***', 'userEmailAddress': '***#etsy.com'}
This has got to be the flakiest and most unreliable API I have ever been unfortunate enough to work with. Requests can take anywhere from an hour to over a week to process, with no indicator of success in the mean time. Errors can also happen for no apparent reason, and no messages or explanations as to why.
It looks like this issue has been resolved by the Google Engineers. Try to run the calls again. It shouldn't be in pending more than the "normal" expected time. I just tried earlier, and I was able to export login info for my users.
Most of Zynga games use the Maximum App requests per day to show to the user how many requests he can send that day. I couldn't figure out how to get that daily number (dynamically) . Any hints on that? Since, I'm doing this in a flash app. I can't let the user send requests more than he is allowed. Ideas?
You can find out your Requests limit via the Developer Settings page:
https://developers.facebook.com/apps
Note that limits only apply to the older method of sending requests. If you use the newer Requests functionality, there is no limit to the amount of requests you can send:
https://developers.facebook.com/docs/reference/dialogs/requests/
Naturally, if you're being spammy, you'll still get reported a lot and automated systems could block you, so remember to keep to a reasonable volume of requests.