Curl and executeCommandLine

Setup, Configuration and Use Scripts & Rules
,
1

Hello,

I am banging my head all day with this.
I can execute the following curl command from the cli just fine

curl -sSH "Authorization: Bearer XXXXXXXXXX" -H "Accept:application/json" -H "Content-Type:application/json" -d '{"message": "testing", "destinations": ["XXXXXXXX"]}' https://api.enco.io/sms/1.0.0/sms/outboundmessages

When I have the same command in a rule it does not work

var String json2 = executeCommandLine('curl -sSH "Authorization: Bearer XXXXXXXXXXXXX" -H "Accept:application/json" -H "Content-Type:application/json" -d \'{"message": "testing", "destinations": ["XXXXXXXXX"]}\' https://api.enco.io/sms/1.0.0/sms/outboundmessages', 5000)

Basically the command works and the request reaches the server and I get the following in the response in the openhab.log

{"fault":{"code":900902,"message":"Missing Credentials","description":"Required OAuth credentials not provided. Make sure your API invocation call has a header: \"Authorization: Bearer ACCESS_TOKEN\""}}

You can clearly see that I am sending the bearer token !

I also put the curl command in a file and I execute it with curl as a script and it also works! But I am not sure if I can pass a variable to an external script

var String json2 = executeCommandLine('curl /etc/openhab2/scripts/curl_script.sh',5000)

Can anybody help ?

Edit: Some more information. I added -v to get more information on what I sent and I see this

 POST /sms/1.0.0/sms/outboundmessages HTTP/1.1
> User-Agent: curl/7.38.0
> Host: api.enco.io
> "Authorization: Bearer XXXXXXXXXXX"
> Accept:application/json
> Content-Type:application/json
> Content-Length: 50

After testing I see that it is the spaces in the Authorization header that result in that header being sent within the quotes. But why ? How can I remove those quotes ?

2

Finally I changed my approach. Rather that executing directly the command I created a script and I pass the variable (bearer token)

Here is the rules line

var String sendsms = executeCommandLine("/etc/openhab2/scripts/SmokeAlarmON_sendSMS.sh " +token,5000)

and here is the script. The variable is passed by using $1

curl -svSH "Authorization: Bearer $1" -H "Accept:application/json" -H "Content-Type:application/json" -d '{"message": "FIRE DETECTED!!!", "destinations": ["+XXXXXXXX"]}' --url https://api.enco.io/sms/1.0.0/sms/outboundmessages

I think the command is buggy unless I am missing something here

3

I just had a look at the executeCommandLine implementation and there seems to be a second way to pass arguments to prevent issues.

Instead of using spaces to separate arguments you can also use @@. I think the current code is based on the openHAB 1 Exec plugin which also has some documentation about issues with passing arguments. It will not look nice with all those @@ though. :frowning:

4

Oh believe me I have tried … with and without @@ and all possible combinations i could think of. In the end I pass the argument I want but it is always within quotes and I do not understand why

The moment I add spaces even in other headers they are put within quotes which I find wrong. In any case my workaround works so I am happy :slight_smile:

5

That’s too bad. :frowning:

It would be nice if custom headers like the “Authorization: Bearer XXX” were possible with the normal sendHttpPostRequest script commands. That way you would not have a need for curl with all those issues at all. It would also be platform independent.

1 Like
6

I use a Thing and a Script to get my curl script to work. FWIW.

Thing

Thing exec:command:getTagList [command="/etc/openhab2/scripts/getTagList.sh", interval=900, timeout=30, autorun=true]

Script

#!/bin/bash

curl -s -X POST -H "Content-Type: application/json; charset=utf-8" -H "Authorization: bearer xxx-xxx-xxx-xxx-xxx" -d "" "http://mytaglist.com/ethClient.asmx/GetTagList"
1 Like
7

I’ve recently discovered that the sendHttpGetRequest also does not support Headers, this is different than what is allowed in a http item definition. For functionality that already exists in a different form I’d think it could be implemented rather directly and would correct many of these curl/exec/script workarounds.