We are getting internal_failure error message while exchanging code to get refresh token. This error doesn't occur all the time for all the accounts. This happens only while authenticating with a few Google accounts and that too like 5 to 6 failures for every 10 authentication requests no matter what the client_id is. We have a test account and is reproducible too frequently in this account as well.
{
"error" : "internal_failure"
}
How often are you making these requests? You are probably running into the per account quota limits.
In real life, any account would not be doing a lot of code to refresh token conversion. The expectation is that you do that just once per application.
So, if you have test/monitoring accounts, they will run into these issues. The best is for you to monitor and test only your site/code.
internal_failure is an authentication server outage. which can be tracked on
Cloud Status or apparently also APP Status although I am not seeing it there it may only be GSuite issues are there.
There is nothing that you can do but wait for the server to return.
Related
I have an app that uses the Twitter API where users can authenticate via twitter and retweet/like/follow through my app. Randomly this week the logs are showing "code: 89 Invalid or expired token".
Naturally, I go login to twitter to see the status of my app, and nothing seems out of the ordinary. I saw others with this issue had success regenerating their keys and replacing them in their application.
This didn't help.
One important thing to note is nothing has changed in the code of my application for the last 3-4 months, so I doubt it's anything in there. It's been working for over two years without any issue.
The thing I suspect the most is perhaps Twitter decided to suspend my app; Although, I don't see anywhere that is the case, and I thought I'd receive an email from them about it if it were.
I'm at a loss and would appreciate some possible solutions or alternative avenues I can pursue to find the culprit.
The keys associated with your app are the API Key (Consumer Token) and API secret key (Consumer Secret). The error you're getting is for the Access token, which belongs to the user. It sounds like the user associated with that request needs to authorize your app again before it can operate again with their access key. This can happen if the user removes authorization for your app by visiting their Settings/Privacy and safety/Apps and sessions.
If you were using your own access token in a scenario like single-user authorization, then regenerating the key might work, but in this case, the only way to get new keys for that user is for them to go through the sign-in process to authorize your app again. e.g. you could log who the user was that the error occurred on and send them a notification to re-authorize.
We are currently working on a mobile application which is currently in beta version and plan to get it released to App Store very soon and this primarily supports only iOS mobile devices
Recently one of the external users had frantically typed a wrong password repeatedly in login screen which further exceeded the limit, resulting in an internal server error and finally locked the user out of the app
The default error messages come from AWS Cognito and the user is required to fill in the phone number and password to log in to the app
How many times will AWS Cognito allow the user to punch in incorrect passwords. Is there a limit to it
Is there any documentation which clearly explains my problem
Is there a way to let the user know at the first instance say., that there are only 5 attempts to try
Any help is much appreciated
According to AWS Cognito docs,there are no limits on login attempts, however they do secure login endpoint with request rate limiting and exponential timeouts:
We allow five failed sign-in attempts. After that we start temporary lockouts with exponentially increasing times starting at 1 second and doubling after each failed attempt up to about 15 minutes. Attempts during a temporary lockout period are ignored. After the temporary lockout period, if the next attempt fails, a new temporary lockout starts with twice the duration as the last. Waiting about 15 minutes without any attempts will also reset the temporary lockout. Please note that this behavior is subject to change.
https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-authentication-flow.html
Account linking problem for only some of our users, most users link account normally. For users linking account failed, they just see the login page refreshed to empty account name and password.
From our server log, we found for users that fail to link, the user accesses our server successfully and got OAUTH code, but after about 15 seconds, google server accessed our server to exchange the code for a token. However, the code has expired by this time.
For successfully linked users, the time between issuing the code and exchanging it for a token is about 2 seconds.
Does anybody know how to resolve the problem? Thanks.
It sounds like the expiration time for the authorization code has been set to about 10-15 seconds. While the auth code should have a short lifetime, 10 seconds is way too short. The recommended lifetime should be no more than 10 minutes, not 10 seconds.
Consider that this code needs to be sent back from your server to the user, from the user to Google, and then from Google to your server. On some networks, each step might take more than a couple of seconds, particularly since it must be done over HTTPS this adds both network and processing overhead. Each step adds just a few fractions of a second - but they can add up on some devices!
There could also be a slight clock skew between the issuing server and the processing server - likely not much, but when you have a lifetime of a just a few seconds, even a 1 second skew could be too much. If the two are very out of skew, then this could be the cause of your problem as well. Make sure the clocks on your servers are at least reasonably in sync.
The best solution would be to increase this timeout on your server when you generate or accept the code. You may have thought you were specifying 10 minutes for a configuration field that actually accepts seconds.
A significant number of users are getting the error message of 'GetAccessToken - Unauthorized error: Your network is not allowed to request an OAuth token for this Application' whilst trying to log in to our application.
I have checked and tested, and they are accessing the correct network with the right credentials. This is happening to almost every person, so I don't believe this to be a coincidence.
This has only begun to happen in the past 24-36 hours. Are there any suggestions as to why this error is occurring, has something changed that I may have missed?
Thanks!
Couple of possible scenarios:
It is likely that the new simplified SSO is rolling out for these
users, which means they will use their O365 credentials to login to
Yammer from now on. Every user will need to reauth external apps (I
had to for our own apps also when this change occurred for us last
week).
Tokens also can expire when user's passwords expire, so if
they have a mandatory time interval to reset this could trigger an en masse need to reauth
Make sure your JS Origins are specified in your app details if you are using the Login with Yammer button and/or the JS SDK. http://naomimoneypenny.com/2015/02/11/yammer-apps-javascript-origins-update/
There isn't clear and definitive guidance regrettably from Yammer as to why and when tokens expire. Just that they do e.g. from https://developer.yammer.com/v1.0/docs/oauth-2
Once the token expires, you will need to re-run the steps above to generate a new code and access_token.
I randomly get the following message when trying to access the graph from my iPhone using Facebook iOS SDK:
response string: {"error":{"type":"OAuthException","message":"Error validating access token: The session was invalidated explicitly using an API call."}}
I'm not sure why this is because I call the graph immediately after I login, so the token should be valid. Also, this happens randomly around 30% of the time. Does anyone know how to go about debugging this issue?
I've been experiencing the same issue. It happens with any graph request after calling authorize immediately after a successful logout callback (with the idea being that a different user can log in from there).
The authorization screen will say that the user's already accepted the permissions (even though they're supposed to be logged out now...) and if they hit ok it will cause the issue. Almost as if the auth process reissues an invalidated token because it doesn't get the memo that they've logged out. However it won't happen if the user hits the "not you?" link and logs in as someone else as intended (or if they log in again as the same user), so this isn't a major issue in my case.
As for an answer / fix, I made mine fix itself by detecting the error response from the graph call and then making another call to authorize. Not ideal though, since it annoys the user with two consecutive app switches...