When I do:
curl https://example.com/my/ressource \
-H "Content-Type: application/json" \
--data '{"itemid":["123","456"]}' \
-u myuser
I get HTTP 403 Forbidden error code. If I use a get request it works, e.g.
curl https://example.com/my/ressource
Works fine. Also if I disable basic authentication at the server side the above post request works fine.
The server is an Apache 2.4 and it is acting as a reverse proxy.
What is wrong with the post request?
It turned out, that in the above case Apache is used as a reverse proxy and the server behind Apache could not handle Authorization, so the solution was to remove this header with:
RequestHeader unset Authorization
Related
Using curl to send a PATCH to my web service and got error:
Bad Request, The request sent by the client was syntactically incorrect. Apache Tomcat/8.0.37
while sending GET and POST using curl have no issue.
Using Swagger sending the same PATCH has no issue. So using WireShark to compare the Swagger (good) case and curl (bad) case.
Swagger (good) case:
curl (bad) case:
In the good case, a 0xA is inserted after "{" and ",". curl doesn't do this and double quotes are missing.
Here is the Swagger UI:
and this is my curl command running on Windows Command Prompt
Chrome app ARC also gets OK response:
Any suggestion is appreciated.
The problem was fixed by following curl:
curl --request PATCH "http://......................" ^
--header "Content-Type: application/json" ^
--header "Accept: application/json" ^
--header "Authorization: ..............." ^
--data "{\"op\":\"add\",\"path\":\"/user\",\"value\":\"%~1\"}"
Because it runs on Windows.
We are developing a Chrome Extension and, as part of the release build, we want to publish it to the Chrome Webstore for testing.
We are using cURL to send the http requests.
Using the information in :
https://developer.chrome.com/webstore/using_webstore_api
we have successfully updated the store, but I am seeing an odd error when trying to publish it using the information in
"Publishing an item to trusted testers" in the above link.
The command line looks like this as suggested in the link above:
curl -H "Authorization: Bearer %refresh_token%" -H "x-goog-api-version: 2" -H "Content-Length: 0" -H "publishTarget: trustedTesters" -X POST -v https://www.googleapis.com/chromewebstore/v1.1/items/%app_id%/publish
When I run this I get an error back stating that the publish condition is not met. The error message states that we should set publish_to_trusted_testers=true, but I can find no documentation suggesting how or where I should set this.
Note that access tokens are working OK, and the PUT command to upload the new extension is also successful.
Any advice would be gratefully accepted.
Jon
https://developer.chrome.com/webstore/webstore_api/items/publish#parameters
The docs on https://developer.chrome.com/webstore/using_webstore_api don't currently point to the correct use of the api, but the publish docs are correct.
I tried url query and it succeeded:
curl \
enter code here-H "Authorization: Bearer $ACCESS_TOKEN" \
-H "x-goog-api-version: 2" \
-H "Content-Length: 0" \
-X POST \
-v \
https://www.googleapis.com/chromewebstore/v1.1/items/$APP_ID/publish?publishTarget=trustedTesters
Using WebHDFS API of Cosmos generates an expired certificate response.
Using this url: https://cosmos.lab.fi-ware.org:13000/
we can see certificate seems expired
Do we need updated certificate or any way to go around this problem?
The certificate must be renewed, for sure. In the meantime, you can simply ignore the certificate. If you are using curl, use the -k option:
$ curl -k -X POST "https://cosmos.lab.fiware.org:13000/cosmos-auth/v1/token" -H "Content-Type: application/x-www-form-urlencoded" -d "grant_type=password&username=frb#tid.es&password=MY_PASSWORD_IS_PRIVATE"
I've recently seen the access to Cosmos' WebHDFS in FIWARE Lab has been protected with OAuth2. I know I have to add a OAuth2 token to the request in order to continue using WebHDFS, but:
How can I get the token?
How the token is added to the request?
Without the token, the API always returns:
$ curl -X GET "http://cosmos.lab.fi-ware.org:14000/webhdfs/v1/user/gtorodelvalle?op=liststatus&user.name=gtorodelvalle"
Auth-token not found in request header
Yes, now WebHDFS access is protected with OAuth2. This is part of the general mechanism for pretecting REST APIs in FIWARE, which performs authentication and authorization. You can find more details here.
First of all, you must request an OAuth2 token to the Cosmos tokens generator. This is a service running in cosmos.lab.fiware.org:13000. You can do this using any REST client, the easiest way is using the curl command:
$ curl -k -X POST "https://cosmos.lab.fiware.org:13000/cosmos-auth/v1/token" -H "Content-Type: application/x-www-form-urlencoded" -d "grant_type=password&username=frb#tid.es&password=xxxxxxxx"
{"access_token": "qjHPUcnW6leYAqr3Xw34DWLQlja0Ix", "token_type": "Bearer", "expires_in": 3600, "refresh_token": "V2Wlk7aFCnElKlW9BOmRzGhBtqgR2z"}
As you can see, your FIWARE Lab credentials are required in the payload, in the form of a password-based grant type.
Once the access token is got (in the example above, it is qjHPUcnW6leYAqr3Xw34DWLQlja0Ix), simply add it to the same WebHDFS request you were performing in the past. The token is added by using the X-Auth-Token header:
$ curl -X GET "http://cosmos.lab.fiware.org:14000/webhdfs/v1/user/frb/path/to/the/data?op=liststatus&user.name=frb" -H "X-Auth-Token: qjHPUcnW6leYAqr3Xw34DWLQlja0Ix"
{"FileStatuses":{"FileStatus":[...]}}
If you try the above request with a random token the server will return the token is not valid; that's because you have not authenticated properly:
$ curl -X GET "http://cosmos.lab.fiware.org:14000/webhdfs/v1/user/frb/path/tp/the/data?op=liststatus&user.name=frb" -H "X-Auth-Token: randomtoken93487345"
User token not authorized
The same way, if using a valid token but trying to access another HDFS userspace, you will get the same answer; that's because you are not authorized to access any HDFS userspace but the one owned by you:
$ curl -X GET "http://cosmos.lab.fiware.org:14000/webhdfs/v1/user/fgalan/path/tp/the/data?op=liststatus&user.name=fgalan" -H "X-Auth-Token: qjHPUcnW6leYAqr3Xw34DWLQlja0Ix"
User token not authorized
IMPORTANT UPDATE:
From summer 2016, cosmos.lab.fiware.org is not workin anymore. Instead, a pair of clusters, storage.cosmos.lab.fiware.org and computing.cosmos.lab.fiware.org have been setup. Regarding the auth server of Cosmos, it currently run in computing.cosmos.lab.fiware.org, port TCP/13000.
The right request must be:
curl -X POST "https://cosmos.lab.fi-ware.org:13000/cosmos-auth/v1/token" -H "Content-Type: application/x-www-form-urlencoded" -d "grant_type=password&username=user#domain.com&password=yourpassword" -k
The url was incorrect, the correct is https://cosmos.lab.fi-ware.org:13000
-k is for turn off certificate verification
I'm trying to create a Webhook on Contentful.com via their Content Management API. Command as follows (note that I've tweaked respective ID's for security):
curl -X PUT -H 'Content-Type: application/vnd.contentful.management.v1+json' -H 'Authorization: Bearer c8c3ef46d5dbfe3c841a3b4bff1ee89449669ffd407d1a62c7a0ecbad9c3120' -H 'Content-Length: 33' 'https://api.contentful.com/spaces/du8mcuj2d5la/webhook_definitions/1CtkR6S5oUqWywgEO2i0xx' -d '{"url":"https://xxx.parseapp.com"}'
It appears no matter what URL (other than https://www.example.com) I use in the final object I get the following response:
{
"sys":{
"type":"Error",
"id":"InvalidJsonRequestBody"
},
"requestId":"85f-1338857905",
"message":"The body you sent is not valid JSON."
}
I've validated with Paw (http://luckymarmot.com/paw) that the endpoint pass accepts inbound POST requests and (returns a 200 response code). Just to stress if I switch out https://xxx.parseapp.com to https://www.example.com it creates the webhook. Anything else it appears to complain.
It seems that the issue is quite simple:
The payload length does not match the Content-Length header.
{"url":"https://xxx.parseapp.com"} is 34 bytes, but you've set the header explicitly to -H 'Content-Length: 33'. (33 is only true for the example.com example.)
If you adjust the length to -H 'Content-Length: 34' it should work fine.
Also you could leave this header out when experimenting with curl as it will automatically set it to the correct value (check with -v option).
In general most HTTP clients/libraries should set the Content-Length header on their own when doing POST/PUT requests.