Gmail API throwing 401 Unauthorized - node.js

I'm trying to integrate Gmail API in my app in order to send emails to users.
i've created a project on Google Developers Console, enabled Gamil API in it, downloaded the credentials as JSON and followed the instruction provided at https://developers.google.com/gmail/api/quickstart/nodejs
I've also added https://developers.google.com/oauthplayground as a redirect URI for the project.
When I run the code, I get redirected to a consent screen. I choose the account which has the project, then get redirected to "oauthplayground"
However, when I try to exchange authorization code for tokens, I receive 401 unauthorized
the full response is:
HTTP/1.1 401 Unauthorized
Content-length: 75
X-xss-protection: 0
X-content-type-options: nosniff
Transfer-encoding: chunked
Expires: Mon, 01 Jan 1990 00:00:00 GMT
Vary: Origin, X-Origin, Referer
Server: scaffolding on HTTPServer2
-content-encoding: gzip
Pragma: no-cache
Cache-control: no-cache, no-store, max-age=0, must-revalidate
Date: Wed, 21 Oct 2020 07:53:18 GMT
X-frame-options: SAMEORIGIN
Alt-svc: h3-Q050=":443"; ma=2592000,h3-29=":443"; ma=2592000,h3-T051=":443"; ma=2592000,h3-T050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43"
Content-type: application/json; charset=utf-8
{
"error_description": "Unauthorized",
"error": "unauthorized_client"
}
Any help is appreciated
Thanks

Related

Validating assets api from postman using rest api for azure media service 401 unauthorzed

Follow link https://learn.microsoft.com/en-us/azure/media-services/previous/media-services-rest-connect-with-aad
Get: https://mediatest1.restv2.SoutheastAsia.media.azure.net/api/Assets
Header:
Content-Type: application/json;odata=verbose
Accept: application/json;odata=verbose
DataServiceVersion: 3.0
MaxDataServiceVersion: 3.0
x-ms-version: 2.19
Host:media.windows.net
Authoriztion: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Im5PbzNaRHJPRFhFSzFqS1doWHNsSFJfS1hFZyIsImtpZCI6Im5PbzNaRHJPRFhFSzFqS1doWHNsSFJfS1hFZyJ9.eyJhdWQiOiJodHRwczovL21hbmFnZW1lbnQuY29yZS53aW5kb3dzLm5ldCIsImlzcyI6Imh0dHBzOi8vc3RzLndpbmRvd3MubmV0L2Y2NDI4YTBhLWE1NTItNDg1Yi04Zjg1LWJhNDU3NjA5ZjEyMS8iLCJpYXQiOjE2MTQwODg1NDYsIm5iZiI6MTYxNDA4ODU0NiwiZXhwIjoxNjE0MDkyNDQ2LCJhaW8iOiJFMllBZ3VXNm43WThFSk9YVG4rdStaYlAvd01BIiwiYXBwaWQiOiI2ZTNjNjg3MC1lMjQwLTQ1ZWYtYWVkNS1jYzk3Mjk0MzE0NTEiLCJhcHBpZGFjciI6IjEiLCJpZHAiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC9mNjQyOGEwYS1hNTUyLTQ4NWItOGY4NS1iYTQ1NzYwOWYxMjEvIiwib2lkIjoiYzI3MzBhYTAtMDY1My00NzIzLWE0MmItOWJkZWIyOTYzZDAyIiwicmgiOiIwLkFBQUFDb3BDOWxLbFcwaVBoYnBGZGdueElYQm9QRzVBNHU5RnJ0WE1seWxERkZGd0FBQS4iLCJzdWIiOiJjMjczMGFhMC0wNjUzLTQ3MjMtYTQyYi05YmRlYjI5NjNkMDIiLCJ0aWQiOiJmNjQyOGEwYS1hNTUyLTQ4NWItOGY4NS1iYTQ1NzYwOWYxMjEiLCJ1dGkiOiIxM2hOZkNXbjVrcTRSZWRJRGZZQUFBIiwidmVyIjoiMS4wIiwieG1zX3RjZHQiOjE2MTM0Njk0OTh9.WmtlWAuY_UxQDjsx7p7N7hQBP061Mx_CMlMP51bA7yXF4ac7Nr46gs1nrj-lTTKEoEuJXb-k-GiMtcfvDc5ooeEHO-IAC3LIFItlQBtgQ1jcAM3QtwXEY8CLJ7yG6XXCk4GtIDLCrcXfh5hg2qdI06gZFdabeEA2aQDrqFbJFj-u4UIkvnPMklM5xs3szHceYQFtiVbblzS8fTBQfkHdYEDWLQunpwH-_GT5h4O_YVtoElmKWjzHgBDO9rA4XgejWFLNV5KzKSjd31IW2EzFb9DWpdaJP1P8ou9pJ_fQvLMAfzk73F4eR785VIPvOP3gfwgw2OSaboFUO_o1gFpADA
Response:
401
Server: Microsoft-IIS/10.0
request-id: 3e93ef9f-cb7e-4921-8e99-b911469d0020
x-ms-request-id: 3e93ef9f-cb7e-4921-8e99-b911469d0020
access-control-expose-headers: request-id, x-ms-request-id
WWW-Authenticate: Bearer
WWW-Authenticate: Bearer
X-Powered-By: ASP.NET
Strict-Transport-Security: max-age=31536000; includeSubDomains
Date: Tue, 23 Feb 2021 14:20:47 GMT
it is working fine when i using azure sdk
Looking for help as i am struggling for last 6 hours
Thank you in advance

Files.ReadWrite ROPC MS Graph API 403 Error Though Scope shows correct authorization

We have a use case in our corporation in which ROPC is deemed secure in which we upload a file to a sharepoint folder. The user has been granted the contributor role. When we log onto sharepoint as the user, she can upload a file.
However, when we try to do the same through our application, we are getting 403 forbidden. Looking at the token we get through ROPC, I see the following:
Files.ReadWrite User.Read profile openid email
Why are we then getting 403 Forbidden when we try to upload the file?
A few more pieces of info:
Consent has been granted by the Administrator for the Delegated permission of Files.ReadWrite.
Application Manifest has allowPublicClient set to true.
In testing this use case, we were able to retrieve a user profile without problem, but for some reason the Files.ReadWrite says not authorized although the user can upload a file no problem from within Sharepoint.
Screenshot of API Permissions:
Decoded token part 1:
Decoded token part 2:
Failing Request:
POST /v1.0/sites/92a99e5f-bb3e-4588-9461-d640b59d52e2/drives/b!X56pkj67iEWUYdZAtZ1S4hDhiQyamFVEj8y19ROdYOKYReOmD1sXSoDAvyFjD733/root:/Miriams%20Folder/FMW%20Management%20EM12c.pptx:/microsoft.graph.createUploadSession HTTP/1.1
SdkVersion: graph-java/v2.4.1
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJub25jZSI6InJNckJTQlBjNnlWZmVGVVZpbXhkYXEwdUpPMDNPQTFIWnZQQ01mV21uLUEiLCJhbGciOiJSUzI1NiIsIng1dCI6ImtnMkxZczJUMENUaklmajRydDZKSXluZW4zOCIsImtpZCI6ImtnMkxZczJUMENUaklmajRydDZKSXluZW4zOCJ9.eyJhdWQiOiJodHRwczovL2dyYXBoLm1pY3Jvc29mdC5jb20iLCJpc3MiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC83Y2I5M2QyOS0yZGRkLTQ5NDAtYTVjMC05NWM1MzY3NjJkOTAvIiwiaWF0IjoxNjA3MzU2NDk1LCJuYmYiOjE2MDczNTY0OTUsImV4cCI6MTYwNzM2MDM5NSwiYWNjdCI6MCwiYWNyIjoiMSIsImFjcnMiOlsidXJuOnVzZXI6cmVnaXN0ZXJzZWN1cml0eWluZm8iLCJ1cm46bWljcm9zb2Z0OnJlcTEiLCJ1cm46bWljcm9zb2Z0OnJlcTIiLCJ1cm46bWljcm9zb2Z0OnJlcTMiLCJjMSIsImMyIiwiYzMiLCJjNCIsImM1IiwiYzYiLCJjNyIsImM4IiwiYzkiLCJjMTAiLCJjMTEiLCJjMTIiLCJjMTMiLCJjMTQiLCJjMTUiLCJjMTYiLCJjMTciLCJjMTgiLCJjMTkiLCJjMjAiLCJjMjEiLCJjMjIiLCJjMjMiLCJjMjQiLCJjMjUiXSwiYWlvIjoiQVNRQTIvOFJBQUFBdUUvM3BaZjlXbE8ySWlaVkJlbzBURDFXK2VWR3o1RHN1YWNYRHF5VTU3WT0iLCJhbXIiOlsicHdkIl0sImFwcF9kaXNwbGF5bmFtZSI6ImFjY2VzcyBsZWVzIGZvbGRlciIsImFwcGlkIjoiOTkzNjQzNzktNDVhMC00ZGZhLTlkOTQtZDlhNDEwNTJjZDFjIiwiYXBwaWRhY3IiOiIwIiwiZmFtaWx5X25hbWUiOiJHcmFoYW0iLCJnaXZlbl9uYW1lIjoiTWlyaWFtIiwiaWR0eXAiOiJ1c2VyIiwiaXBhZGRyIjoiMjE2Ljk5LjE4MC4xNjMiLCJuYW1lIjoiTWlyaWFtIEdyYWhhbSIsIm9pZCI6IjZjODJiY2E3LTE5NjAtNGM1MS1iNjFjLWE3NDg3MTYyM2Y5ZiIsInBsYXRmIjoiMTQiLCJwdWlkIjoiMTAwMzIwMDBGMTZFRkNCRSIsInJoIjoiMC5BQUFBS1QyNWZOMHRRRW1sd0pYRk5uWXRrSGxETnBtZ1JmcE5uWlRacEJCU3pSeDFBTzAuIiwic2NwIjoiRmlsZXMuUmVhZFdyaXRlIG9wZW5pZCBwcm9maWxlIFJvbGVNYW5hZ2VtZW50LlJlYWQuQWxsIFJvbGVNYW5hZ2VtZW50LlJlYWQuRGlyZWN0b3J5IFVzZXIuUmVhZCBlbWFpbCIsInN1YiI6Im1MdTA4WFczc0RmNlF1c0lxZmVtRjViUUdySDlGYkRzQ0JLZ2w1RnljcXMiLCJ0ZW5hbnRfcmVnaW9uX3Njb3BlIjoiTkEiLCJ0aWQiOiI3Y2I5M2QyOS0yZGRkLTQ5NDAtYTVjMC05NWM1MzY3NjJkOTAiLCJ1bmlxdWVfbmFtZSI6Ik1pcmlhbUdAdDg3N3NyZi5vbm1pY3Jvc29mdC5jb20iLCJ1cG4iOiJNaXJpYW1HQHQ4NzdzcmYub25taWNyb3NvZnQuY29tIiwidXRpIjoiR3U5V2FfalRORXFHSUJrdS0xaTlBQSIsInZlciI6IjEuMCIsIndpZHMiOlsiYjc5ZmJmNGQtM2VmOS00Njg5LTgxNDMtNzZiMTk0ZTg1NTA5Il0sInhtc19zdCI6eyJzdWIiOiJDQTFnQkttVU9nLVplc3otMEFmOWF1VVFHOHY0a283MlNoVGp1eEFlSjFNIn0sInhtc190Y2R0IjoxNjAzNzI3NjA4fQ.x5xY4qWUKQdYNOwlj0GWP0f8ICT10ojCQ1CKUoffDYm2W5FGKUMOZPx11dhZv6W2ye1Tm0v3Yd6lMm9nWOkXf5LhILLmLptX1SCA7K0fQ-ttgZRhFrtPf3_sEycaTDMTSIS4WtoDlQ1Z3kjv17F0N56cxWnmZli9YFPJCD54YZZingBzfZI4pd96XvuE9aVaZiB1P92kg7veMIjYczgvDgMijtTSnVgzzF06Uip0eRG5oQhnmz1VwLG2djJFPeu6Xm2zvsIF4-FTxDzEmjq-JQVo2GupAUVxVtUyZyrEsGupu763gpEfOvkgusKPnByZdPXGA1cPksosAA0fe4kbnA
Accept: */*
SdkVersion: graph-java-core/v1.0.5 (featureUsage=0) java/1.8.0_131
client-request-id: edea4a1e-b722-4980-a688-ce1699af69bd
Content-Type: application/json
Content-Length: 11
Host: graph.microsoft.com
Connection: Keep-Alive
Accept-Encoding: gzip
User-Agent: okhttp/4.10.0-RC1
Failing Response (ROPC):
HTTP/1.1 403 Forbidden
Cache-Control: private
Content-Type: application/json
request-id: f00286fd-5ae6-488e-afd6-475ae7846906
client-request-id: edea4a1e-b722-4980-a688-ce1699af69bd
x-ms-ags-diagnostic: {"ServerInfo":{"DataCenter":"North Central US","Slice":"SliceC","Ring":"2","ScaleUnit":"000","RoleInstance":"AGSFE_IN_71"}}
Strict-Transport-Security: max-age=31536000
Date: Mon, 07 Dec 2020 15:59:59 GMT
Content-Length: 279
Successful Request (client_credentials)
POST /v1.0/sites/92a99e5f-bb3e-4588-9461-d640b59d52e2/drives/b!X56pkj67iEWUYdZAtZ1S4hDhiQyamFVEj8y19ROdYOKYReOmD1sXSoDAvyFjD733/root:/Miriams%20Folder/FMW%20Management%20EM12c.pptx:/microsoft.graph.createUploadSession HTTP/1.1
SdkVersion: graph-java/v2.4.1
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJub25jZSI6Imp0M3ZlaW5pVkZPZTc1R0I5RG40Uk0ydEJlWTRkUEZOYTFiaDQwR1RFMmMiLCJhbGciOiJSUzI1NiIsIng1dCI6ImtnMkxZczJUMENUaklmajRydDZKSXluZW4zOCIsImtpZCI6ImtnMkxZczJUMENUaklmajRydDZKSXluZW4zOCJ9.eyJhdWQiOiJodHRwczovL2dyYXBoLm1pY3Jvc29mdC5jb20iLCJpc3MiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC83Y2I5M2QyOS0yZGRkLTQ5NDAtYTVjMC05NWM1MzY3NjJkOTAvIiwiaWF0IjoxNjA3MzcyMDQxLCJuYmYiOjE2MDczNzIwNDEsImV4cCI6MTYwNzM3NTk0MSwiYWlvIjoiRTJSZ1lIZ2hFR1ZwODBpdXhmcFl2V3ZYa1Y4YUFBPT0iLCJhcHBfZGlzcGxheW5hbWUiOiJhY2Nlc3MgbGVlcyBmb2xkZXIiLCJhcHBpZCI6Ijk5MzY0Mzc5LTQ1YTAtNGRmYS05ZDk0LWQ5YTQxMDUyY2QxYyIsImFwcGlkYWNyIjoiMSIsImlkcCI6Imh0dHBzOi8vc3RzLndpbmRvd3MubmV0LzdjYjkzZDI5LTJkZGQtNDk0MC1hNWMwLTk1YzUzNjc2MmQ5MC8iLCJpZHR5cCI6ImFwcCIsIm9pZCI6IjllNWIzYzM1LWNjYzAtNDk5Zi04NjExLTA2Yjc2MmM0NzNlYiIsInJoIjoiMC5BQUFBS1QyNWZOMHRRRW1sd0pYRk5uWXRrSGxETnBtZ1JmcE5uWlRacEJCU3pSeDFBQUEuIiwicm9sZXMiOlsiU2l0ZXMuUmVhZFdyaXRlLkFsbCIsIkZpbGVzLlJlYWRXcml0ZS5BbGwiLCJVc2VyLlJlYWQuQWxsIl0sInN1YiI6IjllNWIzYzM1LWNjYzAtNDk5Zi04NjExLTA2Yjc2MmM0NzNlYiIsInRlbmFudF9yZWdpb25fc2NvcGUiOiJOQSIsInRpZCI6IjdjYjkzZDI5LTJkZGQtNDk0MC1hNWMwLTk1YzUzNjc2MmQ5MCIsInV0aSI6Ilg3aTdIa1N3VGttal9jMW5zbWNYQUEiLCJ2ZXIiOiIxLjAiLCJ4bXNfdGNkdCI6MTYwMzcyNzYwOH0.AIj32kpkwVZiU6OM038yb4m7KQkQZ65PYSYGgS0M_ONhymtxhq7c1XAY-oTTw6jSyApb7d8lI37er-Qi9f47KXvhfEZlrpG0lX4ZOBcuqbPQagOTETT6Tn6FI5LKtIRm7SP2rICNUNzLuXip5D3_3i4Oil0AENQfu4eLjXr6YA5yIfjp4JUx_Ylh8eV9B0QM-na2BZLdrI3RfM0SY2ifFArxcWKQoaNUDinHYE952Wb5-SdgiX16Bi5-dN6LJiIhu4kScn3pHVbbpunBbk7aDTaPaqFeO7uuLycPIIkbu7vStTVX0mmRUXeg2wL6bU9tWo5YT5X93hi7oMYpoyQkNg
Accept: */*
SdkVersion: graph-java-core/v1.0.5 (featureUsage=0) java/1.8.0_131
client-request-id: 147bd003-d380-49ec-aa5a-6f18adef0021
Content-Type: application/json
Content-Length: 11
Host: graph.microsoft.com
Connection: Keep-Alive
Accept-Encoding: gzip
User-Agent: okhttp/4.10.0-RC1
Successful Response (client_credentials)
HTTP/1.1 200 OK
Cache-Control: private
Content-Type: application/json;odata.metadata=minimal;odata.streaming=true;IEEE754Compatible=false;charset=utf-8
Location: https://graph.microsoft.com
Vary: Accept-Encoding
request-id: bc409fcf-f957-4477-8e02-05d06f4724f1
client-request-id: 147bd003-d380-49ec-aa5a-6f18adef0021
x-ms-ags-diagnostic: {"ServerInfo":{"DataCenter":"North Central US","Slice":"SliceC","Ring":"3","ScaleUnit":"002","RoleInstance":"AGSFE_IN_12"}}
OData-Version: 4.0
Strict-Transport-Security: max-age=31536000
Date: Mon, 07 Dec 2020 20:19:04 GMT
Content-Length: 1473
FOR SUCCESSFUL RUN, this is followed by
CONNECT t877srf.sharepoint.com:443 HTTP/1.1
Host: t877srf.sharepoint.com:443
Connection: Keep-Alive
User-Agent: okhttp/4.10.0-RC1
Plus all the chunking
Issue encountered was due to the simple fact that the folder we are uploading to is not the root folder. For root Folder, Files.ReadWrite is sufficient; for other folders the permission Files.ReadWrite.All is required.

IBM Cloud GitLab + Slack Integration: HTTP Status 400 missing_text_or_fallback_or_attachments

I am trying to connect my GitLab repository from IBM Cloud to our slack channel. I get a http status error code 400: missing_text_or_fallback_or_attachments
My response header looks like this
Content-Type: text/html
Transfer-Encoding: chunked
Connection: close
Date: Wed, 20 Feb 2019 09:14:21 GMT
Server: Apache
Vary: Accept-Encoding
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Referrer-Policy: no-referrer
X-Frame-Options: SAMEORIGIN
Access-Control-Allow-Origin: *
X-Via: haproxy-www-v06s
X-Cache: Error from cloudfront
Via: 1.1 fb8e6daa39bc4124e46750734008822c.cloudfront.net (CloudFront)
X-Amz-Cf-Id: Mv3PJD_D63jNuvA4YldBtHcMNGP-1fofXQ-BxgOmBy7eqPgkjpfOKg==
The integration settings looks like this
Are you creating a new webhook in GitLab or using the Slack Notifications integration? Only Slack Notifications are supported, some people had similar issues here: https://gitlab.com/gitlab-org/gitlab-ce/issues/41853#note_66355191

Page exists, google bot returning 404 error

I have website which is online. When I'am using it via browser everything is ok and this page is present in browser. When I'm using it as googlebot ( via webmastertools ) i'm getting error
HTTP/1.1 404 Not Found
Date: Mon, 19 Nov 2012 09:57:37 GMT
Server: Apache
X-Powered-By: PHP/5.2.17
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: symfony=55240a0a341202d07fc96cbc1c1bcca5; path=/
Keep-Alive: timeout=2, max=200
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8
and rest of the html code...
same thing when I'm trying to validate it via wc3 validator.
Please help :( I tryied everything :(
website address is mojaczestochowa.pl
If more info is needed please let me know.
Try to check the pae with web-sniffer and set user agent to google.bot
Here is the exact query, which will simulate server's response to the GoogleBot crawler:
https://websniffer.cc/?url=http://mojaczestochowa.pl/&uak=9

Foursquare venue photos API only occasionally working with client_id/client_secret?

I've found that some venues will only return photos if I use a signed in user instead of a client_id / client_secret. Is this intentional?
curl -i https://api.foursquare.com/v2/venues/4c36476d93db0f47f6cc1d92/photos?client_id=xxx\&client_secret=xxx\&group=venue\&v=20120304
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Cache-Control: no-cache, private, no-store
Content-Type: application/json; charset=utf-8
Date: Mon, 05 Mar 2012 00:28:34 GMT
Expires: Mon, 5 Mar 2012 00:28:34 GMT
Pragma: no-cache
Server: nginx/0.8.52
X-RateLimit-Limit: 5000
X-RateLimit-Remaining: 4999
Content-Length: 66
Connection: keep-alive
{"meta":{"code":200},"response":{"photos":{"count":0,"items":[]}}}
curl -i https://api.foursquare.com/v2/venues/4c36476d93db0f47f6cc1d92/photos?group=venue\&v=20120304\&oauth_token=xxx\&v=20120304
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Cache-Control: no-cache, private, no-store
Content-Type: application/json; charset=utf-8
Date: Mon, 05 Mar 2012 00:29:19 GMT
Expires: Mon, 5 Mar 2012 00:29:19 GMT
Pragma: no-cache
Server: nginx/0.8.52
X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 1000
Content-Length: 15311
Connection: keep-alive
{"meta":{"code":200},"notifications":[{"type":"notificationTray","item":{"unreadCount":0}}],"response":{"photos":{"count":14,"items":[lots of images here]}}}
I want to fetch a photo to associate with a given place as a background process, not tied to the specific user. Is it intended that this API only functions correctly for signed in users?
Looks like there's a bug in userless access to /venues/photos. The team is investigating. The intended behavior is that userless access of that endpoint returns all public photos attached to that venue.

Resources