oauth2.0 invalid request when trying to use refresh token - oauth2-playground

Used google oauth2 playground: https://developers.google.com/oauthplayground/
Followed: https://developers.google.com/accounts/docs/OAuth2WebServer#offline
Anyone why I am getting invalid request?
POST /o/oauth2/token HTTP/1.1
Host: accounts.google.com
Content-length: 209
Content-type: application/x-www-form-urlencoded
Authorization: OAuth ya29.XXXXXXXX
client_id=XXXXXXXXX&
client_secret=XXXXXXXXX&
refresh_token=1/0ffkj5lggn8XXXXXXXXX&
grant_type=refresh_token
HTTP/1.1 400 Bad Request
Content-length: 33
X-xss-protection: 1; mode=block
X-content-type-options: nosniff
X-google-cache-control: remote-fetch
-content-encoding: gzip
Server: GSE
Reason: Bad Request
Via: HTTP/1.1 GWA
Pragma: no-cache
Cache-control: no-cache, no-store, max-age=0, must-revalidate
Date: Thu, 11 Oct 2012 21:29:55 GMT
X-frame-options: SAMEORIGIN
Content-type: application/json
Expires: Fri, 01 Jan 1990 00:00:00 GMT
{
"error" : "invalid_request"
}

If you're getting 400 is because you are adding an invalid parameter or missing one.
edit:
i believe from the given data there is an extra header Authorization. This is used in oauth2 only when access_token is passed in header, to make authenticated calls
Authorization : Bearer XXXXXXXXXXXXXXXX
while refreshing access_token there is no need to provide the same in header.
https://developers.google.com/accounts/docs/OAuth2InstalledApp#refresh

Related

Add Access-Control header to Google Domain 301 redirect

I'm trying to add the following header to my 301 redirect from https://id.danielbakas.com to https://pod.danielbakas.com:
Access-Control-Allow-Origin: *
My 301 redirect was setup using Google Domain's "Website Redirect", but I can't seem to find any documentation about adding headers to the redirect.
If you were to curl the origin URL you would find that the Access-Control-Allow-Origin header is missing:
curl --head https://id.danielbakas.com
HTTP/2 301
location: https://pod.danielbakas.com/profile/card
date: Wed, 14 Dec 2022 17:36:39 GMT
content-type: text/html; charset=UTF-8
server: ghs
content-length: 237
x-xss-protection: 0
x-frame-options: SAMEORIGIN
However, if you were to curl the destination URL, you would find that the header is indeed present:
curl --head https://pod.danielbakas.com/profile/card
HTTP/1.1 200 OK
Vary: Accept,Authorization,Origin
X-Powered-By: Community Solid Server
Updates-Via: wss://pod.danielbakas.com/
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Access-Control-Expose-Headers: Accept-Patch,Accept-Post,Accept-Put,Allow,ETag,Last-Modified,Link,Location,Updates-Via,WAC-Allow
Allow: OPTIONS, HEAD, GET, PATCH, PUT, DELETE
Accept-Patch: text/n3, application/sparql-update
Accept-Put: */*
Content-Type: text/turtle
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Link: <https://pod.danielbakas.com/profile/card.meta>; rel="describedby"
Link: <https://pod.danielbakas.com/profile/card.acl>; rel="acl"
Last-Modified: Mon, 12 Dec 2022 20:21:11 GMT
ETag: "1670876471000"
WAC-Allow: user="read",public="read"
Date: Wed, 14 Dec 2022 17:38:07 GMT
Connection: keep-alive
Keep-Alive: timeout=5
How could I configure this redirect so that this header is present in the origin URL?
Thank you so much!

How to get 103 Early Hints work in Traefik?

I am using traefik in kubernetes and I have a service deployed that is returning 103 Early Hint. I can confirm that it is working by directly querying the service, e.g.
curl -D - http://contra-web-app
HTTP/1.1 103 Early Hints
Link: <https://builds.contra.com>; rel="preconnect"; crossorigin
Link: <https://fonts.googleapis.com/css2?family=Inter:wght#400;500;600;700;900&display=swap>; rel="preload"; as="font"
Link: <https://builds.contra.com/3f509d0cc/assets/entry-client-routing.4f895d55.js>; rel="modulepreload"; as="script"; crossorigin
Link: <https://www.googletagmanager.com/gtag/js?id=G-96H5NXQ2PR>; rel="preload"; as="script"
HTTP/1.1 200 OK
cache-control: no-store
referrer-policy: strict-origin-when-cross-origin
x-frame-options: sameorigin
content-type: text/html
content-length: 9062
Date: Tue, 26 Jul 2022 20:34:19 GMT
Connection: keep-alive
Keep-Alive: timeout=72
However, requesting the same service through Traefik just returns 200 response:
curl -H 'host: contra.com' -D - http://contra-traefik.traefik/gajus
HTTP/1.1 200 OK
Cache-Control: no-store
Content-Length: 11441
Content-Type: text/html
Date: Tue, 26 Jul 2022 19:51:48 GMT
Referrer-Policy: strict-origin-when-cross-origin
Set-Cookie: contra_web_app_service=394e7e912ad85b66; Path=/; Secure
Vary: Accept-Encoding
X-Frame-Options: sameorigi
At this point, I am unable to establish whether I am missing a configuration or if Traefik does not support it.

Getting a 401 status error whilst establishing a connection to Concourse API

At the moment, we are trying to get CI working in our labs..
we have just followed the instructions on the concourse website.
We are able to login properly and have setup ~/.flyrc as recomended ion the concourse-ci.org and concoursetutorial.com websites.
We have noticed that most commands are returning with a 401 Unauthorized error.
We have gone ahead setup the audit logs https://concourse-ci.org/concourse-web.html#audit-logs
But it isn't clear where this writes to, help?
It is difficult at the moment to properly trace this. BTW this is our first exposure to concourse.
We would like to know why? and what we can do resolve this (to cross this huddle).
fly -t rdb-ci set-team --team-name a-team --local-user admin --github-org organization --verbose --print-table-headers --non-interactive
2019/07/10 22:02:37 GET /api/v1/info HTTP/1.1
Host: ci.example.org
User-Agent: Go-http-client/1.1
Accept-Encoding: gzip
2019/07/10 22:02:37 HTTP/1.1 200 OK
Content-Length: 88
Connection: keep-alive
Content-Type: application/json
Date: Wed, 10 Jul 2019 21:02:37 GMT
Server: nginx/1.12.2
X-Concourse-Version: 5.3.0
X-Content-Type-Options: nosniff
X-Download-Options: noopen
X-Frame-Options: deny
X-Xss-Protection: 1; mode=block
{"version":"5.3.0","worker_version":"2.1","external_url":"https://ci.example.org"}
setting team: a-team
role owner:
users:
- local:admin
groups:
- github:organization
apply team configuration? [yN]: y
2019/07/10 22:02:53 PUT /api/v1/teams/a-team HTTP/1.1
Host: ci.example.org
User-Agent: Go-http-client/1.1
Content-Length: 71
Content-Type: application/json
Accept-Encoding: gzip
{"auth":{"owner":{"groups":["github:organization"],"users":["local:admin"]}}}
2019/07/10 22:02:53 HTTP/1.1 401 Unauthorized
Content-Length: 14
Connection: keep-alive
Content-Type: text/plain; charset=utf-8
Date: Wed, 10 Jul 2019 21:02:53 GMT
Server: nginx/1.12.2
X-Concourse-Version: 5.3.0
X-Content-Type-Options: nosniff
X-Download-Options: noopen
X-Frame-Options: deny
X-Xss-Protection: 1; mode=block
not authorized
could not find a valid token.
logging in to team 'main'
2019/07/10 22:02:53 GET /api/v1/info HTTP/1.1
Host: ci.example.org
User-Agent: Go-http-client/1.1
Accept-Encoding: gzip
could not reach the Concourse server called rdb-ci:
Get https://ci.example.org/api/v1/info: x509: certificate is valid for www.example.org, not ci.example.org
is the targeted Concourse running? better go catch it lol

Facebook share throwing connection error when sharing

Every article on the following website fails when attempting to share the page via the share link in our social media widget.
for example:
the following page, http://news.gc.ca/web/article-en.do?mthd=index&crtr.page=1&nid=957389 when shared via the following link:
Returns an Error: Connection error in the share preview window. Response headers for this request are:
Cache-Control: private, no-cache, no-store, must-revalidate
Content-Encoding: gzip
Content-Type: text/html
Date: Wed, 01 Apr 2015 14:22:20 GMT
Expires: Sat, 01 Jan 2000 00:00:00 GMT
Pragma: no-cache
Strict-Transport-Security: max-age=15552000; preload
Vary: Accept-Encoding
X-Content-Type-Options: nosniff
X-FB-Debug: iYvCJSRJJqVdVXyIubD1kVq6teZBILIBRrCACZW9hI/Ms+B2qsquq52KyU5820UTfLmuXTis3LbRoL2bMlCVBw==
X-Frame-Options: DENY
X-XSS-Protection: 0
X-Firefox-Spdy: 3.1
200 OK
running the above URL through the OpenGraph object debugger returns:
Error parsing input URL, no data was cached, or no data was scraped.
and the scraper sees the following for the URL:
Document returned no data
We need to determine the cause of this since none of our content can be shared from our site at the moment.
Any ideas, tips greatly appreciated!

Why does Github API only returns the first 100 watched repositories?

I'm watching 392 repositories on Github. However, the Github API only returns 100. Does anyone have any idea why?
https://github.com/api/v2/json/repos/watched/trivektor
You need to paginate manually using the page parameter. The HTTP Response headers will tell you the next and the last page, if available. Check the headers:
X-Next
X-Last
Examples:
curl -D- https://github.com/api/v2/json/repos/watched/trivektor
HTTP/1.1 200 OK
Server: nginx/1.0.4
Date: Sat, 22 Oct 2011 08:24:45 GMT
Content-Type: application/json; charset=utf-8
Connection: keep-alive
Status: 200 OK
X-RateLimit-Limit: 60
ETag: "c597e396e9f17b91c5c5a7e462ba954f"
X-Next: https://github.com/api/v2/json/repos/watched/trivektor?page=2
X-Last: https://github.com/api/v2/json/repos/watched/trivektor?page=5
Now the 2nd page:
curl -D- https://github.com/api/v2/json/repos/watched/trivektor?page=2
HTTP/1.1 200 OK
Server: nginx/1.0.4
Date: Sat, 22 Oct 2011 08:28:08 GMT
Content-Type: application/json; charset=utf-8
Connection: keep-alive
Status: 200 OK
X-RateLimit-Limit: 60
ETag: "c57d0e97e2062672cb3771467cf2abc7"
X-Next: https://github.com/api/v2/json/repos/watched/trivektor?page=3
X-Last: https://github.com/api/v2/json/repos/watched/trivektor?page=5
X-Frame-Options: deny
X-RateLimit-Remaining: 58
X-Runtime: 353ms
Content-Length: 44966
Cache-Control: private, max-age=0, must-revalidate
And the last one:
curl -D- https://github.com/api/v2/json/repos/watched/trivektor?page=5
HTTP/1.1 200 OK
Server: nginx/1.0.4
Date: Sat, 22 Oct 2011 08:28:30 GMT
Content-Type: application/json; charset=utf-8
Connection: keep-alive
Status: 200 OK
X-RateLimit-Limit: 60
ETag: "11ce44ebc229eab0dc31731b39e10dcf"
X-Frame-Options: deny
X-RateLimit-Remaining: 57
X-Runtime: 93ms
Content-Length: 7056
Cache-Control: private, max-age=0, must-revalidate
Very common for API's to limit the size of a response object to protect against outliers. Given that it's returning a round number, that suggests this is by design. I don't see them discussing paging in their docs, so it might just be a hard cap. Either way, you should just ping github.