Last year I was building an application to create my own YT dashboard.
It was based only the code of a tutorial
They basically authenticate a user via OAuth and send requests to get channel data or playlists of the authenticated user.
I was trying out both the original tutorial app and my own (after a few dormant months) and they suddenly don't work anymore.
Meaning: I can authenticate on both, but on the original version I get a 403 error telling me: "The request is missing a valid API key." (on requesting channel data)
This is confusing because the API key is never used because only the OAuth client id was necessary.
And on my own fancy version, I get a 403 error telling me that I've exceeded my getting started quota. (on requesting the users playlists)
Looking at my quota page:
I can see, that queries per day (why is it there twice?) is somehow set to 0.
Perhaps creating a new OAuth 2.0 Client ID or a new API key would solve these errors, as was suggested in another post.
But since I'm planning to use the YT Data API in a real project soon and want to prevent this from ever happening I would like to understand what was going on. Why the daily quota limit is suddenly turned to 0 and how to go about it when that happens.
Or at least how to contact google about it.
Perhaps some of you have some insights.
UPDATE:
I've just found this post reporting, that after 90 inactive days, the quota is automatically set to 0.
Now I created a new OAuth Client Id and replaced the constant in my code. Nothing changed so far. Perhaps I have to wait 24h. Or perhaps I have to fill out this form which apparently can lead to months of back and forth email nonsense. I sure hope not.
It seemed the only viable option was to create a new project with new credentials.
(And one should not forget that the YT Data API has to be enabled again for the new project.)
Related
I have created an app in Django. Using Twilio Verify API (free trial) for OTP.
Problem:-
It's working fine but when a user try to get the OTP multiple times, Twilio creates an exception "HTTP 429 error: Unable to create record: Too many requests". After this I was not able to use this for the whole day even for different mobile number or device.
How to bypass this issue and precisely what is the reason behind this issue?
Twilio Developer Evangelist here. The Verify API has rate limits for sending SMS codes to the same phone number, ~5 requests within 10 minutes. I'm not sure why it wasn't working with a different phone number, though - let me know if you're still having issues after you try the below.
You're definitely not the first person to run into this issue, so I have a blog post that should answer the question: How to test Twilio Verify without getting rate limited
tl;dr your options include -
Complete a verification lifecycle by calling the Verification Check endpoint
Wait for the verification to expire (in 10 minutes)
I also recommend spinning up a Verification Testing Dashboard that will help you check/cancel a verification during development.
Here's another blog post about managing retry logic that's also designed to prevent hitting API rate limits: https://www.twilio.com/blog/best-practices-retry-logic-sms-2fa
This may have been solved by now but for anyone else it's possible that the free Twilio trial account has expired or used up it's allocated requests. This happened me as I had forgotten I was using a trial account in a test environment, and when tests started to fail this was the issue.
I encountered the same problem with email channel when a user tries to send verify api multiple times and gets this error. All other emails would get the same error, and nobody can get verified. This looks to me that one user gets rate limited and it could affect all other users.
I have been using Gmail API to automatic email processing in production for many months now. All of a sudden since July 2, 2020 seeing the error message trying to access Gmail API.
HttpError 403 when requesting https://www.googleapis.com/discovery/v1/apis/gmail/v1/rest returned
"The caller does not have permission"
Checked Gmail Dashboard and the credentials are active noting was removed or modified.
Checked code and can confirm nothing changed for 3-4 months.
And we are not using old token. Our code takes care of expired credentials and does a token refresh.
Also tried removing the token.pickle file, when rerun re-authenticated using the Gmail Auth screen and token.pickle file is recreated however the error message cannot be resolved.
It looks like something changed in Google's end.
Can someone please confirm ?
When doing a search seems lot of ppl are seeing this in various APIs recently but no viable solution is provided.
This is a system-wide issue on Google's side: https://issuetracker.google.com/issues/160441983
logged against python api here: https://github.com/googleapis/google-api-python-client/issues/959. they seemed to be responsive before
There is a workaround using a local copy of the discovery json file posted in the thread yihlamur linked: https://issuetracker.google.com/u/1/issues/160441983#comment73. The workaround was successful for us.
I had this issue yesterday aswell. The issue has since been resolved. See - https://issuetracker.google.com/issues/160441983
I am getting the following error ("Error: HTTP status code: 400") now that I have updated to facebook SDK 3.1 as of yesterday, 10/9. But everything is completely functional as far as connecting with facebook, I just see this error message every time I start a facebook session on my app. I have seen a few people commenting on this, but I can't determine from them if this is going to be a real problem or not. Does anyone know definitively if this is going to cause a problem? And if so, how to fix it? Thanks!
The original issue was resolved by Facebook just after the 3.1 SDK was released.
But some are still having issues, if you have this issue you should check the login flow, and look at facebooks examples, after that if you are still having issues this could be a hint to a solution.
I got the 400 error when I do not have authorization to get to my information. The strange thing is that I get an accessToken and even a valid login (this is because I structured my code, with the help according to Scrumptious example and did a valid login when the Session state is open).
The FBSessionState is only opened for like a second and then it changes to closed with an 400 Error.
With iOS6 native login you get the permission alert when you ask for it, and then the phone remember that choice for 24 hours. But if the user logs in to the facebook home-page and then deletes permission for the application the phone will not recognize that the user has deleted the permissions for 24 hours, since it remembers the that the phone has already asked it and approved it (in the 24-hour window), regardless if you re-install the app or not.
I found this out after some hours of debugging, since I allowed the application from the Settings in iOS, but I could not post, and since I deleted the permission from the facebook privacy, and the alert would not show again there was nothing I could do but to manually give me permissions via a debug tool or wait 24 hours so I could accept the facebook-permission alert again.
I need to migrate my FB app away from using the offline_access permission. As I understand it, server-side OAuth should return a long-lived (60 days) access_token once the user has authenticated.
Once those 60 days are up, I have to request a new token. But, can I do this transparently without requiring the user to revisit Facebook? I understand that the user won't be prompted for the same permissions, but:
a) the redirect_uri parameter must point to a URL where I can process the OAuth request, which makes it difficult for a transparent operation
b) many of my Graph API calls are initiated from AJAX requests hitting my server. If these are rejected due to an expired token, I can't redirect the user away without breaking my application flow.
So my question is, can this be done in a completely transparent manner? I'm assuming the answer is 'No' but bugging the user every 60 days - especially if they've been using the app regularly for 59 days - seems overkill.
It does indeed look like the answer is "No"... Under Scenario 3
Note: The user must access your application before you're able to get
a valid "authorization Code" to be able to make the server-side OAuth
call again. Apps will not be able to setup a background/cron job that
tries to automatically extend the expiration time, because the
"authorization code" is short-lived and will have expired.
We're facing the same problem and it looks like we're going to be forced to bug the user every 60 days. Thankfully this is a relatively minor part of our system and all the AJAX calls are made to our servers which in turn query fb - so we've got a layer of abstraction there where we can hand back cached data/control messages to manage application flow which gives us some wiggle room in terms of failing gracefully until we can get pending data stored and redirect the user appropriately.
Incidentally, it's worth noting that according to the roadmap offline_access will officially become deprecated on 3rd Oct 2012.
I've tried do develop automatic code that would fetch data from ads campaigns under account. My plan is to have server that would query every day to get data from impressions/clicks/costs of ads and save it for later use.
I use https://developers.facebook.com/tools/explorer to get access_token for getting data (insights) from those campaign pages but when I log out to try offline_access it tells access_token is old, cause of password change or access_token getting outdated.
Isn't the whole point of offline_access to grant acccess when user is not logged in?
And besides that.. what's with most of my calls ending having reply as follows:
"(#294) Managing advertisements requires the extended permission ads_management, and a participating API key"
I've given access_token that has ads_management, but I have no idea what this Participating Api key even means. Do I need to add this to url call or something? Where do I get this Api Key?
Edit: I want to be able to get data from add campaign pages, so I'm not talking about Apps in page
You will want to read up on the deprecation of the offline_access here: https://developers.facebook.com/docs/offline-access-deprecation/
But most importantly follow the guide here on how to handle invalid access tokens:
https://developers.facebook.com/blog/post/500/
You app is to monitor the error messages coming back from the API and handle it gracefully.
I have the same issue and I found this bug can be reason of our problem. It's already accepted and assigned, but still not solved. I hope it's really bug and not a secure hole, that was closed :)