I'm using Play! 2.0.4 with SecureSocial to handle Facebook connect.
With an account that was successfully connecting some days ago, Facebook answers the server with an error, which is thrown here :
https://github.com/aogriffiths/securesocial/blob/master/module-code/app/securesocial/core/providers/FacebookProvider.scala#L65
The error :
{"error":{"message":"Cannot call API on behalf of this user","type":"OAuthException","code":200}}
I thought the token has expired. But a new one is generated at each try to connect.
How can I handle this error ?
Cordially,
Julien
To make it acceptable here my answer from the comments:
These messages are sometimes due to breaking changes somewhere on the Facebook roadmap. Be sure to check all the changes for the current month and your app settings if you have enabled/disabled any of them.
Related
I am trying to register OAuth client, following the docs, but none of the links containing /developers in the path are working for me. I am either getting redirected to the https://my.tapkey.com/AdminUI/ and infinite load, until i refresh the page, or getting status code 502 Bad Gateway.
The ones I am having problems with are:
https://my.tapkey.com/AdminUI/developers/oauth-clients
https://my.tapkey.com/AdminUI/developers/identity-providers.
I tried on different OS's, using proxy, but nothing worked for me.
I am trying to register OAuth client, and explore more of the TapKey web api, but this one is a blocker for me.
You caught us here - we have changed the website a bit, and updated documentation is on its way but not yet published. We are working on it right now.
Developer section has moved to Tapkey Integrator Portal available on https://portal.tapkey.io .
Use the same login credentials you are using with Tapkey.
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.)
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 using omniauth-saml 1.3.1 with omniauth 1.2.2 in rails 4.2. It works well with my test identity provider set up at openidp.feide.no (a nifty tool for those setting up a SAML service provider). It even works in production.
Now I am trying to get an IdP set up with a client of mine. When the user visits /auth/saml, they are directed to the client's IdP as expected. The user is able to use their email/pw to login.
The IdP then responds to my SP, but omniauth is redirecting to the failure callback.
As seen here, I get an error message "invalid_ticket". However, the error itself isn't getting passed to my failure controller action in env["omniauth.error"], as I read it should somewhere (unfortunately I can't find that documentation right now).
I'm hoping somebody will have some advice as to how I can figure out what is causing the "invalid_ticket" to happen. Is there perhaps a way to see the raw SAML response from the IdP?
I should note that I need to find this information in production because the client's IdP points to our production SP and I can't convince them to point it somewhere I can do some more extensive testing (like my localhost dev machine). I can, however, write in some more logging or Honeybadger exception reporting if that will help.
Currently, I am reporting to Honeybadger all env["omniauth.*"] values and params when omniauth redirects to the failure route, but I am not getting any information further than Omniauth message: invalid_ticket.
A big thank you to anyone who can help me go in the right direction here!
You might want to try adding other environments to failure_raise_out_environments:
OmniAuth.config.failure_raise_out_environments = ['development', 'staging', 'production']
to your initializer. You will get meaningful error messages in your log or Honeybadger.
These errors are by default raised only in development environment.
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.