Eclipse Hono - 401 Unauthorized Error (Even when the credentials are correct) - eclipse-hono

I am using the following commands to create a tenant in Eclipse Hono
$ curl -X POST -i -H 'Content-Type: application/json' -d '{"tenant-id": "testenant1"}'
http://localhost:28080/tenant
HTTP/1.1 201 Created
location: /tenant/testenant1
content-length: 0
Registering a device in the tenant using the below command
curl -X POST -i -H 'Content-Type: application/json' -d '{"device-id": "1"}'
http://localhost:28080/registration/testenant1
HTTP/1.1 201 Created
location: /registration/testenant1/1
content-length: 0
Authenticating the registered device using the below command
$ curl -i -X POST -H 'Content-Type: application/json' --data-binary '{
"device-id": "1",
"type": "hashed-password",
"auth-id": "newAuth1",
"secrets": [{
"pwd-plain": "mylittle"
}]
}' http://localhost:28080/credentials/testenant1
HTTP/1.1 201 Created
location: /credentials/testenant1/newAuth1/hashed-password
content-length: 0
When I try to send data to this registered and Authenticated device using the below command.
curl -X POST -i -u newAuth1#testenant1:mylittle -H 'Content-Type: application/json' -d '{"temp": 23.07, "hum": 45.85}' http://localhost:8080/telemetry
HTTP/1.1 401 Unauthorized
content-length: 0
I will be getting 401 Unauthorized error (I am expecting 503 - Service Unavailable error).
Note: I was using the similar approach before and it was working perfectly fine. I am not sure if I am missing something.

You are using wrong credentials when POSTing the data. The username always consists of the auth-id and the tenant-id separated by #.
You need to use:
curl -X POST -i -u newAuth1#testenant1:mylittle -H 'Content-Type: application/json' -d '{"temp": 23.07, "hum": 45.85}' http://localhost:8080/telemetry
That said, based on the URIs you are using for registering the tenant and device, you seem to be using quite an old version of Hono. Please consider upgrading to the latest version (1.1.1) in order to take advantage of recent development/bug fixing ...

Related

Evaluate parameters in curl API call

I got a curl that had to be rewritten recently, looking like this:
cmd=$("curl https://exampleurl/query -sX POST -H Authorization: Bearer $ingestToken -H Content-Type: application/json -H Accept: application/json -H Accept-Charset: utf-8 -d {\"queryString\":\"$query\", \"start\": \"$start_time\", \"end\": \"$stop_time
This returns the error "No such file or directory"
I got a working version using eval $cmd, and I have compared the two curl strings generated by each method, and they look the same. Any ideas what is causing the error in this case?

How do I interact with the hackage API using curl?

There are sparsely documented methods here. This page just mentions there's an API, and links to the hackage-security library which 5min poking around doesn't help me figure out how to form an http request to the (which?) server
The following just get me a stub html file:
$ curl -H "Accept: application/json" hackage.org/package/aeson/
$ curl -H "Accept: application/json" hackage.org/api/package/aeson/
old related: Does Hackage have an API?
You have the base URL wrong. It's https://hackage.haskell.org/.
curl -H 'Accept: application/json' https://hackage.haskell.org/package/aeson
yields the output
{"0.1.0.0":"normal","0.10.0.0":"deprecated","0.11.0.0":"normal","0.11.1.0":"normal","0.11.1.1":"normal","0.11.1.2":"normal","0.11.1.3":"normal","0.11.1.4":"normal","0.11.2.0":"normal","0.11.2.1":"normal","0.11.3.0":"normal","0.2.0.0":"normal","0.3.0.0":"normal","0.3.1.0":"normal","0.3.1.1":"normal","0.3.2.0":"normal","0.3.2.1":"normal","0.3.2.10":"normal","0.3.2.11":"normal","0.3.2.12":"normal","0.3.2.13":"normal","0.3.2.14":"normal","0.3.2.2":"normal","0.3.2.3":"normal","0.3.2.4":"normal","0.3.2.5":"normal","0.3.2.6":"normal","0.3.2.7":"normal","0.3.2.8":"normal","0.3.2.9":"normal","0.4.0.0":"normal","0.4.0.1":"normal","0.5.0.0":"normal","0.6.0.0":"normal","0.6.0.1":"normal","0.6.0.2":"normal","0.6.1.0":"normal","0.6.2.0":"normal","0.6.2.1":"normal","0.7.0.0":"deprecated","0.7.0.1":"deprecated","0.7.0.2":"deprecated","0.7.0.3":"deprecated","0.7.0.4":"normal","0.7.0.5":"deprecated","0.7.0.6":"normal","0.8.0.0":"deprecated","0.8.0.1":"deprecated","0.8.0.2":"normal","0.8.1.0":"normal","0.8.1.1":"normal","0.9.0.0":"normal","0.9.0.1":"normal","1.0.0.0":"normal","1.0.1.0":"normal","1.0.2.0":"normal","1.0.2.1":"normal","1.1.0.0":"normal","1.1.1.0":"normal","1.1.2.0":"normal","1.2.0.0":"normal","1.2.1.0":"normal","1.2.2.0":"normal","1.2.3.0":"normal","1.2.4.0":"normal","1.3.0.0":"normal","1.3.1.0":"normal","1.3.1.1":"normal","1.4.0.0":"normal","1.4.1.0":"normal","1.4.2.0":"normal","1.4.3.0":"normal","1.4.4.0":"normal","1.4.5.0":"normal","1.4.6.0":"normal","1.4.7.0":"normal","1.4.7.1":"normal","1.5.0.0":"normal","1.5.1.0":"normal","1.5.2.0":"normal","1.5.3.0":"normal","1.5.4.0":"normal","1.5.4.1":"normal","1.5.5.0":"normal","1.5.5.1":"normal","1.5.6.0":"normal","2.0.0.0":"normal","2.0.1.0":"normal","2.0.2.0":"normal","2.0.3.0":"normal"}

{"error":"incident is missing"} when using PATCH or PUT to update an incident

When I try to submit a PATCH or PUT request to update an incident, I get:
{"error":"incident is missing"}
Here is my request:
curl --location --request PATCH 'https://api.statuspage.io/v1/pages/xxxx/incidents/lf7****nf2?api_key=xxx' \
--header 'Content-Type: application/json' \
--data-raw '{
"incident": "Requests Failed (500)",
"status": "identified"
}'
I have also tried with Authorization: Oauth approach
I am able to create an incident and am also able to list them, so I am unsure what is going on.
I am following https://developer.statuspage.io/#operation/putPagesPageIdIncidentsIncidentId and https://developer.statuspage.io/#operation/patchPagesPageIdIncidentsIncidentId
What am I missing?
Any advice is much appreciated
i need to use https://doers.statuspage.io/api/v1/
curl https://api.statuspage.io/v1/pages/qfn30z5r6s5h/incidents/21w20wsvz5kv.json \
-H "Authorization: OAuth 2a7b9d4aac30956d537ac76850f4d78de30994703680056cc103862d53cf8074" \
-X DELETE

Value of resource when subscribing to webhook notifications using graph api

I am trying to subscribe to the Microsoft Graph API for webhook notifications to track changes in a folder in a SharePoint Document library. I have app only access to this SharePoint site and am able to see and download all the content within the drive associate with the document library. I can also upload new files using API.
When I make the call to the subscription endpoint I receive an internal server error.
Here is the request I make
curl -X POST \
https://graph.microsoft.com/v1.0/drive/root/subscriptions \
-H 'Accept: */*' \
-H 'Accept-Encoding: gzip, deflate' \
-H 'Authorization: Bearer TOKEN' \
-H 'Cache-Control: no-cache' \
-H 'Connection: keep-alive' \
-H 'Content-Length: 303' \
-H 'Content-Type: application/json' \
-H 'Host: graph.microsoft.com' \
-d '{
"changeType": "updated",
"notificationUrl": "https://c.ngrok.io/sp-hook",
"resource": "drives/{{DRIVE-ID}}/root",
"expirationDateTime": "2019-09-18T11:23:00.000",
"clientState": "test"
}'
Here is the response I get
{
"error": {
"code": "InternalServerError",
"message": "Unable to find target address",
"innerError": {
"request-id": "c8e66e50-5b94-4593-88d5-3111e5c5c6c7",
"date": "2019-09-13T09:50:12"
}
}
}
I believe this could be due to a wrong resource value, but I could not locate documentation about what the value of resource should be. I have gone over: https://learn.microsoft.com/en-us/graph/webhooks and https://learn.microsoft.com/en-us/graph/api/resources/webhooks?view=graph-rest-1.0. All the documentation seems to point to a resource value of "me/drives/root", however with app only access a my site is not defined and so the call fails.
These are the different values for resource that I have tried within the request json body
drives('DRIVE-ID')/root
drives/DRIVE-ID/root
DRIVE-ID
drive/DRIVE-ID
drive/DRIVE-ID/root
me/drive("DRIVE-ID")/root
DRIVE-ITEM-ID-FOR-ROOT
Different documentation seems to point to different subscription endpoints. These are the different endpoints I have tried
https://graph.microsoft.com/v1.0/subscriptions
https://graph.microsoft.com/v1.0/drive/root/subscriptions
https://graph.microsoft.com/beta/drives/{{drive-id}}/root/subscriptions
The error also made me suspect that during subscription registration, it was not able to find my webhook. However having tested the endpoint I am sure it is accessible.
Additional information
I use the following call to get the drive id for a sharepoint site
curl -X GET \
'https://graph.microsoft.com/v1.0/sites/SITE-ID/drive' \
-H 'Accept: */*' \
-H 'Accept-Encoding: gzip, deflate' \
-H 'Authorization: Bearer TOKEN' \
-H 'Cache-Control: no-cache' \
-H 'Connection: keep-alive' \
-H 'Content-Type: application/json' \
-H 'Host: graph.microsoft.com' \
I see you are performing POST on https://graph.microsoft.com/v1.0/drive/root/subscriptions endpoint
Expected subscriptions endpoint is https://graph.microsoft.com/v1.0/subscriptions
Please note there is no '/drive/root' in the URL path.

Linux curl post request and Error 417 but sudo success?

My service is deployed in docker,the exposed nginx port is 18082;service port is 38087,and I tried both.
while I use command
curl -i -X POST -H 'content-type: text/json' -d #post.json \
http://127.0.0.1:18082/youtu/openliveapi/livedetectfour
return 417
HTTP/1.1 417 Expectation failed
Server: squid/2.7.STABLE9
Date: Tue, 15 Aug 2017 11:57:04 GMT
Content-Type: text/html
Content-Length: 1436
X-Squid-Error: ERR_INVALID_REQ 0
X-Cache: MISS from SK-SQUIDDEV-118
X-Cache-Lookup: NONE from SK-SQUIDDEV-118:8080
Connection: close
But when I add sudo in the front,it return success.
HTTP/1.1 100 Continue
HTTP/1.1 200 OK Server: openresty/1.9.15.1
I really do search and knew while curl post over 1024 bytes,it will first send
expect 100-continue.if server don't support that request, it will return 417 error.
then how can sudo succsess,maybe It is related to nginx mechanism,I'm not familiar with that.thanks.
Since you are using proxy in your corporate setup and the proxy might be insert in your user's bash profile. You can do 3 things
Update ~/.bash_profile or ~/.bashrc
Remove the proxy from your profile and you won't need the proxy
Unset the variables
You can unset the variables before the call
unset http_proxy
unset https_proxy
curl -i -X POST -H 'content-type: text/json' -d #post.json \ http://127.0.0.1:18082/youtu/openliveapi/livedetectfour
Blank the variables for the call
You can set the variables just for that one curl call
http_proxy= https_proxy= curl -i -X POST -H 'content-type: text/json' -d #post.json \ http://127.0.0.1:18082/youtu/openliveapi/livedetectfour

Resources