I am learning OpenStack now and I want to list all accessible volumes on my OpenStack controller by HTTP get request with x_auth_token:
http://{OpenStack controller IP}:8776/v3/{project_id}/volumes
(Reference URL: https://developer.openstack.org/api-ref/block-storage/v3/index.html?expanded=#list-accessible-volumes)
But, the request body always as below:
{
"badRequest":{
"message": "Malformed request url",
"code": 400
}
}
I have try many times but they all didn't work.
So, I want to know, what the request url should be here?
Thanks in advance.....
One of the possible reasons is that your project_id is incorrect or doesn't match your credential, take a look at this link. In order to solve this problem you can:
1. Try openstack command with debug option.
openstack --debug volume list
#or
cinder --debug list
you could get the request and response details:
REQ: curl -g -i -X GET http://ip:port/v3/{project_id}/volumes/detail -H "User-Agent: python-cinderclient" -H "Accept: application/json" -H "X-Auth-Token: {token_value}"
Make sure you have input every required headers(context-type/x-auth-token/...).
Try to ask for help in irc channel #openstack-cinder
Related
I tried to get an access token with the google documentation.
curl -L -X POST 'https://www.googleapis.com/oauth2/v4/token?
client_id=oauth2-client-id& client_secret=oauth2-client-secret&
code=authorization-code& grant_type=authorization_code&
redirect_uri=https://www.google.com'
With this request it didn't worked.
I added -H 'Content-Length: 0' and now I'm ending up with
{
"error": "invalid_grant",
"error_description": "Bad Request"
}
Anybody have an idea?
If fixing the space didn't work, re-do you linking here from the Google guide, steps 1-6. Then get a new authorization code. I had the same issue and re-linking worked for me (with the -H flag).
it seems you have a space in the request:
/v4/token? client_id=oauth2-client-id
when i tried to copy past the commands from the documentation it didn't work.
i had to re-edit the request before i could use it and it worked.
I've got the same issue.
curl -L -X POST "https://www.googleapis.com/oauth2/v4/token?client_id=<client_id>.apps.googleusercontent.com&client_secret=<secret>&code=4/4wGANiKF5......N0Jg&grant_type=authorization_code&redirect_uri=https://www.google.com"
Stumped
Don't you have to use a different redirect_uri? Your own configured redirect uri?
I need to perform a get request from nifi to couchbase. The curl command is:
curl http://HOST:PORT/query/service -d "statement=select item.Date from bucket unnest bucket as item" -u USER:PASSWORD
I tried using InvokeHttp and ExecuteStreamCommand but it keeps returning errors(status code 400). The full error message is:
{ "requestID": "bff62c0b-36fd-401d-bca0-0959e0944323", "errors":
[{"code":1050,"msg":"No statement or prepared value"}], "status":
"fatal", "metrics": {"elapsedTime": "113.31µs","executionTime":
"74.321µs","resultCount": 0,"resultSize": 0,"errorCount": 1
It's important to say that I prefer that the http request will be triggered by an incoming flowfile. I tried using the processors in various of ways but non of them worked.
When I run the command from the nifi server it works fine.
Thanks for the help
the -d parameter of the curl utility forces HTTP POST command
and application/x-www-form-urlencoded mime-type.
so, in the nifi InvokeHTTP select the following parameters
HTTP Method = POST
Remote URL = <your url here>
Basic Authentication Username = <username>
Basic Authentication Password = <password>
Content-Type = application/x-www-form-urlencoded
and the body of the flow file should be
statement=select item.Date from bucket unnest bucket as item
I don't know nifi, but based on the error message, the "statement=" part of the request isn't being included, or you are not sending the request as a POST command.
I would like to access HDFS files using webhdfs. Curl gives me an option of using --negotiate -u: user option to use existing kerberos token. How do we pass the negotiate option using HTTP request headers. I know that we can use "Authorization: Negotiate" option. However, I get the following error.
GSSException: Defective token detected
you can do like this:
kinit -kt ${your_keytab_file_full_path} ${your_principal}
curl --negotiate -u : -o ${your_keytab_file_full_path} ${URL}
Artifactory OSS
5.4.6 rev 50406900
Trying to get access token to work.
I created token...
e.g. curl -uadmin:adminpw -X POST "myserver:8081/artifactory/api/security/token" -d "username=moehoward"
Returned msg looks like success...
{
"scope" : "member-of-groups:readers api:*",
"access_token" : <very-long-string>
"expires_in" : 3600,
"token_type" : "Bearer"
}
I can see it in the gui (admin -> Security -> Access Tokens) with "Subject" = to the user ("moehoward" in the example above) and with a "Token ID" that's a lot shorter, something like...
f2eb693a-d4ff-4618-ba52-764dc975c497
To test, I tried to ping using example in the docs...
curl -umoehoward:<very-long-string> myserver:8081/artifactory/api/system/ping
Fails with a 401 (bad credentials).
I replace the token with the "token id" I see in the gui, same result.
I replace again with the hardcoded pw of the "moehoward" user and that works (responds with "OK").
I tried the "-H"Authentication: Bearer " approach using the long string and that worked. So I guess the very long string is the token and not the "Token ID" in the gui.
Q: Any idea why this works for Bearer" and not the user by name ?
So you are right that this is supposed to work for both standard authentication and the Authentication HTTP header.
I did the test on a server with the same version Artifactory OSS 5.4.6 and the following works fine here
Inject the proper variables
export SERVER=server-artifactory
export APIKEY=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Create and use an access token for user moehoward
curl -u "admin:$APIKEY" -X POST "http://$SERVER/artifactory/api/security/token" -d "username=moehoward" -d "scope=member-of-groups:readers" > token.log
export TOKEN=`cat token.log | jq -r '.access_token'`
curl -u "moehoward:$TOKEN" "http://$SERVER/artifactory/api/system/ping"
curl -H "Authorization: Bearer $TOKEN" "http://$SERVER/artifactory/api/system/ping"
I get "OK" from the last two commands. Can you run exactly these commands and report back?
I have personally experienced the same problem (Bearer header working, standard user credentials not working) with an old version of curl. The obvious workaround is to use Bearer, the more complex workaround is to upgrade curl (or use another tool).
What is the version of curl you use? Any curl from 2015 or more recent should work fine.
I am working with Nexus OSS 2.11.x and would like to create new users through the REST API. The following command correctly retrieves the list of all users, thus confirming that I am able to call the API:
curl -u $NEXUS_USER:$NEXUS_PASS $NEXUS_LOCAL/service/local/users
Based on the API documentation, I've constructed a JSON user object:
export USER='{"data":{"email":"testing#example.com","firstName":"Test","lastName":"Ing","userId":"testing","status": "active","roles":["repository-any-read"],"password": "test123$"}}'
And then I submit a POST request:
curl -i -H "Accept: application/json" -H "ContentType: application/json; charset=UTF-8" -v -d "$USER" -u $NEXUS_USER:$NEXUS_PASS $NEXUS_LOCAL/service/local/users
The response comes back with HTTP 201 (created) - but GET /service/local/users only gives me back the original user list. The user is not in the list provided from the UI, and the log (available in the UI) does not even indicate that any activity took place. The $NEXUS_USER account is in the "Nexus Administrator" role.
Does anyone have a suggestion for what I'm overlooking here?
I used the above code and had the same problem:
HTTP/1.1 201 Created
and nothing happened.
After some debuging I noticed a simple typo above which was a problem.
Instead:
-H "ContentType: application/json; charset=UTF-8"
should be:
-H "Content-Type: application/json; charset=UTF-8"
(notice the dash in Content-Type) and it started working.
The code above is correct and executes just fine today. The server was rebooted overnight and somehow that fixed things.
To further clarify the environment variables
NEXUS_LOCAL is your nexus server. If you install on localhost with the default settings, then export NEXUS_LOCAL=http://localhost:8081/nexus (Bash) or SET NEXUS_LOCAL=http://localhost:8081/nexus (Windows).
NEXUS_USER and NEXUS_PASS are plaintext for an account with in the Administrator role, or presumably UI Administrator (have no tested the latter).