gmail api suddenly returns 403 forbidden - vb.net

I have a VB.net application that has been working great with the gmail.api "gmail.send" scope for months. I have about 3 dozen different gmail accounts that have successfully integrated using OAUTH2. Starting yesterday one of the accounts began returning a 403 Forbidden error. Today another one started doing the same thing. Meanwhile, the others are all working just fine, sending plenty of messages successfully every day. My app hasn't been verified yet, but I would think if it were to be shut down then all of the accounts would not work. Likewise if there was some sort of throttling I would think it would apply to my app as a whole and not affect individual users. It seems very strange that some work and others don't. Any ideas?

I dove into the API instructions. I had been appending a ?key=[gmail application client id] parameter to the POST googleapis.com/upload/gmail/v1/users/userId/messages/send url. I'm not sure why I did that originally, but as of a few days ago it began causing a 403 forbidden error for some of the linked gmail accounts. Problem solved!

Related

Why am I getting a 403 Error When accessing here.com?

We have an application that uses here.com apis. The application had worked up until a month or so ago, but we are now getting a 403 error when trying to access it. We have a freemium account and have not hit our max hits for the site. What could be causing this?

Google Authentication error "500. That’s an error"

Since about 1 week ago I'm getting consistently 500. That’s an error from accounts.google.com side when trying to authenticate with Google.
The first request to
https://accounts.google.com/o/oauth2/auth?scope=openid%20email%20https://adwords.google.com/api/adwords/%20https://www.googleapis.com/auth/drive%20https://spreadsheets.google.com/feeds%20https://docs.google.com/feeds&response_type=token&redirect_uri=https://<XXXXXX>/&state=<XXXX>2&client_id=<MY_CLIENT_NUMBER>.apps.googleusercontent.com&hd=
returns 200, but then the second request to
https://accounts.google.com/signin/oauth?hd&client_id=<app_id>.apps.googleusercontent.com&as=-XXXXXX&nosignup=1&destination=https://<my_app_uri>&approval_state=<somewhatrandomstate>&xsrfsig=<signature>
almost always fails with 500.
I'm using Java Google API client version 1.22.0 and my application is deployed on AWS (region eu-central-1). I'm currently signed in to multiple google accounts, so Account Chooser is triggered.
Any ideas what could be the problem? This auth flow worked fine for long time before then.
The problem was a very slight change of behavior on Google side. Mainly handling hd parameter. Before this change hd parameter was accepted even empty, but now when it's empty it usually ends up with status code 500.

Google oauth2 and 400 bad request: Bug on Google side?

We have Google oauth2 working fine on our website. However, often Chrome users complaint about 400 Bad request and we were able to reproduce it now. Based on the investigation, it indeed looks like a bug on Google side:
It only happens with users who were authenticated earlier and logged-in with multiple accounts on GMail
It doesn't happen when the same user uses incognito window.
This problem is universal and not only with our website. At this moment, I am not able to login using google oauth2 on any website including StackOverflow. Stackoverflow site also gives the same 400 Bad request error and I have to use incognito.
No additional information is present along with 400 Bad Request Error
To further confirm, I just loaded https://accounts.google.com/o/oauth2/auth without any parameters and it also gave 400 Bad request. However, if I load it in incognito, it gives Error: invalid_request. So there is indeed different behavior.
So We suspected that the problem might be with cookies sent along with request since incognito window has no cookies. So we cleared all the cookies for domain accounts.google.com and problem magically solved. This confirms that Google side of code is not able to handle their own cookies.
We really need to solve this. Please help. Do let me know if you need any information.
This might be caused only for the clients that have multiple google accounts logged in as described here Google OAuth2 returns Bad Request when logged with multiple accounts.
It is not clear to me if is a google bug or a miss-use of the api. Anyway stackoverflow is affected as well.

Occasionally 401 Unauthorized Google Cloud Message

While using Google Cloud Message API I occasionally get 401 Unauthorized status. So, sometimes my push notifications are send and sometimes not, without changing anything in the API request.
I use curl request with server key.
I tried to specify IPs list and set it to "Any IP allowed".
I already tried to create new server keys and projects, as some people here tell it helps them in similar situation. Sadly, it not helps me.
I'm seeing a similar problem with other Google Cloud APIs and I suspect it's related to your authentication being expired. Make sure to refresh any tokens you are using.

Google OAuth won't accept its own client_id

I have an app that already successfully uses google oauth, but now I am trying to setup a staging deployment. It is a rails app with devise and omniauth, but I think there might be a problem with how I configured Google.
In the google api admin panel (https://code.google.com/apis/console) I can see the existing app. I created another one with a different callback url (because it is staging). Using Postman (a fancy way to edit the url parameters) I can send a get request to google with the current production client_id and redirect_url and it works fine. When I copy and paste in the new clients (staging's) client_id and redirect_url I always get the error Error: invalid_client.
I'm sure where to start with trying to the figure out the problem, but I've tried a lot of different steps, renaming the urls, changing the client secret, or recreating the client in the admin panel. Any ideas? This error is rather cryptic.
We had a temporary issue with a small set of client ids. The issue should be resolved. If you are still having problems please follow up.