I got two users created by me, admin, with admin permissions, and another user, now with admin permissions too, but initially community (i'll be referring to this account as community).
I've registered an application with the community user and associated the admin later. As callbackUrl i've registered the address below in my keyrock instance
<keystone ip>:/oauth2/token
The request i am making to get oauth2 follows below, it uses https://raw.githubusercontent.com/Bitergia/fiware-chanchan-docker/master/images/pep-wilma/4.3.0/auth-token.sh as a guideline. I've changed the user,pass, host, client id and app secret
curl -s --insecure -i --header "Authorization: Basic NmJjODMyMWMzNDQwNGVlYzkwYzNhNzhlYTU0ZTE2NjY6M2YwMzQyZjE4ZTM1NGI0ZDg5YjhlYWVkNTZmNGI5Mjc=" --header "Content-Type: application/x-www-form-urlencoded" -X POST http://<keyrock IP>/oauth2/token -d 'grant_type=password&username=<user>&password=<pass>&client_id=<clientID>&client_secret=<secret>'
The request reaches the keystone and it replies with a 404 (access token not found).
When i try to get oauth2 tokens from keyrock for both the admin and the community, it says
Error: Root - User access-token not authorized
I can login in horizon with both users.
What did i miss in order to get a oauth2 token from idm?
Edit: Code used to create users:
users_default_pass = '...'
user0 = _register_user(keystone,"user0",passwd=users_default_pass)
keystone.roles.grant(user=user0.id,role=keystone.roles.find(name='community'), project=user0.default_project_id)
Edit2: raw response and response from keystone captured with tcpflow
request:
POST /oauth2/token HTTP/1.1
User-Agent: curl/7.35.0
Host: 130.206.118.xxx:5000
Accept: */*
Authorization: Basic ZWU2YmFjMWNjOTQ3NDdhNmI4MTU3NDdiNDk5NmVhZjQ6NTRkY2NjMjgxODhhNDMxYTk4OTY3MjkwN2UxYjIxYzY=
Content-Type: application/x-www-form-urlencoded
Content-Length: 143
grant_type=password&username=admin&password=admin&client_id=ee6bac1cc94747a6b815747b4996eaf4&client_secret=54dccc28188a431a989672907e1b21c6
write error to stdout
response:
HTTP/1.1 404 Not Found
Vary: X-Auth-Token
Content-Type: application/json
Content-Length: 93
Date: Wed, 09 Sep 2015 09:46:19 GMT
{"error": {"message": "The resource could not be found.", "code": 404, "title": "Not Found"}}
write error to stdout
Took me a while to find it :)
In KeyRock, oauth2 is implemented in Horizon. Looking at your request, I've found couple things:
You are using HTTP instead of HTTPS
Requests are being sent against port 5000 (usually Keystone)
That made me think that your requests are going against Keystone.
By default, KeyRock handles oauth2 requests at Horizon, which means, use https and port 443. As you said, doing requests against Keystone fails:
HTTP/1.1 404 Not Found
Vary: X-Auth-Token
Content-Type: application/json
Content-Length: 93
Date: Wed, 09 Sep 2015 15:36:34 GMT
{"error": {"message": "The resource could not be found.", "code": 404, "title": "Not Found"}}
Make sure you do the request against Horizon with HTTPS and port 443 and everything should work!
Related
I have a Jekyll site published to Github Pages. I am trying to use the Github API to be able to schedule posts.
I can "Get a Github Pages site" with the API, https://docs.github.com/en/rest/pages?apiVersion=2022-11-28#get-a-github-pages-site
When I try to test the Github API for "Request a Github Pages build," it gives me the following error:
curl
-X POST
-H "Accept: application/vnd.github+json"
-H "Authorization: Bearer $Classic_Personal_Access_Token_with_all_permissions_for_testing"
-H "X-GitHub-Api-Version: 2022-11-28"
https://api.github.com/repos/aykchoe/aykchoe.github.io/pages/builds -vv
Trying 192.30.255.116:443...
Connected to api.github.com (192.30.255.116) port 443 (#0)
ALPN: offers h2
ALPN: offers http/1.1
CAfile: /etc/ssl/cert.pem
CApath: none
(304) (OUT), TLS handshake, Client hello (1):
(304) (IN), TLS handshake, Server hello (2):
(304) (IN), TLS handshake, Unknown (8):
(304) (IN), TLS handshake, Certificate (11):
(304) (IN), TLS handshake, CERT verify (15):
(304) (IN), TLS handshake, Finished (20):
(304) (OUT), TLS handshake, Finished (20):
SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256
ALPN: server accepted h2
Server certificate:
subject: C=US; ST=California; L=San Francisco; O=GitHub, Inc.; CN=.github.com
start date: Mar 16 00:00:00 2022 GMT
expire date: Mar 16 23:59:59 2023 GMT
subjectAltName: host "api.github.com" matched cert's ".github.com"
issuer: C=US; O=DigiCert Inc; CN=DigiCert TLS Hybrid ECC SHA384 2020 CA1
SSL certificate verify ok.
Using HTTP2, server supports multiplexing
Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
h2h3 [:method: POST]
h2h3 [:path: /repos/aykchoe/aykchoe.github.io/pages/builds]
h2h3 [:scheme: https]
h2h3 [:authority: api.github.com]
h2h3 [user-agent: curl/7.85.0]
h2h3 [accept: application/vnd.github+json]
h2h3 [authorization: Bearer $Classic_Personal_Access_Token_with_all_permissions_for_testing]
h2h3 [x-github-api-version: 2022-11-28]
Using Stream ID: 1 (easy handle 0x15600d800)
POST /repos/aykchoe/aykchoe.github.io/pages/builds HTTP/2
Host: api.github.com
user-agent: curl/7.85.0
accept: application/vnd.github+json
authorization: Bearer $Classic_Personal_Access_Token_with_all_permissions_for_testing
x-github-api-version: 2022-11-28
HTTP/2 403
server: GitHub.com
date: Sat, 14 Jan 2023 03:49:29 GMT
content-type: application/json; charset=utf-8
content-length: 203
x-oauth-scopes: admin:enterprise, admin:gpg_key, admin:org, admin:org_hook, admin:public_key, admin:repo_hook, admin:ssh_signing_key, audit_log, codespace, delete:packages, delete_repo, gist, notifications, project, repo, user, workflow, write:discussion, write:packages
x-accepted-oauth-scopes:
github-authentication-token-expiration: 2023-02-13 03:44:38 UTC
x-github-media-type: github.v3; format=json
x-github-api-version-selected: 2022-11-28
x-ratelimit-limit: 5000
x-ratelimit-remaining: 4996
x-ratelimit-reset: 1673671506
x-ratelimit-used: 4
x-ratelimit-resource: core
access-control-expose-headers: ETag, Link, Location, Retry-After, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Used, X-RateLimit-Resource, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval, X-GitHub-Media-Type, X-GitHub-SSO, X-GitHub-Request-Id, Deprecation, Sunset
access-control-allow-origin: *
strict-transport-security: max-age=31536000; includeSubdomains; preload
x-frame-options: deny
x-content-type-options: nosniff
x-xss-protection: 0
referrer-policy: origin-when-cross-origin, strict-origin-when-cross-origin
content-security-policy: default-src 'none'
vary: Accept-Encoding, Accept, X-Requested-With
x-github-request-id: C127:4B9A:5325FBA:5629D14:63C22649
{
"message": "The repository does not have a GitHub Pages site. See https://docs.github.com/v3/repos/pages/",
"documentation_url": "https://docs.github.com/rest/pages#request-a-github-pages-build"
}
Connection #0 to host api.github.com left intact
From Googling, it seems like a permissions error (http 403), but not sure what I could be missing.
I tried both fine-grain token and classic.
I noticed my git user was different than the repo owner, so I added it as a collaborator.
I tried switching the git user to the repo owner.
I tried making a new Jekyll repo with Github Pages and running the API code.
After posting json format data to server using curl in windows command prompt(cmd), I'm testing the response data now, got a 'Bad request' message.
I've checked the request format, too.
cmd:
curl -i -X POST -H "Content-Type: application/json" -d '{ "isbn":"123442123, 97885654453443","title":"Learn how to build modern web application with MEAN stack","author": "Didin J.","description":"The comprehensive step by step tutorial on how to build MEAN (MongoDB, Express.js, Angular 5 and Node.js) stack web application from scratch","published_year":"2017","publisher":"Djamware.com" }' localhost:3000/api
And then,
HTTP/1.1 400 Bad Request
X-Powered-By: Express
Content-Type: text/plain; charset=utf-8
Content-Length: 11
ETag: W/"b-EFiDB1U+dmqzx9Mo2UjcZ1SJPO8"
Date: Wed, 05 Sep 2018 01:41:55 GMT
Connection: keep-alive
Bad Request
What's wrong? please help me.
You wrote the title as 'curl issue...', but i think curl has never any issue, because it is very widely used.
And your request data have no fault.
As my experience, problem would be exist in DB connection.
please check and check the accuracy of MongoDB connection.
I'm running ethereum/client-go docker image with the following flags:
docker run -p 8545:8545 ethereum/client-go --rpcapi personal,db,eth,net,web3 --rpc --rpcaddr 0.0.0.0 --rpccorsdomain * --rinkeby
This image is running on machine A and I can query the RPC within it. But when I try to query it from machine B I receive the following response:
Request:
curl -X POST http://<machine_A_address>:8545 -H "Content-Type: application/json" --data '{"jsonrpc":"2รท.0","method":"eth_coinbase","params":[],"id":64}' --verbose
Response:
< HTTP/1.1 403 Forbidden
< Content-Type: text/plain; charset=utf-8
< X-Content-Type-Options: nosniff
< Date: Wed, 18 Apr 2018 14:58:44 GMT
< Content-Length: 23
<
invalid host specified
* Connection #0 to host ... left intact
How can I query the ethereum client hosted on machine A from machine B ? Where I can find the ethereum client logs so I can debug it ?
Adding --rpcvhosts=* this flag solved the issue
Since --rpcvhosts is deprecated, you need to specify the flag --http.vhosts=<YOUR_DOMAIN>.
If you need an easy walkaround, you can set --http.vhosts=*, but this solution is a bad security practice.
I'm following an Autodesk tutorial on loading CAD files in the browser with WebGL, and am trying to convert an .nwd file I've uploaded to one of their buckets to an "OBJ".
When I run the POST request in step two of the tutorial above, however, I receive a 400 (full response below) that indicates x-ads-troubleshooting: The system does not support this file format, despite the fact that of the Autodesk documentation indicates .nwd files are supported.
Here's the full path to my file (requires Oauth token): https://developer.api.autodesk.com/oss/v2/buckets/gathering-a-bulding-bucket/objects/Yale_Residential_Colleges_Arch.nwd
When I added the item to the bucket, I was given the following objectId (which the docs also refer to as the source URN):
"objectId" : "urn:adsk.objects:os.object:gathering-a-bulding-bucket/Yale_Residential_Colleges_Arch.nwd"
I base64 encoded this string and removed the excess padding (the extra == characters at the end) per the documentation, which resulted in the following:
dXJuOmFkc2sub2JqZWN0czpvcy5vYmplY3Q6Z2F0aGVyaW5nLWEtYnVsZGluZy1idWNrZXQvWWFsZV9SZXNpZGVudGlhbF9Db2xsZWdlc19BcmNoLm53ZA
I'm now trying to convert this nwd file to an OBJ with the following command:
curl -X 'POST' -H 'Authorization: Bearer OAUTHTOKENHERE' -H 'Content-Type: application/json' -v 'https://developer.api.autodesk.com/modelderivative/v2/designdata/job' -d '{"input":{"urn":"dXJuOmFkc2sub2JqZWN0czpvcy5vYmplY3Q6Z2F0aGVyaW5nLWEtYnVsZGluZy1idWNrZXQvWWFsZV9SZXNpZGVudGlhbF9Db2xsZWdlc19BcmNoLm53ZA"},"output":{"formats":[{"type":"obj"}]}}'
This command yields the following response:
* Connected to developer.api.autodesk.com (52.7.124.118) port 443 (#0)
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate: developer.api.autodesk.com
* Server certificate: Symantec Class 3 Extended Validation SHA256 SSL CA
* Server certificate: VeriSign Universal Root Certification Authority
> POST /modelderivative/v2/designdata/job HTTP/1.1
> Host: developer.api.autodesk.com
> User-Agent: curl/7.43.0
> Accept: */*
> Authorization: Bearer OAUTHTOKENHERE
> Content-Type: application/json
> Content-Length: 181
>
* upload completely sent off: 181 out of 181 bytes
< HTTP/1.1 400 Bad Request
< Access-Control-Allow-Credentials: true
< Access-Control-Allow-Origin: *
< Content-Type: application/json; charset=utf-8
< Date: Fri, 09 Sep 2016 16:07:06 GMT
< Server: Apigee Router
< x-ads-app-identifier: platform-viewing-2016.08.01.1114.dbcc24a-production
< x-ads-duration: 525 ms
< x-ads-exception-id: c54954c5-dc74-4b09-961a-5eb7de82625b
< x-ads-startup-time: Wed Sep 07 01:40:23 UTC 2016
< x-ads-troubleshooting: The system does not support this file format.
< Content-Length: 61
< Connection: keep-alive
<
* Connection #0 to host developer.api.autodesk.com left intact
{"diagnostic":"Failed to trigger translation for this file."}
Does anyone have any leads on what I might be overlooking? I'd be grateful for any help others can offer!
Please take a look at this list of supported translations, you'll see that translation from .nwd to .obj is not supported, only to svf (which is used for Viewer).
I have the same kind of connectivity problem discussed in the question "Cygnus can not persist data on Cosmos global instance". However, I have found no solution after read it.
Nowadays, I have recently deployed two virtual machines in FILAB (both VMs contain Orion ContextBroker 0.26.1 and Cygnus 0.11.0).
When I try to persist data on Cosmos via Cygnus, I get the following error message (the same in both VMs) :
2015-12-17 19:03:00,221 (SinkRunner-PollingRunner-DefaultSinkProcessor)
[ERROR - com.telefonica.iot.cygnus.sinks.OrionSink.process(OrionSink.java:305)]
Persistence error (The /user/rmartinezcarreras/def_serv/def_serv_path/room1_room
directory could not be created in HDFS. Server response: 503 Service unavailable)
On the other hand, when I try to fire a request from the command line of whatever VM, I get the next response:
[root#orionlarge centos]# curl -v -X GET "http://cosmos.lab.fiware.org:14000/webhdfs/v1/user/rmartinezcarreras/?
op=liststatus&user.name=rmartinezcarreras" -H "X-Auth-Token: XXXXXXX"
* About to connect() to cosmos.lab.fiware.org port 14000 (#0)
* Trying 130.206.80.46... connected
* Connected to cosmos.lab.fiware.org (130.206.80.46) port 14000 (#0)
> GET /webhdfs/v1/user/rmartinezcarreras/?
op=liststatus&user.name=rmartinezcarreras HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7
NSS/3.16.2.3 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> Host: cosmos.lab.fiware.org:14000
> Accept: */*
> X-Auth-Token: XXXXX
>
* Closing connection #0
* Failure when receiving data from the peer
curl: (56) Failure when receiving data from the peer
Nevertheless, from an external VM (outside FILAB):
[root#dsieBroker orion]# curl -v -X GET
"http://cosmos.lab.fiware.org:14000/webhdfs/v1/user/rmartinezcarreras/?
op=liststatus&user.name=rmartinezcarreras" -H "X-Auth-Token: XXXXX"
* About to connect() to cosmos.lab.fiware.org port 14000 (#0)
* Trying 130.206.80.46... connected
* Connected to cosmos.lab.fiware.org (130.206.80.46) port 14000 (#0)
> GET /webhdfs/v1/user/rmartinezcarreras/?
op=liststatus&user.name=rmartinezcarreras HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7
NSS/3.19.1 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> Host: cosmos.lab.fiware.org:14000
> Accept: */*
> X-Auth-Token: XXXXXX
>
< HTTP/1.1 200 OK
< X-Powered-By: Express
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Methods: HEAD, POST, GET, OPTIONS, DELETE
< Access-Control-Allow-Headers: origin, content-type, X-Auth-Token, Tenant-
ID, Authorization
< server: Apache-Coyote/1.1
< set-cookie:
hadoop.auth="u=rmartinezcarreras&p=rmartinezcarreras&t=simple&e=XXXXXX&s=
XXXXhD 8="; Version=1; Path=/
< Content-Type: application/json; charset=utf-8
< transfer-encoding: chunked
< date: Thu, 17 Dec 2015 18:52:46 GMT
< connection: close
< Content-Length: 243
< ETag: W/"f3-NL9+bYJLweyFpoJfNgjQrg"
<
{"FileStatuses":{"FileStatus":
[{"pathSuffix":"def_serv","type":"DIRECTORY","length":0,"owner":
"rmartinezcarreras","group":"rmartinezcarreras","permission":"740",
"accessTime":0,"modificationTime":1450349251833,"blockSize":0,
"replication":0}]}}
* Closing connection #0
Also get good results from my Cosmos account.
How can I solve this? It seems a connectivity problem. Could you help me?
Thank you in advance
Finally, this was a problem with the OAuth2 proxy we are using for Authentication and Authorization. The underlying Express module it is based was adding a content-length header when another transfer-encoding: chunked header was present. As researched in this other question, this combination is not according to the RFC, and was causing certain fully compliant client implementations were reseting the connection.