I went through the sandbox testing and graduation procedure. My application got approved (for internal use), but I've been unable to use the new client ID.
The OAuth callback URL contains the error message:
GET /oauth2callback?error=invalid_request&error_description=OAU-230%3AInvalid%20or%20unknown%20client%3A%20xxxxxxxclientIdxxxxx
I copied my client ID several times from the application credentials page, it is correct and complete. The ID is repeated correctly inside the error message as well, so I know it's received on the production server. The production server URL is correct too.
What's going on here?
Apparently, all I had to do is wait. After graduating my application and getting the Approved message, RingCentral took a while longer for the new credentials to start working. I don't know how long it took, as I've waited 28 days to try again.
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.
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.)
After processing the payment, control is not directing back to our site(x_relay_url) from https://test.authorize.net/gateway/transact.dll.
The URL mentioned in the x_relay_url cannot be accessed directly it requires session id and other details to access it which was passed to Authorize net page using merchantDefinedData variables.
I checked the following article also but our URL seems to be fine and we checked our code there is nothing wrong in that.
I tried multiple URLs in "x_relay_url" but nothing seems to be working.
Any help is appreciated.
Error Message:
An error occurred while trying to report this transaction to the
merchant. An e-mail has been sent to the merchant informing them of
the error. The following is the result of the attempt to charge your
credit card.
This transaction has been approved.
It is advisable for you to contact the merchant to verify that you will receive the product or service.
I have installed authorize.net sdk(PHP) and changed config file. I am running the sample app that comes along with the bundle.
When I proceed with the payment, the transaction fails and responses below error
"We're sorry, but we can't process your order at this time due to the following error:
The merchant login ID or password is invalid or the account is inactive.
response code 3
response reason code 13"
Naturally you need to verify your login credentials are correct. Also, make sure you are using the right server. You can use the production server or development server for testing. If you mix up your credentials that will cause this also.
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.