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.
Related
Some URLs with brackets don't work with CURL but work on Chrome and Firefox.
For example this URL: https://rdtrkr.com/mg.php?voluum_id=d51b17bc-c537-4f3e-9879-2e373341ae5a&widget_id={widget_id}&campaign_id={campaign_id}&teaser_id={teaser_id}&geo={geo}&img=guy18.jpg&txt=german&lp=de&click_price={click_price}&click_id={click_id}&{click_id} does work in Chrome and firefox but when called with CURL, gives a 404 error.
curl \
-H "User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.80 Safari/537.36" \
-v "https://rdtrkr.com/mg.php?voluum_id=d51b17bc-c537-4f3e-9879-2e373341ae5a&widget_id={widget_id}&campaign_id={campaign_id}&teaser_id={teaser_id}&geo={geo}&img=guy18.jpg&txt=german&lp=de&click_price={click_price}&click_id={click_id}&{click_id}"
Produces the result:
< HTTP/2 404
< server: nginx
< date: Thu, 13 Dec 2018 16:53:45 GMT
< content-type: text/html; charset=UTF-8
< content-length: 0
But with chrome developper tools in "Preserve log" mode I have :
CURL receives 404 instead of a 302 redirect. Is it related to the fact that CURL might be URL encoding brackets? I don't know what is going wrong here.
ps: I am not the owner of the website I'm using in the example.
Curly brackets are unsafe in URLs. cURL (unlike Google Chrome) tries to do you a favor and automatically encodes the URL.
In other words, it transforms { to %7B and } to &7D.
To prevent that behavior, you can pass the query string parameters using -d instead. Since -d changes the request to a POST, you'll also need to use -G to force the request to be a GET.
So instead of doing
curl "http://example.com?param1=xxx¶m2=yyy"
you can do
curl "http://example.com" -G -d "param1=xxx¶m2=yyy"
In your particular case, for some reason the webserver you're targeting will still return 404 unless you supply an Accept-Language header:
curl -v "http://rdtrkr.com/mg.php" \
-G -d "voluum_id=d51b17bc-c537-4f3e-9879-2e373341ae5a&widget_id={widget_id}&campaign_id={campaign_id}&teaser_id={teaser_id}&geo={geo}&img=guy18.jpg&txt=german&lp=de&click_price={click_price}&click_id={click_id}&{click_id}" \
-H "Accept-Language: en-US,en;q=0.9,fr;q=0.8,ru;q=0.7,es;q=0.6"
gives
* Trying 34.192.193.118...
* Connected to rdtrkr.com (34.192.193.118) port 80 (#0)
> GET /mg.php?voluum_id=d51b17bc-c537-4f3e-9879-2e373341ae5a&widget_id={widget_id}&campaign_id={campaign_id}&teaser_id={teaser_id}&geo={geo}&img=guy18.jpg&txt=german&lp=de&click_price={click_price}&click_id={click_id}&{click_id} HTTP/1.1
> Host: rdtrkr.com
> User-Agent: curl/7.47.0
> Accept: */*
> Accept-Language: en-US,en;q=0.9,fr;q=0.8,ru;q=0.7,es;q=0.6
>
< HTTP/1.1 302 Found
< Server: nginx
< Date: Thu, 13 Dec 2018 17:39:18 GMT
< Content-Type: text/html; charset=UTF-8
< Content-Length: 0
< Connection: keep-alive
< Location: https://rotronica-premarity.com/d51b17bc-c537-4f3e-9879-2e373341ae5a?widget_id={widget_id}&campaign_id={campaign_id}&teaser_id={teaser_id}&geo={geo}&img=guy18.jpg&txt=german&lp=de&click_price={click_price}&click_id={click_id}
<
* Connection #0 to host rdtrkr.com left intact
Use this flag (from man curl):
-g/--globoff
This option switches off the "URL globbing parser". When you set this option, you can
specify URLs that contain the letters {}[] without having them being interpreted by curl
itself. Note that these letters are not normal legal URL contents but they should be
encoded according to the URI standard.
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 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.
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!