I am attempting to update a file in one of my repos via the API.
Here is my get of that file (works nicely):
curl -XGET 'https://git.fake.local/api/v3/repos/jsmith/repo_version/contents/version.html?ref=gh-pages'
{
"name": "version.html",
"path": "version.html",
"sha": "b1b716105590454bfc4c0247f193a04088f39c7f",
"size": 5,
"url": "https://git.fake.local/api/v3/repos/jsmith/post_version/contents/version.html?ref=gh-pages",
"html_url": "https://git.fake.local/jsmith/post_version/blob/gh-pages/version.html",
"git_url": "https://git.fake.local/api/v3/repos/jsmith/post_version/git/blobs/b1b716105590454bfc4c0247f193a04088f39c7f",
"type": "file",
"content": "aW5pdAo=\n",
"encoding": "base64",
"_links": {
...
}
}
Here is my attempt to update that file via PUT:
curl -XPUT 'https://git.fake.local/api/v3/repos/jsmith/repo_version/contents/version.html?ref=gh-pages' -d '{
"message": "update from api",
"committer": {
"name": "Joe Smith",
"email": "jsmith#fake.com"
},
"content": "bXkgdXBkYXRlZCBmaWxlIGNvbnRlbnRz",
"sha": "b1b716105590454bfc4c0247f193a04088f39c7f"
}'
RESULT:
{
"message": "Not Found"
}
Okay... I think I got it.
From the github doco:
Authentication
There are three ways to authenticate through GitHub API v3. Requests
that require authentication will return 404 Not Found, instead
of 403 Forbidden, in some places. This is to prevent the
accidental leakage of private repositories to unauthorized users.
I was expecting a 403 if Auth was a problem but they are throwing a 404, so basically I probably need to make sure I am auth'd correctly and all will be well.
SOLVED:
I created a personal oauth token (under settings/applications) and add to curl request in header and it all works great.
curl -XPUT -H "Authorization: token MYSECRETTOKEN"
Related
I'm trying to send data to an ElasticSearch server using CURL. There is an index called 'datastream2' which has a lot of fields sorta like this:
"datastream2": {
"mappings": {
"properties": {
"UA": {
"type": "text",
"fields": {
"keyword": {
"type": "keyword",
"ignore_above": 512
}
}
},
"accLang": {
"type": "text",
"fields": {
"keyword": {
"type": "keyword",
"ignore_above": 256
}
}...
I'd like to use CURL to send data to this index.
I've been using CURL for the attempted POST like this:
curl -v -X POST http://66-228-66-111.ip.linodeusercontent.com:9200/datastream2/newdocname -H "Content-type: application/json" --user elastic:u34XXXc2qYNGnVS4XXXA -d '{"UA":"Mozilla","acclang":"eng"}'
but it's failing with the message:
{"error":"no handler found for uri [/datastream2/newdocname] and method [POST]"}%
I will admit that I'm not sure what to put after the indexname of '/datastream2/' , but I've tried various different values. Some documentation says to list the type (which I'm not sure where to find) and some docs say that this is no longer necessary on ElasticSearch 8+ .
Any ideas how I can get this data posted into ElasticSearch?
You just need to replace newdocname by _doc and it will work
curl -v -X POST http://66-228-66-111.ip.linodeusercontent.com:9200/datastream2/_doc
I have a problem with testing MB WAY for API only payment method on Adyen https://docs.adyen.com/payment-methods/mb-way/api-only
After I send request as described here https://docs.adyen.com/payment-methods/mb-way/api-only#make-payment
curl https://checkout-test.adyen.com/v68/payments \
-H 'x-api-key: YOUR_API_KEY' \
-H 'content-type: application/json' \
-d '{
"merchantAccount": "YourCompanyECOM",
"reference": "My first Adyen test payment",
"amount": {
"value": 1000,
"currency": "EUR"
},
"paymentMethod": {
"type": "scheme",
"encryptedCardNumber": "test_4111111111111111",
"encryptedExpiryMonth": "test_03",
"encryptedExpiryYear": "test_2030",
"encryptedSecurityCode": "test_737"
}
}'
I receive this response
{
"status": 500,
"errorCode": "905_1",
"message": "Could not find an acquirer account for the provided txvariant (mbway), currency (EUR), and action (AUTH).",
"errorType": "configuration",
"pspReference": "GBSGRNJVSBLZNN82"
}
I did not found a way to set up an acquirer account on Adyen dashboard so far. Is that option there, or I need to do something else to make it work?
This kind of error can have as origin one of the following reasons:
The currency is not configured or supported
The minimum amount is set too low
The payment method is not configured on your account
The payment type (shopperInteraction) is not supported.
The full documentation of this error is here
Description:
Oki, i am trying to upload products to printful via api
|> __ they changed to oauth and the docs are not matching anymore
|> __ the functionality itself is in their docs, but i cant get it to auth
|> __ their dev support was not helpful and i am not a api person
Assets:
=>> https://developers.printful.com/docs/#section/Products-API-examples/Create-a-new-Sync-Product
=>> https://developers.printful.com/docs/#operation/createSyncProduct
Code:
heres my error and code basically directly from their docs:
{"code":200,"result":"Welcome to the Printful API","extra":[]}
{"code":400,"result":"This API endpoint applies only to Printful stores based on the
Manual Order / API platform.
Find out more at Printful API docs.","error":{"reason":"BadRequest","message":
"This API endpoint applies only to Printful stores based on the Manual Order
/ API platform. Find out more at Printful API docs."}}%
# Authorized CURL request with Basic auth
curl -X GET 'https://api.printful.com/' \
-H 'Authorization: Bearer TOKEN'
curl --location --request POST 'https://api.printful.com/store/products' \
-H 'Authorization: Bearer SAMEtOKEN' \
--data-raw '{
"sync_product": {
"name": "T-Shirt",
"thumbnail": "https://picsum.photos/200/300"
},
"sync_variants": [
{
"retail_price": 21.00,
"variant_id": 4011,
"files": [
{
"url": "https://picsum.photos/200/300?image=1"
},
{
"type": "back",
"url": "https://picsum.photos/200/300?image=1"
}
]
},
{
"retail_price": 21.00,
"variant_id": 4012,
"files": [
{
"url": "https://picsum.photos/200/300?image=1"
},
{
"type": "back",
"url": "https://picsum.photos/200/300?image=1"
}
]
}
]
}'
To save anyone else the headache:
The Printful 'Create Product' and similiar API calls don't work with shops created via the automatic API integrations:
As far as I'm aware there is no workaround, but if I find one I'll update here. The name is a bit misleading, as the 'Sync Products' seem to describe products capable of syncing with external services. However you are limited to the ECommerce Platform Sync API calls. It seems to be possible to modify an existing one, but that doesn't help much for GUI-free automation.
Maybe you can you create a number of placeholders as 'Drafts' and modify, but haven't gotten that running myself yet.
I upload many files to Nuxeo server using rest API. Now I need to add permission to users. I use http://localhost:8080/nuxeo/api/v1/id/file-id/#acl endpoint with payload:
{
"username": "username",
"permission": "ReadWrite"
}
But it is not working. The error is:
{
"entity-type": "exception",
"status": 405,
"message": "javax.ws.rs.WebApplicationException"
}
How can I do it? Is there any endpoint for that?
Permission can be added by the Document.AddPermission operation available on the http://localhost:8080/nuxeo/api/v1/automation/Document.AddPermission endpoint.
Here is a curl example call used to add ReadWrite permission for editor user to the document with ID 2d28e87f-0753-4cfc-9f9b-b17d424aa6a7:
curl -X POST -u Administrator:Administrator \
http://localhost:8080/nuxeo/api/v1/automation/Document.AddPermission \
-H "Content-Type: application/json" \
-d '{"params":{"users":["editor"],"permission":"ReadWrite"},"input":"2d28e87f-0753-4cfc-9f9b-b17d424aa6a7"}'
And here is an example payload when you want to add permission for external user:
{
"params": {
"users":[],
"email": "some-external#user.com",
"permission": "Read",
"begin": "2020-06-01T00:00:00+02:00",
"end": "2020-06-30T00:00:00+02:00",
"notify": true,
"comment": "notify#me.com"},
"context": {},
"input": "2d28e87f-0753-4cfc-9f9b-b17d424aa6a7"
}
I would like to use the OpenShift REST api to make queries from a separate portal. We first created a service account using the following steps (where my-id is an admin in the project):
C:\openshift>oc login
Authentication required for https://openshift-test.foo.com:8443 (openshift)
Username: my-id
Password:
Login successful.
You have access to the following projects and can switch between them with 'oc project <projectname>':
* datalake-replication-consumers
datalake-replication-demo
Using project "datalake-replication-consumers".
C:\openshift>oc create serviceaccount gmi-registry
serviceaccount "gmi-registry" created
C:\openshift>oc policy add-role-to-user admin system:serviceaccounts:datalake-replication-consumers:gmi-registry
role "admin" added: "system:serviceaccounts:datalake-replication-consumers:gmi-registry"
C:\openshift>oc serviceaccounts get-token gmi-registry
<token here>
I then pasted that token as a bearer token into Postman to make a few api calls. Since I added my service account to the admin role within my project, I assumed this would work, but instead we're getting back a 403.
GET pods:
https://openshift-test.foo.com:8443/api/v1/namespaces/datalake-replication-consumers/pods
Response:
{
"kind": "Status",
"apiVersion": "v1",
"metadata": {},
"status": "Failure",
"message": "User \"system:serviceaccount:datalake-replication-consumers:gmi-registry\" cannot list pods in project \"datalake-replication-consumers\"",
"reason": "Forbidden",
"details": {
"kind": "pods"
},
"code": 403
}
GET specific deployment:
https://openshift-test.foo.com:8443/oapi/v1/namespaces/datalake-replication-consumers/deploymentconfigs/entity-65869977-9d56-49a5-afa2-4a547df82d5c
Response:
{
"kind": "Status",
"apiVersion": "v1",
"metadata": {},
"status": "Failure",
"message": "User \"system:serviceaccount:datalake-replication-consumers:gmi-registry\" cannot get deploymentconfigs in project \"datalake-replication-consumers\"",
"reason": "Forbidden",
"details": {
"name": "entity-65869977-9d56-49a5-afa2-4a547df82d5c",
"kind": "deploymentconfigs"
},
"code": 403
}
What are we missing for service account permissions here?
UDPATE: I should also add that I pulled my own bearer token out of the CLI and used that for both calls. That worked.
Not a very exciting answer, but our problem was solved when we installed a v3.7 instance. My initial tests were on v1.5, which I think corresponds to 3.5 or 3.6 in the enterprise offering?