First I create an API consumer key and secret with read_write permission. (Either manually from the UI or programmatically using the API)
Then, i use the consumer_key and consumer_secret as query parameters to consume the API: create a webhook for example. So i did:
curl -X POST \
'http://wp.mee/wordpress496/wp-json/wc/v3/webhooks?consumer_key=ck_7cc776be8d22b6841b0d62a96a50e975e7523343&consumer_secret=cs_7b788da4bf6063f8dff4b0463c1e9693fdee7a5b' \
-H 'Content-Type: application/json' \
-d '{"name":"ProWebSms","topic":"order.created","delivery_url":"https://dev.smshare.fr/api/v2/woo/webhooks/all/7235173095214b608914159bea2360eb"}'
I get the following message:
{"code":"woocommerce_rest_cannot_create","message":"Sorry, you are not allowed to create resources.","data":{"status":401}}
Using the basic authentication mechanism fails also. I created a test.php just to be sure that the authorization header is not stripped out by the server and i can confirm that the header is there.
<?php var_dump(apache_request_headers()); ?>
//i can see:
'Authorization'
'Basic Y2tfN2NjNzc2YmU4ZDIyYjY4NDFiMGQ2MmE5NmE1MGU5NzVlNzUyMzM0Mzpjc183Yjc4OGRhNGJmNjA2M2Y4ZGZmNGIwNDYzYzFlOTY5M2ZkZWU3YTVi'
Tried on both:
woocommerce version 3.3.5
wordpress version: 4.9.6
And:
woocommerce version 3.5.4
wordpress version: 5.0.3
EDIT
I noticed that if I replace consumer_key and consumer_secret by the admin user username/password (ex: admin:admin) the call succeeds.
The wp_authenticate_username_password is being called..
I found the issue. You must be using HTTPS.
This make testing in local environments hard.
Related
So I am using vault approle with airflow as secret backend and it keeps throwing permission denied error on $Vault_ADDR/v1/auth/approle/login. I tried using approle from CLI like:
vault write auth/approle/login role_id="$role_id" secret_id="$secret_id"
and it works fine.
But if I try it using API:
curl --request POST --data #payload.json $VAULT_ADDR/v1/auth/approle/login
where payload.json contains secret and role id. It fails with permission denied.
Here is my policy:
vault policy write test-policy -<<EOF
path "kv/data/airflow/*" {
capabilities = [ "read", "list" ]
}
EOF
It works fine for reading on this path.
and role:
vault write auth/approle/role/test-role token_ttl=4h token_max_ttl=5h token_policies="test-policy"
Don't know why it is failing with API.
An important thing to mention is that I am using cloud based HCP Vault.
The problem is with your app_role authentication.You need to provide admin namespace in your url.
Change this:
curl --request POST --data #payload.json $VAULT_ADDR/v1/auth/approle/login
To this:
curl --request POST --data #payload.json $VAULT_ADDR/v1/admin/auth/approle/login
Furthermore, if you are trying to access from a third party tool like airflow then try adding "namespace=admin" in your config file.
Found the problem. HCP vault uses namespace (default = admin). Namespace was needed in url :
$VAULT_ADDR/v1/admin/auth/approle/login
but the problem still exists in Airflow's Hashicorp provider. Changing the auth_mount_point still concatenates it at the end as :
$VAULT_ADDR/v1/auth/{$auth_mount_point}
I'm trying to update the property of an artifact(In my case sample text file)
I tried the API https://www.jfrog.com/confluence/display/RTF/Artifactory+REST+API#ArtifactoryRESTAPI-UpdateItemProperties
this is what I tried:
curl -X PATCH -uadmin:password -H '"props":{"ccs_x1_version":
"7.7.7.7"}'
"http://XXXXXXXXX:8081/artifactory/maven-dev-local/com/test/sbom/2.0.0-SNAPSHOT/sbom-2.0.0-20180704.094719-1.txt"
but was not successful, as command returns nothing, can someone help me in figuring out the right usage.
Looks like you're missing the API endpoint for using the UpdateItemProperties. You're also sending the data as malformed JSON as a header rather than data.
You need to add the endpoint: /api/metadata/ and reformat your data to a proper JSON.
{
"props" : {
"ccs_x1_version": "7.7.7.7"
}
}
According the the link provided:
Since: 6.1.0
Security: Requires a privileged user (Annotate authorisation required)
Usage: PATCH /api/metadata/{repoKey}/{itemPath}?[&recursive=1]
Produces: application/json
Sample Usage:
PATCH /api/metadata/libs-release-local/org/acme?[recursive=1]
{
"props":{
"newKey": "newValue",
"existingKey": "modifiedValue",
"toBeRemovedKey": null
}
}
If you update your request to curl -X PATCH -uadmin:password -d '{"props":{"ccs_x1_version": "7.7.7.7"}}' "http://XXXXXXXXX:8081/artifactory/api/metadata/maven-dev-local/com/test/sbom/2.0.0-SNAPSHOT/sbom-2.0.0-20180704.094719-1.txt"
This is also a new rest endpoint which is only available with the latest version of artifactory 6.1.0. If you're running an older version you're going to have to use the previous endpoint (Set Item Properties) in the official JFrog Documentation.
This is formatted curl -X PUT -uadmin:password "http://XXXXXXXXX:8081/artifactory/api/storage/maven-dev-local/com/test/sbom/2.0.0-SNAPSHOT/sbom-2.0.0-20180704.094719-1.txt?properties=ccs_x1_version=7.7.7.7"
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).
I recently got a hubot setup for irc and works fine. I'm trying to add this script.
I'm not entirely understanding the setup instructions however. The setup instructions read
curl -H "Authorization: token <your api token>" \
-d '{"name":"web","active":true,"events":["pull_request"],"config":{"url":"<this script url>","content_type":"json"}}' \
https://api.github.com/repos/<your user>/<your repo>/hooks
I don't understand what the "url":"<this script url>" refers to. Anyone know?
I'm deploying to heroku if that helps.
Add more explanation for #MikeKusold 's answer
The curl command is to create the github hook, therefore it is set hook to the receiver for the notification.
"config": {
"url": "http://example.com/webhook",
"content_type": "json"
}
The hook is the hubot plugin, so the url path is defined in that script, see line
robot.router.post "/hubot/gh-pull-requests", (req, res) ->
Below two lines in that scripts tell you what is after the path, it has parameters room & type
user.room = query.room if query.room
user.type = query.type if query.type
Hubot itself define the port number, it route the path to the plugin as it requested, check this part in robot.coffee, the default port is 8080
Therefore the URL is like below
http://<your hubot sever>:8080/hubot/gh-pull-requests/?room=<room>&type=<type>
Actually you can use curl command to test it towards hubot directly first.
Add <HUBOT_URL>:<PORT>/hubot/gh-pull-requests?room=<room>[&type=<type>] url hook via API
That is the URL