Bug #5755
API request on /api/channel/grid with filter dont get entry by uuid
0%
Description
curl -s --digest -d 'filter=[{"type":"string","value":"zdf_neo HD","field":"name"}]' 'http://xxx:[email protected]:9981/api/channel/grid' |jq
gets a
{
"entries": [
{
"uuid": "67d479b9506a14392072eb3a31afbb65",
"enabled": true,
"autoname": true,
"name": "zdf_neo HD",
"number": 200,
"icon": "file:////etc/tvheadend/picons/snp/zdfneohd.png",
"icon_public_url": "imagecache/1",
"epgauto": false,
"epglimit": 0,
"epggrab": [],
"dvr_pre_time": 0,
"dvr_pst_time": 0,
"epg_running": -1,
"services": [
"b8d5c3454828a8a52cf52fb0973d850c"
],
"tags": [
"def14a5a50ac2c5f68b6aae4be69db55",
"4f41008112b51656d4630c363ffc44df",
"edbb0be39a72646e215aa085cba5e66e",
"403c7bf2162c70ad14774ec07856188d",
"9243e0dfb4862d42351668e81f3df212"
],
"bouquet": ""
}
],
"total": 1
}
curl -s --digest -d 'filter=[{"type":"string","value":"67d479b9506a14392072eb3a31afbb65","field":"uuid"}]' 'http://xxx:[email protected]:9981/api/channel/grid' |jq
{
"entries": [],
"total": 0
}
So i guess there is something wrong in the API-src?
History
Updated by Joe User about 5 years ago
Updated by uuid is special case.
use:
curl -s --digest -d 'uuid=67d479b9506a14392072eb3a31afbb65' 'http://xxx:[email protected]:9981/api/idnode/load' |jq or curl -s --digest 'http://xxx:[email protected]:9981/api/idnode/load?uuid=67d479b9506a14392072eb3a31afbb65' |jq
Updated by Maik Fuss about 5 years ago
Updated by Hm, seems there is still something wrong:
curl -s --digest -d 'uuid=67d479b9506a14392072eb3a31afbb65' 'http://xxx:[email protected]:9981/api/idnode/load' <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <HTML><HEAD> <TITLE>400 Bad Request</TITLE> </HEAD><BODY> <H1>400 Bad Request</H1> </BODY></HTML>
BUT...
curl -s --digest 'http://xxx:[email protected]:9981/api/idnode/load?uuid=67d479b9506a14392072eb3a31afbb65'
...works
Any ideas why curl with --data wont work?
Updated by Maik Fuss about 5 years ago
So it seems to be a TVH-version problem?
Can u show the curl -v output and the tvh-version?
My is 4.3-1833~g6fbb30d03-dirty
curl -v -s --digest -d 'uuid=67d479b9506a14392072eb3a31afbb65' 'http://xxx:[email protected]:9981/api/idnode/load' * Trying 192.168.81.7:9981... * TCP_NODELAY set * Connected to 192.168.81.7 (192.168.81.7) port 9981 (#0) * Server auth using Digest with user 'xxx' > POST /api/idnode/load HTTP/1.1 > Host: 192.168.81.7:9981 > User-Agent: curl/7.65.0 > Accept: */* > Content-Length: 0 > Content-Type: application/x-www-form-urlencoded > * Mark bundle as not supporting multiuse < HTTP/1.1 400 Bad Request < Server: HTS/tvheadend < Cache-Control: no-cache < Connection: Keep-Alive < Content-Type: text/html < Content-Length: 155 < <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <HTML><HEAD> <TITLE>400 Bad Request</TITLE> </HEAD><BODY> <H1>400 Bad Request</H1> </BODY></HTML> * Connection #0 to host 192.168.81.7 left intact
Updated by Joe User about 5 years ago
I am using 4.3 also.
I do not see any digest info in your output???
from my output:
Authorization: Digest username="xxxxxx", realm="tvheadend", nonce="Fq2i34ttQYwpq58n3JVgEjciykgG1e14sTneqoQex14=", uri="/api/idnode/load", cnonce="NWQ1NmIyOTI0OTE3OTEwZTk1Mjc2Y2I2OWEzMTA0ZGI=", nc=00000001, qop=auth, response="da1784f72add8ffa8facf824fc147f0a", opaque="V4Imr/9OxRDaQXU362UR5IGCQKAwzGv2/AMx7583A+0="
The only way I can reproduce your results is if I start tvheadend with the --noacl option. Then it still works for the GET, but not POST when --digest is used.
Are you using the --noacl option? What are your settings in tvheadend for Configuration->General->Base->Authentication type: ??
Updated by Maik Fuss about 5 years ago
Was "digest", now it is "both".
TVH get started with: /usr/bin/tvheadend -f -C -u tvh-g video -c /etc/tvheadend --syslog --debug api
hmmmm
Updated by Joe User about 5 years ago
You can try to add to trace "http" and possibly "access" and "idnode" to see if that leads to more info.
It is interesting that (at least with noacl for me) --data works with channel grid but not idnode.
Updated by Jaroslav Kysela about 5 years ago
Updated by It seems that curl does the first request with digest auth without any argments:
> Content-Length: 0 > Content-Type: application/x-www-form-urlencoded
If the result is ok, then the second (correct) request is sent. But idnode/load requires the argument thus error 400 is returned. The question is, why curl behaves in this way.
Updated by Jaroslav Kysela about 5 years ago
Or just use the tvh-json.py tool (https://github.com/tvheadend/tvheadend/blob/master/lib/api/python/tvh-json.py):
TVH_API=http://localhost:9981/api TVH_USER=admin TVH_PASS=admin ./tvh-json.py export c4a0588c687d24dc59a8ade7fe2b94c8
Updated by Em Smith about 5 years ago
Updated by Re: content-length 0, I think this explains it: https://github.com/curl/curl/issues/3385
When using the Digest authentication, there can be no such header in the first outgoing request. Digest is a challenge-response kind of auth and it first needs a 401 (or 407) response back (containing the necessary nonce), and only then can curl send a Authorization: header.
So, I assume curl is sending zero length since it is expecting an Unauthorized 401 response since we've explicitly said "digest", and it avoids wasting bandwidth on the send.
The older version of the spec RFC 2617 S3.5 has an example.
https://tools.ietf.org/html/rfc2617#page-18
Updated by Jaroslav Kysela about 5 years ago
- Status changed from New to Fixed
Fixed in v4.3-1841-g707b82b9c . Other API calls should be reviewed, too.