Insufficient scope when attempting to get Docker Hub catalog - docker

I'm attempting to get a catalog listing for Docker hub, but so far I'm just getting an error in response. My understanding is I'd need to pass a bearer token with the catalog request, so I start by getting that token with the related scope:
curl -u "username:password "https://auth.docker.io/token?service=registry.docker.io&scope=registry:catalog:*"
(this is using username/password from my Docker Hub account)
I then pass the returned token to the registry:
curl -vL -H "Authorization: Bearer eyJhbGciOiJFUzI1NiIsInR5cCI6I(...)" https://registry-1.docker.io/v2/_catalog
In response to that request, I'm getting:
* Trying 54.86.130.73...
* Connected to registry-1.docker.io (54.86.130.73) port 443 (#0)
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate: *.docker.io
* Server certificate: RapidSSL SHA256 CA - G3
* Server certificate: GeoTrust Global CA
> GET /v2/_catalog HTTP/1.1
> Host: registry-1.docker.io
> User-Agent: curl/7.43.0
> Accept: */*
> Authorization: Bearer eyJhbGciOiJFUzI1NiIsInR5cCI6I(...)
>
< HTTP/1.1 401 Unauthorized
HTTP/1.1 401 Unauthorized
< Content-Type: application/json; charset=utf-8
Content-Type: application/json; charset=utf-8
< Docker-Distribution-Api-Version: registry/2.0
Docker-Distribution-Api-Version: registry/2.0
< Www-Authenticate: Bearer realm="https://auth.docker.io/token",service="registry.docker.io",scope="registry:catalog:*",error="insufficient_scope"
Www-Authenticate: Bearer realm="https://auth.docker.io/token",service="registry.docker.io",scope="registry:catalog:*",error="insufficient_scope"
< Date: Fri, 06 May 2016 23:00:08 GMT
Date: Fri, 06 May 2016 23:00:08 GMT
< Content-Length: 134
Content-Length: 134
< Strict-Transport-Security: max-age=31536000
Strict-Transport-Security: max-age=31536000
<
{"errors":[{"code":"UNAUTHORIZED","message":"authentication required","detail":[{"Type":"registry","Name":"catalog","Action":"*"}]}]}
...which seems to be asking me to go back and get authorized with the URL I entered above.
Should this be possible? If so, what am I missing?

I got the same problem, raised this with docker support and got the following answer,
"The catalog endpoint does not work against Docker Hub because that endpoint actually lists all the repositories on a Registry, and we disabled it as it would list all repositories on Docker Hub."

If you want repository information for a username or organization, an alternative is to use V1 api. The problem with this is you need to make multiple calls based on the number of repos available.
The following command will give the repos available for a given username :
curl -k -H "Authorization: Basic <encripted username:password>" -H "Accept: application/json" -X GET "https://index.docker.io/v1/search?q=<username>&n=100"
Here q is the query and n is the number of items to be returned in each page.
Another call can be made based on what data you need by passing repo as a parameter.

Related

Kong: kong-spec-expose plugin cannot load the documentation(302 permanently moved)

I have hard times configuring this kong-spec-expose plugin.It is supposed to automatically configure the routes with Swagger. After some time I managed to configure it but when i try to access the documentation of a certain route it is always giving me the 302 permanently moved.So i tested it with curl and here I will leave a link for the kong plugin and a screenshot of the request..
https://docs.konghq.com/hub/optum/kong-spec-expose/
* Trying 127.0.0.1:8000...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 8000 (#0)
> GET /api/employee-controller/profile/user/12/base/specz HTTP/1.1
> Host: localhost:8000
> User-Agent: curl/7.68.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 302 Moved Temporarily
< Date: Wed, 11 Jan 2023 09:50:38 GMT
< Content-Type: text/html; charset=utf-8
< Transfer-Encoding: chunked
< Connection: keep-alive
< X-Kong-Response-Latency: 409
< Server: kong/2.8.1
Actually I tried configuring the plugin on multiple routes then on service level but nothing seems to work out.. then tried to analyse where this request is redirected but with no results.

Postman using wrong (nonsense?) code in OAuth2 flow against Keycloak server

I'm attempting to use Postman (Version 7.20.0 - linux 5.5.8-200.fc31.x86_64 / x64)to authenticate using the OAuth2.0 "Authorization Code" flow against a Keycloak 9.0.0 server, backed by Google as an IdP.
Postman is sending the following to the .../token endpoint when trying to exchange the code for the access/refresh tokens:
grant_type: authorization_code
code: 4/xgFPM8rkZXA1pWguPMHPKg8GS3BrI7whtmSq2U2K4_4Cy62m10y2l3IQp3KuiLRyaLaZWKCUiGJGEWVJ9K4zcTc
redirect_uri: http://localhost:3002
client_id: mission-control
client_secret: 3cc09c80-••••-••••-••••-••••••••
This fails in Keycloak with the following error, confirmed in the Postman console:
POST /auth/realms/test-realm/protocol/openid-connect/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded
User-Agent: PostmanRuntime/7.23.0
Accept: */*
Cache-Control: no-cache
Postman-Token: f2cfc8be-a911-4bc6-b5be-dbfab46d3a56
Host: localhost:8080
Accept-Encoding: gzip, deflate, br
Content-Length: 246
Connection: keep-alive
grant_type=authorization_code&code=4%2FxgFPM8rkZXA1pWguPMHPKg8GS3BrI7whtmSq2U2K4_4Cy62m10y2l3IQp3KuiLRyaLaZWKCUiGJGEWVJ9K4zcTc&redirect_uri=http%3A%2F%2Flocalhost%3A3002&client_id=mission-control&client_secret=3cc09c80-••••-••••-••••-••••••••
HTTP/1.1 400
Connection: keep-alive
Cache-Control: no-store
Pragma: no-cache
Content-Type: application/json
Content-Length: 62
Date: Fri, 13 Mar 2020 08:36:02 GMT
{"error":"invalid_grant","error_description":"Code not valid"}
Keycloak logs show that this token has the wrong format:
keycloak_1 | 09:53:23,219 WARN [org.keycloak.protocol.oidc.utils.OAuth2CodeParser] (default task-35) Invalid format of the code
keycloak_1 | 09:53:23,219 WARN [org.keycloak.events] (default task-35) type=CODE_TO_TOKEN_ERROR, realmId=Test Realm, clientId=mission-control, userId=null, ipAddress=172.20.0.1, error=invalid_code, grant_type=authorization_code, client_auth_method=client-secret
To check whether Keycloak, or Postman was at fault I walked through the same steps on the CLI with the help of Netcat:
On the CLI, with help of netcat I can walk through the flow successfully, and I see a different token format:
Start a netcat server to catch the callback from the browser window: $ nc -lk localhost 3002
Open this in my browser http://localhost:8080/auth/realms/test-realm/protocol/openid-connect/auth?client_id=mission-control&redirect_uri=http%3A%2F%2Flocalhost%3A3002&response_type=code&scope=openid
Click through the login flow with Google as the provider.
The netcat server will receive something like this GET /?code=3b9ac786-f9d1-40f9-b884-35e17b2fa756.70a3be09-8edf-47ed-9803-d08550a07faa.8794bba2-6f2b-4512-8bd7-6d5073852d1c (and more)
I can exchange this code for tokens successfully: curl -XPOST -H "Content-Type: application/x-www-form-urlencoded" -d "grant_type=authorization_code&code=3b9ac786-f9d1-40f9-b884-35e17b2fa756.70a3be09-8edf-47ed-9803-d08550a07faa.8794bba2-6f2b-4512-8bd7-6d5073852d1c&redirect_uri=http%3A%2F%2Flocalhost%3A3002&client_id=mission-control&client_secret=3cc09c80-48bc-46fd-bc91-232e6bbb681a" http://localhost:8080/auth/realms/test-realm/protocol/openid-connect/token
I don't know where the Postman OAuth flow is getting the "code" out of the response body, which it uses to send to the token exchange endpoint The difference in the tokens is clear, when walking through it by hand (same client, same token, same oauth2 server) then the code loosk like:
3b9ac786-f9d1-40f9-b884-35e17b2fa756.70a3be09-8edf-47ed-9803-d08550a07faa.8794bba2-6f2b-4512-8bd7-6d5073852d1c
When using Postman, it's sending this as the code:
4/xgFPM8rkZXA1pWguPMHPKg8GS3BrI7whtmSq2U2K4_4Cy62m10y2l3IQp3KuiLRyaLaZWKCUiGJGEWVJ9K4zcTc
What can I do to make postman take the callback ?code form the URL?
This is a confirmed bug in Postman when both the callback_uri and the token OAuth server endpoints are on the same (localhost) domain.
https://github.com/postmanlabs/postman-app-support/issues/7105
Update: This issue was fixed in September 2020.

Cannot make get request after acquiring Bearer token - 401 error "insufficient scope"

I have the following requests to get a bearer token from the Docker Hub API and then use that token for a GET request to the given endpoint:
#!/usr/bin/env bash
raw_token="$(curl https://auth.docker.io/token?service=registry.docker.io&scope=repository:library/ubuntu:list)";
token="$(node -pe "JSON.parse('$raw_token').token")"
curl -i -H "Authorization: Bearer $token" https://registry-1.docker.io/v2/library/ubuntu/tags/list
If I run that, I get this error:
HTTP/1.1 401 Unauthorized
Content-Type: application/json; charset=utf-8
Docker-Distribution-Api-Version: registry/2.0
Www-Authenticate: Bearer realm="https://auth.docker.io/token",service="registry.docker.io",scope="repository:library/ubuntu:pull",error="insufficient_scope"
Date: Wed, 20 Jun 2018 08:02:24 GMT
Content-Length: 157
Strict-Transport-Security: max-age=31536000
{"errors":[{"code":"UNAUTHORIZED","message":"authentication required","detail":[{"Type":"repository","Class":"","Name":"library/ubuntu","Action":"pull"}]}]}
Does anyone know how I can make the right request, and get the right token?
When you get token, you specify scope=repository:library/ubuntu:list. When you use token, it says you need scope="repository:library/ubuntu:pull".

iOS payload, but nothing to deliver to (missing device_tokens, tags, segments, or aliases)

I am doing background download for my app but I am getting
iOS payload, but nothing to deliver to (missing device_tokens, tags, segments, or aliases)
when I insert this in terminal:
curl -v -X POST -u "<appKey>:<master key>" -H "Content-type: application/json" -H "Accept:
application/vnd.urbanairship+json; version=3;" --data '{"audience":"all", "device_types" : ["ios"], "notification": {"ios": {"content-available":true, "sound": "default", "badge": 1, "message": "Hi there!", "priority":5}}}' https://go.urbanairship.com/api/push/
I wonder if the curl codes has any format mistakes in it.
Terminal return:
* Hostname was NOT found in DNS cache
* Trying 23.74.208.46...
* Connected to go.urbanairship.com (23.74.208.46) port 443 (#0)
* TLS 1.2 connection using TLS_RSA_WITH_AES_256_CBC_SHA
* Server certificate: *.urbanairship.com
* Server certificate: Cybertrust Public SureServer SV CA
* Server certificate: Baltimore CyberTrust Root
* Server auth using Basic with user '<codes>'
> POST /api/push/ HTTP/1.1
> Authorization: Basic <codes>
> User-Agent: curl/7.37.1
> Host: go.urbanairship.com
> Content-type: application/json
> Accept:
> application/vnd.urbanairship+json; version=3;
> Content-Length: 143
>
* upload completely sent off: 143 out of 143 bytes
< HTTP/1.1 400 Bad Request
* Server gunicorn/0.14.5 is not blacklisted
< Server: gunicorn/0.14.5
< Vary: Authorization, Cookie
< X-Frame-Options: SAMEORIGIN
< Content-Type: text/html; charset=utf-8
< Date: Wed, 19 Nov 2014 02:19:02 GMT
< Transfer-Encoding: chunked
< Connection: close
< Connection: Transfer-Encoding
< Set-Cookie: SRV=s0196; path=/
<
* Closing connection 0
iOS payload, but nothing to deliver to (missing device_tokens, tags, segments, or aliases)
First, you should not post your credentials for all to see. This could allow anyone to send notifications to your app users!
Second, the problem appears to be that within your "ios" section you need to specify your audience by means of device tokens, tags, segments, or aliases. These are mechanisms UA gives you to identify which users should receive the notification.

POST request treated as GET in Heroku environment

I have weird case. I have a RoR app, which provides REST API which I'm connecting to from Java application.
I'm developing RoR locally, and deploying it on Heroku environment.
Regardless how (I tried from Java APP, Mozilla REST client, etc.) I try to send POST HTTP request that should be handled by create action in api controller. On localhost - everything is working as expected. On Heroku production env - the POST request is treated as normal GET.
Here are my routes for this resource:
api_v1_items GET /api/v1/items(.:format) api/v1/items#index {:format=>:json}
POST /api/v1/items(.:format) api/v1/items#create {:format=>:json}
api_v1_item GET /api/v1/items/:id(.:format) api/v1/items#show {:format=>:json}
PATCH /api/v1/items/:id(.:format) api/v1/items#update {:format=>:json}
PUT /api/v1/items/:id(.:format) api/v1/items#update {:format=>:json}
DELETE /api/v1/items/:id(.:format) api/v1/items#destroy {:format=>:json}
So I'm trying to do POST request to /api/v1/items passing all necessary parameters.
In localhost the response is correct:
Started POST "/api/v1/items?token=l4XOHrhDApPqTp1u4TxBjQ" for 127.0.0.1 at 2014-05-15 22:11:49 +0200
Processing by Api::V1::ItemsController#create as JSON
Parameters: {"height"=>10.0, "item_name"=>"Super item", "width"=>20.0, etc...
However the same request fired at Heroku its treated as GET:
2014-05-15T20:27:58.137541+00:00 app[web.1]: Started GET "/api/v1/items?token=iEdDkDLiDUlWi0mDbr6XYw" for 89.74.57.51 at 2014-05-15 20:27:58 +0000
2014-05-15T20:27:58.223620+00:00 app[web.1]: Processing by Api::V1::ItemsController#index as JSON
Any idea? Of course both repos are in sync. Checked few times.
This is really weird... maybe some kind of Heroku cache magic?
HTTP/1.1 301 Moved Permanently
301 redirects are not Heroku magic. Your DNS (or possibly your app) is likely forwarding all apex requests (mydomain.com) to the www subdomain.
Using subdomains is preferred:
Heroku Dev Center: Custom Domains
I experienced a similar error when not using a custom domain just because of an easily overlooked error: I was using heroku.com instead of herokuapp.com
wrong:
http://my-app.heroku.com
right:
http://my-app.herokuapp.com
I suspect it's very similar in cause to the issue mentioned in Catsby's answer.
Well, I tried CURL, and it appeared error is silly.
I was posting at http://mydomain.com, where it's routed as GET.
When I fire at http://www.mydomain.com - it works.
Heroku magic.
Below are curl's and results for your reference. Maybe somebody will be able to explain why it works like this...
POST at mydomain.com
curl -v -H "Accept: application/json" -H "Cont"width":20.0,"item_desc":"The super item","std_pack":40,"sku":"A1004","depth":20.0}}' http://mydomain.com/api/v1/items?token=dSWeyKjjtZu0ZSs6b2J-yw
* Adding handle: conn: 0x7fe70b803000
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x7fe70b803000) send_pipe: 1, recv_pipe: 0
* About to connect() to mydomain.com port 80 (#0)
* Trying 78.46.51.229...
* Connected to mydomain.com (78.46.51.229) port 80 (#0)
> POST /api/v1/items?token=dSWeyKjjtZu0ZSs6b2J-yw HTTP/1.1
> User-Agent: curl/7.30.0
> Host: mydomain.com
> Accept: application/json
> Content-type: application/json
> Content-Length: 174
>
* upload completely sent off: 174 out of 174 bytes
< HTTP/1.1 301 Moved Permanently
< Date: Thu, 15 May 2014 21:20:58 GMT
* Server Apache is not blacklisted
< Server: Apache
< Location: http://www.mydomain.com/api/v1/items?token=dSWeyKjjtZu0ZSs6b2J-yw
< Content-Length: 273
< Content-Type: text/html; charset=iso-8859-1
<
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved here.</p>
</body></html>
* Connection #0 to host mydomain.com left intact
POST at www.mydomain.com
Maciejs-MacBook-Pro:merchbag maciejsimm$ curl -v -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{"item":{"height":10.0,"item_name":"Super duper item","width":20.0,"item_desc":"The super","std_pack":40,"sku":"A1005","depth":20.0}}' http://www.mydomain.com/api/v1/items?token=dSWeyKjjtZu0ZSs6b2J-yw
* Adding handle: conn: 0x7fc191003000
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x7fc191003000) send_pipe: 1, recv_pipe: 0
* About to connect() to www.mydomain.com port 80 (#0)
* Trying 50.17.185.176...
* Connected to www.mydomain.com (50.17.185.176) port 80 (#0)
> POST /api/v1/items?token=dSWeyKjjtZu0ZSs6b2J-yw HTTP/1.1
> User-Agent: curl/7.30.0
> Host: www.mydomain.com
> Accept: application/json
> Content-type: application/json
> Content-Length: 133
>
* upload completely sent off: 133 out of 133 bytes
< HTTP/1.1 201 Created
< Cache-Control: max-age=0, private, must-revalidate
< Content-Type: application/json; charset=utf-8
< Date: Thu, 15 May 2014 21:24:17 GMT
< Etag: "41231ae0f50a604cd7316a014d19b3f2"
* Server WEBrick/1.3.1 (Ruby/2.0.0/2014-05-08) is not blacklisted
< Server: WEBrick/1.3.1 (Ruby/2.0.0/2014-05-08)
< Set-Cookie: request_method=POST; path=/
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< X-Request-Id: ba05dd74-bf52-47d5-b8a9-d0516aff5804
< X-Runtime: 0.020289
< X-Ua-Compatible: chrome=1
< X-Xss-Protection: 1; mode=block
< Content-Length: 234
< Connection: keep-alive
<
* Connection #0 to host www.mydomain.com left intact
{"id":15,"partner_id":1,"sku":"A1005","item_name":"Super duper item","item_desc":"The super","std_pack":40,"height":10,"width":20,"depth":20,"image":null,"created_at":"2014-05-15T21:24:17.753Z","updated_at":"2014-05-15T21:24:17.761Z"}
I had this same issue when sending a POST request to heroku using HTTP instead of HTTPS. Every time heroku routed my POST requests as GET requests. Once I updated the url to use HTTPS, my POST requests were routed by heroku as POSTs and not GETs, resolving the issue. The redirection issues mentioned in the previous posts are likely the root cause of the issue I experienced as well.

Resources