I am having some trouble posting a transaction on my ReST server. When I try to POST a transaction, I always get a 422 error. If I delete any fields, I will get a 500 error. It seems like whatever transaction id is there is invalid, and I do not know why it is invalid. In my original .cto files, I did not ask for there to be a transactionID field, so I am assuming this is a default field. Here is a screenshot of my POST method:
Here is my input that I put in:
{
"$class": "models.transactionsModel.InvalidateCertificate",
"certificate": "#cert2",
"transactionId": "string",
"timestamp": "2018-06-18T16:57:45.644Z"
}
I made the certificate identifiable by a hash string
Here is the resulting curl, body, and header respectively,
curl -X POST --header 'Content-Type: application/json' --header 'Accept: application/json' -d '{ \
"$class": "models.transactionsModel.InvalidateCertificate", \
"certificate": "#cert2", \
"transactionId": "string", \
"timestamp": "2018-06-18T16:57:45.644Z" \
}' 'http://localhost:3000/api/models.transactionsModel.InvalidateCertificate'
{
"error": {
"statusCode": 422,
"name": "ValidationError",
"message": "The `models_transactionsModel_InvalidateCertificate` instance is not valid. Details: `transactionId` can't be set (value: \"string\").",
"details": {
"context": "models_transactionsModel_InvalidateCertificate",
"codes": {
"transactionId": [
"absence"
]
},
"messages": {
"transactionId": [
"can't be set"
]
}
},
"stack": "ValidationError: The `models_transactionsModel_InvalidateCertificate` instance is not valid. Details: `transactionId` can't be set (value: \"string\").\n at /Users/harshdeshpande/.nvm/versions/node/v8.11.2/lib/node_modules/composer-rest-server/node_modules/loopback-datasource-juggler/lib/dao.js:398:12\n at models_transactionsModel_InvalidateCertificate.<anonymous> (/Users/harshdeshpande/.nvm/versions/node/v8.11.2/lib/node_modules/composer-rest-server/node_modules/loopback-datasource-juggler/lib/validations.js:578:11)\n at models_transactionsModel_InvalidateCertificate.next (/Users/harshdeshpande/.nvm/versions/node/v8.11.2/lib/node_modules/composer-rest-server/node_modules/loopback-datasource-juggler/lib/hooks.js:93:12)\n at models_transactionsModel_InvalidateCertificate.<anonymous> (/Users/harshdeshpande/.nvm/versions/node/v8.11.2/lib/node_modules/composer-rest-server/node_modules/loopback-datasource-juggler/lib/validations.js:575:23)\n at models_transactionsModel_InvalidateCertificate.trigger (/Users/harshdeshpande/.nvm/versions/node/v8.11.2/lib/node_modules/composer-rest-server/node_modules/loopback-datasource-juggler/lib/hooks.js:83:12)\n at models_transactionsModel_InvalidateCertificate.Validatable.isValid (/Users/harshdeshpande/.nvm/versions/node/v8.11.2/lib/node_modules/composer-rest-server/node_modules/loopback-datasource-juggler/lib/validations.js:541:8)\n at /Users/harshdeshpande/.nvm/versions/node/v8.11.2/lib/node_modules/composer-rest-server/node_modules/loopback-datasource-juggler/lib/dao.js:394:9\n at doNotify (/Users/harshdeshpande/.nvm/versions/node/v8.11.2/lib/node_modules/composer-rest-server/node_modules/loopback-datasource-juggler/lib/observer.js:155:49)\n at doNotify (/Users/harshdeshpande/.nvm/versions/node/v8.11.2/lib/node_modules/composer-rest-server/node_modules/loopback-datasource-juggler/lib/observer.js:155:49)\n at doNotify (/Users/harshdeshpande/.nvm/versions/node/v8.11.2/lib/node_modules/composer-rest-server/node_modules/loopback-datasource-juggler/lib/observer.js:155:49)\n at doNotify (/Users/harshdeshpande/.nvm/versions/node/v8.11.2/lib/node_modules/composer-rest-server/node_modules/loopback-datasource-juggler/lib/observer.js:155:49)\n at Function.ObserverMixin._notifyBaseObservers (/Users/harshdeshpande/.nvm/versions/node/v8.11.2/lib/node_modules/composer-rest-server/node_modules/loopback-datasource-juggler/lib/observer.js:178:5)\n at Function.ObserverMixin.notifyObserversOf (/Users/harshdeshpande/.nvm/versions/node/v8.11.2/lib/node_modules/composer-rest-server/node_modules/loopback-datasource-juggler/lib/observer.js:153:8)\n at Function.ObserverMixin._notifyBaseObservers (/Users/harshdeshpande/.nvm/versions/node/v8.11.2/lib/node_modules/composer-rest-server/node_modules/loopback-datasource-juggler/lib/observer.js:176:15)\n at Function.ObserverMixin.notifyObserversOf (/Users/harshdeshpande/.nvm/versions/node/v8.11.2/lib/node_modules/composer-rest-server/node_modules/loopback-datasource-juggler/lib/observer.js:153:8)\n at Function.ObserverMixin._notifyBaseObservers (/Users/harshdeshpande/.nvm/versions/node/v8.11.2/lib/node_modules/composer-rest-server/node_modules/loopback-datasource-juggler/lib/observer.js:176:15)"
}
}
{
"date": "Mon, 18 Jun 2018 18:23:47 GMT",
"content-encoding": "gzip",
"x-content-type-options": "nosniff",
"x-download-options": "noopen",
"x-frame-options": "DENY",
"content-type": "application/json; charset=utf-8",
"access-control-allow-origin": "http://localhost:3000",
"transfer-encoding": "chunked",
"connection": "keep-alive",
"access-control-allow-credentials": "true",
"vary": "Origin, Accept-Encoding",
"x-xss-protection": "1; mode=block"
}
What is even stranger is that I can submit a valid transaction via the Composer playground. In the composer playground, though, it does not ask for a transactionID or timestamp - it automatically generates while the transaction is being submitted.
See the answer here -> error executing hyperledger fabric code on localhost:3000 (through REST) - transactionId - it is really a Loopback issue.
Post your same transaction as follows (but remove the transactionId and timestamp - these are generated for you and the former represents the transaction Id on the ledger):
{
"$class": "models.transactionsModel.InvalidateCertificate",
"certificate": "#cert2"
}
cheers
Related
How do I get the timestamp at which a PR review was request/re-requested? It shows as an event in the conversations tab in a PR so it must exist somewhere.
The pulls API endpoint show who has been requested to review but I can't see when.
"requested_reviewers": [
{
"login": "tamlyn",
...
},
],
Any ideas?
You're looking for the GitHub Timeline API. See the docs for the Timeline API here.
Request:
curl \
-H "Accept: application/vnd.github+json" \
-H "Authorization: Bearer <YOUR-TOKEN>" \
https://api.github.com/repos/OWNER/REPO/issues/ISSUE_NUMBER/timeline
Response:
...
{
"id": "12345",
...
"actor": {
"login": "user",
...
},
"event": "review_requested",
"created_at": "2022-01-01T01:01:01Z",
...
"review_requester": {
"login": "user",
...
},
"requested_reviewer": {
"login": "user2",
...
},
...
},
...
I want to add a record to a MongoDB collection with the new MongoDB Data API. It works perfectly with Postman or curl with this code:
curl --location --request POST 'https://data.mongodb-api.com/app/<Data API App ID>/endpoint/data/beta/action/insertOne' \
--header 'Content-Type: application/json' \
--header 'Access-Control-Request-Headers: *' \
--header 'api-key: <Data API Key>' \
--data-raw '{
"dataSource": "<cluster name>",
"database": "<database name>",
"collection": "<collection name>",
"document": {
"firstname": "John",
"lastname": "Doe",
"email": "john#doe.com"
}
}'
but fails when I use fetch:
function addUser(event){
event.preventDefault();
fetch('https://data.mongodb-api.com/app/<Data API App ID>/endpoint/data/beta/action/insertOne', {
method:'POST',
mode: 'no-cors',
headers: {
'Content-type':'application/json',
'Access-Control-Request-Headers': '*',
'api-key': '<Data API Key>',
},
body:
{
"dataSource": "<cluster name>",
"database": "<database name>",
"collection": "<collection name>",
"document":
{
"firstname": "John",
"lastname": "Doe",
"email": "john#doe.com"
}
}
})
res.render('homepage')
}
Error in MongoDB log: Error:
"no authentication methods were specified"
Where is the error in my code?
I am a beginner with fetch to MongoDB Data API
Thank you very much!
Problem solved! Had to add this on top of my routes:
router.use(express.json());
Hope this might help for someone else too :)
When creating a subscription, it would be nice to return the subscription ID.
For instance, the following code doesn't return anything :
curl localhost:1026/v2/subscriptions -s -S --header 'Content-Type: application/json' \
-d #- <<EOF
{
"description": "A subscription to get info about Room1",
"subject": {
"entities": [
{
"id": "Room1",
"type": "Room"
}
],
"condition": {
"attrs": [
"pressure"
]
}
},
"notification": {
"http": {
"url": "http://localhost:1028/accumulate"
},
"attrs": [
"temperature"
]
},
"expires": "2040-01-01T14:00:00.00Z",
"throttling": 5
}
EOF
In the subscription case, the resource id is generated server-side (with difference to the entities endpoint, where the id is decided client-side).
It would be nice to return it in the POST call, is there any way to do this?
Subscription ID is retrieved in Location header in the response to the subscription creation request, eg:
Location: /v2/subscriptions/5b991dfa12f473cee6651a1a
More details in the NGSIv2 API specification (check "Create Subscription" section).
I'm trying to use Orion notification to send SMS with Plivo.
This is how I send an SMS directly with Plivo:
curl -X POST https://api.plivo.com/v1/Account/MAMDA5ZDJIMDM1/Message/ -L -u MAMDA5ZDJIM:YzhiNDJjODNhNDkxMjhiYTgxZD -H 'Content-Type: application/json' -d #- <<EOF
{
"src": "0039414141414",
"dst": "0039414747111",
"text": "test SMS"
}
EOF
How should I encode it in Orion? I tried:
curl localhost:1026/v2/subscriptions -s -S --header 'Content-Type: application/json' --header 'Accept: application/json' -d #- <<EOF
{
"description": "A subscription to get info about WS_UPPA_Sensor2",
"subject": {
"entities": [
{
"id": "Sensor1",
"type": "SensingDevice"
}
],
"condition": {
"attrs": [
"temperature"
]
}
},
"notification": {
"httpCustom": {
"url": "https://api.plivo.com/v1/Account/MAMDA5ZDJIMDM1NZVMZD/Message/",
"headers": {
"Authorization": "Basic TUFNREE1WkRKSU1ETTFOWlZNWkQ6WXpoaU5ESmpPRE5oTkRreE1qaGlZVGd4WkRkaE5qYzNPV1ZsTnpZMA=="
},
"payload": "{%22src%22%3A%2200393806412092%22%2C%22dst%22%3A%2200393806412093%22%2C%22text%22%3A%22test%20SMS%20from%20Waziup%22}"
},
"attrs": [
"temperature"
]
},
"expires": "2040-01-01T14:00:00.00Z",
"throttling": 5
}
EOF
Is there another way than percent encoding?
URL encoding (I understand is the one you refer by "percent encoding") is the only one which have an special treatment in custom notifications (details described as part of the Orion documentation).
In fact, taking into account the existing one is complete (I mean, any text can be expressed in the terms of URL encoding) there is no need of adding any other.
I have this issue in a C#-based project, but I can reproduce it with curl as well. The code was working a few days ago but now it isn't and I'm pretty sure I haven't changed it.
I have a payment that has been authorized and I have its ID, which is correct (when I close the transaction with their online tool I get AUTHORIZATION_ALREADY_COMPLETED instead of Server 500 error).
Here's what I do with curl to repro it, sensitive info redacted:
// check if the AUTHIDHERE code is correct:
curl -v -X GET https://api.paypal.com/v1/payments/authorization/AUTHIDHERE -H "Content-Type:application/json" -H "Authorization:Bearer BEARER123"
the above call works and returns:
{
"id": "AUTHIDHERE",
"create_time": "2013-07-17T21:17:58Z",
"update_time": "2013-07-17T21:18:00Z",
"state": "authorized",
"amount": {
"total": "1.35",
"currency": "USD",
"details": {
"subtotal": "1.35"
}
},
"parent_payment": "PAY-SOMELONGIDHERE",
"valid_until": "2013-08-15T21:17:58Z",
"links": ...whole bunch here]}
}
then I call the capture
curl -v https://api.paypal.com/v1/payments/authorization/AUTHIDHERE/capture \
-H "Content-Type:application/json" -H "Authorization:Bearer BEARER123" \
-d '{"amount":{"currency":"USD","total":"1.32"},"is_final_capture":true}
and I get this with HTTP 500 status:
{
"name": "INTERNAL_SERVICE_ERROR",
"message": "An internal service error has occurred",
"information_link": "https://developer.paypal.com/webapps/developer/docs/api/#INTERNAL_SERVICE_ERROR",
"debug_id": "7edadeba20509"
}
Some other debug_id values are: 062fc6964d9a8, 6eebc751504eb
quick update: interestingly they all failed in the underlying acquirer call - trying to figure out what went wrong.
Are these all debug_ids associated with the same authorization_id ?