Error when exchanging code for Oauth - google-drive-api

Suddenly, I am getting an error during the Oauth process, after my app has been given permission for access by the user and a authorization code is delivered to my redirect url. I've been using the same code for a couple weeks now, and it has been working fine. I'm pretty certain I haven't made any changes.
Is there an issue with Google Drive API today?
The error occurs here in Python code here:
credentials = flow.step2_exchange(authorization_code)
Error message:
FlowExchangeError: Invalid response 400.
The entire exchange_code method as copied from Google example:
def exchange_code(authorization_code):
"""Exchange an authorization code for OAuth 2.0 credentials.
Args:
authorization_code: Authorization code to exchange for OAuth 2.0
credentials.
Returns:
oauth2client.client.OAuth2Credentials instance.
Raises:
CodeExchangeException: an error occurred.
"""
logging.debug(authorization_code);
flow = flow_from_clientsecrets(CLIENTSECRETS_LOCATION, ' '.join(SCOPES))
flow.redirect_uri = REDIRECT_URI
try:
credentials = flow.step2_exchange(authorization_code)
return credentials
except FlowExchangeError, error:
logging.error('An error occurred: %s', error)
raise CodeExchangeException(None)
Using Oauth Playground, I get the following error response:
HTTP/1.1 400 Ok
Status: 400
Content-length: 37
X-xss-protection: 1; mode=block
X-content-type-options: nosniff
X-google-cache-control: remote-fetch
-content-encoding: gzip
Server: GSE
Via: HTTP/1.1 GWA
Pragma: no-cache
Cache-control: no-cache, no-store, max-age=0, must-revalidate
Date: Fri, 10 Aug 2012 03:23:54 GMT
X-frame-options: SAMEORIGIN
Content-type: application/json
Expires: Fri, 01 Jan 1990 00:00:00 GMT
{
"error" : "unauthorized_client"
}
Any ideas why this would start happening when the code was working for weeks as it is now?
Thanks,
Chris

The HTTP response code 400 means that your request is somehow invalid and there should be a more descriptive error message telling you what is wrong.
Perhaps the Python library is hiding the complete message, I'd recommend you to try the same request with the OAuth 2.0 Playground and compare it with yours:
https://code.google.com/oauthplayground/

I was finally able to get the code working again. I reverted the GAE app version to my prior version. Oauth exchange_code worked again. Then I took it back to the current version on GAE, with no changes to the code whatsoever, and it continues to work.
So the oauth process did stop working when I recently created new version in GAE with no changes to the code. For what it's worth.....

Related

Revit Design Automation fails on downloading resources

I have been able to run several jobs on Forge, but I am running into a new situation today. It seems like the workitem stays idle for about 70 minutes even when it reports back "In Progress". Finally when the workitem starts, it fails immediately on downloading resources. I am assuming because the signed URL doesn't last that long:
[06/10/2022 01:07:09] Starting work item accb10182b02420f925ccd4d113dffbd
[06/10/2022 01:07:09] Start download phase.
[06/10/2022 01:07:09] Start downloading input: verb - 'GET', url - 'https://developer.api.autodesk.com/oss/v2/signedresources/b70c5565-0ff5-48cb-af7b-b3f57113786e?region=US'
[06/10/2022 01:07:10] Embedded resource [{"ViewName": "VR_EXPORT"}] is saved as file: T:\Aces\Jobs\accb10182b02420f925ccd4d113dffbd\params.json.
[06/10/2022 01:07:10] Error: Failed - 404 (Not Found)
Request: GET https://developer.api.autodesk.com/oss/v2/signedresources/b70c5565-0ff5-48cb-af7b-b3f57113786e?region=US
Response Headers:
Access-Control-Allow-Headers: Authorization, Accept-Encoding, Range, Content-Type
Access-Control-Allow-Methods: GET
Access-Control-Allow-Origin: *
Date: Fri, 10 Jun 2022 01:07:10 GMT
Strict-Transport-Security: max-age=31536000; includeSubDomains
x-ads-region: US
X-Content-Type-Options: nosniff
Connection: keep-alive
Response Content Headers:
Content-Type: application/json; charset=utf-8
Content-Length: 38
Response Body:
{"reason":"Signed Resource not found"}
Not sure if this is an internal issue with Design Automation or I am doing something wrong.

EWS managed-api encountered 500 internal server error when import EML

When I import a large mail filer via ews-managed api, it encountered http code 500 with reponse:
Cache-Control: private^M
Content-Length: 1015^M
Content-Type: text/xml; charset=utf-8^M
Date: Thu, 20 Sep 2018 03:03:01 GMT^M
HTTP/1.1 500 Internal Server Error^M
Server: Microsoft-IIS/10.0^M
Set-Cookie: exchangecookie=12133ae873f24a8f80b93e5b92ab3979;
expires=Fri, 20-Sep-2019 03:01:27 GMT; path=/; HttpOnly^M
X-AspNet-Version: 4.0.30319^M
X-BEServer: PS2PR02MB2694^M
X-BackEndHttpStatus: 500^M
X-BeSku: WCS5^M
X-CalculatedBETarget: PS2PR02MB2694.apcprd02.prod.outlook.com^M
X-CalculatedFETarget: PS2P216CU002.internal.outlook.com^M
X-DiagInfo: PS2PR02MB2694^M
X-FEProxyInfo: PS2P216CA0031.KORP216.PROD.OUTLOOK.COM^M
X-FEServer: HK0PR03CA0085^M
X-FEServer: PS2P216CA0031^M
X-Powered-By: ASP.NET
X-RUM-Validated: 1
request-id: 905db567-dcf7-449c-820d-b00ed0afa981
x-ms-appId: af08ce07-1df9-4a39-b6e6-092ac934eb21
However, the mail was successfully uploaded.
It should be a mismatch error code, or something wrong in this request.
Should I retry this request again? or anyway to improve this behavior?
Thanks for help.
Make sure your setting the X-AnchorMailbox header to the Mailbox your importing to otherwise the backend servers will be proxying the request on you behalf so you can get that type of error for long running operations when the server doesn't receive the response in time (the state of the operation at that point is unknown).

OAuth2 redirect_url_mismatch error in oauth playground

I have created the Credentials and configured my Gmail Addon to use the same.
I am Using the : https://github.com/googlesamples/apps-script-oauth2 in the Gmail Addon (I am not using the messages's temp access token).
I have generated an "Auth Code" from the Gmail Add-on application (without creating access tokens from the same). I now want to use the same to generate the access token from Auth Playground [I finally want to use the Authorization Code for another Java application to pull in users emails]
I wanted to check if the same Authorization Code can be used by OAuth Playground
Using "Authorization Code" from the Gmail Addon in the OAuth2 Playground always gives: redirect_url_mismatch error.
code=4%2FAABqS_YGEwyFBM4N42-NzRMaOU6kGis2VWgvcv9tbiP77zBjJWzM096oO04rJ26uXOQDKEpyYvElb2kp1Jzd7gU&redirect_uri=https%3A%2F%2Fdevelopers.google.com%2Foauthplayground&client_id=183587298757-6pm37j05msctfimobq0kl48fsap42v7i.apps.googleusercontent.com&client_secret=yGhUgj-vZDuxyz-2Hrmb7EHE&scope=&grant_type=authorization_code
HTTP/1.1 400 Bad Request
Content-length: 75
X-xss-protection: 1; mode=block
X-content-type-options: nosniff
Transfer-encoding: chunked
Expires: Tue, 06 Mar 2018 15:54:51 GMT
Vary: Origin, X-Origin
Server: GSE
-content-encoding: gzip
Cache-control: private, max-age=0
Date: Tue, 06 Mar 2018 15:54:51 GMT
X-frame-options: SAMEORIGIN
Alt-svc: hq=":443"; ma=2592000; quic=51303431; quic=51303339; quic=51303338; quic=51303337; quic=51303335,quic=":443"; ma=2592000; v="41,39,38,37,35"
Content-type: application/json; charset=UTF-8
{
"error_description": "Bad Request",
**"error": "redirect_uri_mismatch"**
}
I have reconfirmed that I have the : https://developers.google.com/oauthplayground listed under "Authorized redirect URIs" I have tried with and without slash both.
I have correctly used "Use your own OAuth credentials" and put in the Client Id and Secret. The same ones used by the Gmail Addon to create the auth tokens.
Firstly, is it possible to achive what I am trying to do ? If so what is it that I am missing out on thats leading to this error ?
I might be missing something, but I have not been able to pinpoint it.
I have read the other answers with similar questions and have had no success in getting this to work.
The Code to setup the client (The credentials are same that I used in the playgound, store in properties) :
Just add the /oauth2callback at the end in your Authorized redirect URIs which looks like:
https://developers.google.com/oauthplayground/oauth2callback

Cache manifest validator Proxy Error on manifest-validator.com

I am trying to use http://manifest-validator.com/ to check my cache manifest file by URI. It has been failing with the message:
Proxy Error
The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request POST /validate.
Reason: Error reading from remote server
I have tried removing my robots.txt file in case Disallow: / was causing problems.
Has anyone else experienced this Proxy Error?
Is this something that I can fix or is it an error with manifest-validator.com ?
In short
The reason for your error in this validator is a missing content-type attribute in your http response headers. Add one like text/cache-manifest and it will work.
Explaining the details
First of all, here are the response headers sent by your server. Note the missing content-type:
robert#robert-ubuntu:~$ curl -I -X HEAD http://nucreativetesting.co.uk/cache-test/test003/manifest.appcache
HTTP/1.1 200 OK
Date: Tue, 07 Oct 2014 16:25:59 GMT
Server: Apache/2.4.9 (Unix)
Last-Modified: Mon, 11 Aug 2014 13:45:07 GMT
ETag: "46c-5005ac34a2331"
Accept-Ranges: bytes
Content-Length: 1132
Why the proxy error?
The validator you are using is a NodeJS project, proxied by an apache webserver. The reason you get an error is that the apache waits for NodeJS to generate a response but it's hanging. After some time it gets a timeout and returns your error.
So why is it hanging?
In the current implementation of this validator you find the following code [1]:
try {
contentType = res.headers['content-type'].split(';')[0];
if ( ['text/plain', 'text/cache-manifest'].indexOf( contentType ) === -1 ) {
callback('ERR_MANIFEST_MIMETYPE');
return;
}
} catch(e) {
// TODO: Debug statement in production, had some strange output in the error logs.
// Should be removed again
console.error('manifest.js: Content-Type');
return;
}
We see that res.headers['content-type'] should get split, but if there's no content type in your request header, this will raise an Exception because res.headers['content-type'] is undefined. The Exception itself is just logged to the servers output but isn't handled with their callback() function. Thats the reason the request is hanging till timeout.
Conclusion
It might be a bug or bad error handling on their side or just very unusual to not have a content type in your header. I don't know. But it should work with a content type ;).
References
[1]: https://github.com/fhemberger/manifest-validator/blob/6d82bc4660c4daaa131fee3c19a88ae6e462a44b/app/lib/manifest.js#L63 code producing your error

google drive error processing oauth 2 request 400

we have several google oauth2 refresh tokens for Google Drive for which we always get the following error when trying to request a new access token:
POST /o/oauth2/token HTTP/1.1
Connection: close
accept-encoding: gzip, deflate
content-type: application/x-www-form-urlencoded
Content-Length: 208
Host: accounts.google.com
refresh_token=1%2FY5_2XY8uGujYa222rxXnsjR<snipped>&client_id=<clientid>&grant_type=refresh_token&client_secret=<clientsecret>
Response:
HTTP/1.1 400 Error processing OAuth 2 request
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: Fri, 01 Jan 1990 00:00:00 GMT
Date: Tue, 20 Aug 2013 14:55:24 GMT
<HTML>
<HEAD>
<TITLE>Error processing OAuth 2 request</TITLE>
</HEAD>
<BODY BGCOLOR="#FFFFFF" TEXT="#000000">
<H1>Error processing OAuth 2 request</H1>
<H2>Error 400</H2>
</BODY>
</HTML>
This only happens for some accounts, others work fine. The broken accounts fail reproducibly across days and weeks. Is there something wrong with the data we send? Any hint on what fails the validation?
I could provide you the tokens that are failing if necessary.
As far as I can tell all these refresh tokens fail because of invalid user accounts (deleted, disabled, etc). In these cases for all intents and purposes the token itself is invalid.
The HTML error response is a bug, and it should be fixed by now. Please report if you still see errors like this. The proper OAuth 2 error code in this case is "invalid_token".