Re: [PATCH V2 uhttpd] ubus: add new RESTful API
On 08.08.2020 01:47, Andre Valentin wrote:
I'm just experimenting a bit with the patch.
There were multiple this:
You need to reply to all, this is public stuff potentially affecting
all OpenWrt users.
1)
I habe some mips routers and an ipq806x based router.
After I added that patch, I cannot authenticate on via json-rpc on the ipq806x.
I remove the patch, rebuild. It works again.
This does not seem to happen on the mips routers.
I can't think of any explanation for this. Platform or endianess should
not affect ubus behaviour.
Maybe you just missed something in your rpcd confguration? Acl stuff?
I can't say anything without providing more debugging info.
2)
Authentication over rest-api works fine:
"jsonrpc": "2.0",
"id": 1,
"result": {
"ubus_rpc_session": "3653e64078f1f6ebaf4803e67c18fa2a",
"timeout": 300,
Perfect.
But if I try to subscribe I get this error:
GET /ubus/subscribe/hostapd.wap-knet1 HTTP/1.1
Host: ap-av-grwz
User-Agent: curl/7.64.0
Accept: */*
Authorization: Bearer 3653e64078f1f6ebaf4803e67c18fa2a
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Connection: Keep-Alive
Connection: Keep-Alive
< Transfer-Encoding: chunked
Transfer-Encoding: chunked
< Keep-Alive: timeout=20
Keep-Alive: timeout=20
< Content-Type: application/json
Content-Type: application/json
<
* Connection #0 to host ap-av-grwz left intact
{"code":-13,"message":"Permission denied"}
I do not have an idea what's wrong, perhaps you have an idea?
Sure, it means you / your session is not allowed to subscribe. See:
if (!conf.ubus_noauth && !uh_ubus_allowed(sid, path, data.method)) {
err = ERROR_ACCESS;
goto error;
}
Until we add acl.d rule for allowing subscription access it's possible
only with ubus_noauth. I'm going to work on proper / new acl.d as soon
as I get this patch accepted.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH V2 uhttpd] ubus: add new RESTful API
Hi!
Am 04.08.20 um 18:40 schrieb Rafał Miłecki:
> On 04.08.2020 09:43, Andre Valentin wrote:
>> Am 03.08.20 um 07:49 schrieb Rafał Miłecki:
>>> On 31.07.2020 13:02, Andre Valentin wrote:
this is really great stuff. It would help me to get forward with my wifi
controller.
Could it be possible to subsribe to multiple sources to limit the
connections to ubus?
2 SSIDs with 2.4 ad 5GHz would me 4 concurrent channels if I understand
right.
>>>
>>> I'm happy someone finds it useful!
>>>
>>> If you mean hostapd.* objects, that's right. That would require you to
>>> use:
>>> /ubus/subscribe/hostapd.wlan0
>>> /ubus/subscribe/hostapd.wlan0-1
>>> /ubus/subscribe/hostapd.wlan1
>>> /ubus/subscribe/hostapd.wlan1-1
>>>
>>> For subscribing to multiple objects we would need to:
>>> 1. Stick to GET due to the way EventSource works
>>> 2. Pick some more generic URL
>>> 3. Adjust output format ("event" and "data" fields)
>>>
>>> So my guess would be something like:
>>>
>>> $ curl
>>> http://192.168.1.1/ubus/subscribe?path=hostapd.wlan0&path=hostapd.wlan1
>>
>> Good idea!
>>
>>> event: hostapd.wlan1 status
>>> data: {"count":5}
>>>
>>> event: hostapd.wlan0-1 status
>>> data: {"count":5}
>>>
>>> event: hostapd.wlan1 status
>>> data: {"count":7}
>>>
>>>
>>> Regarding parsing events stream, event names with spaces seem to be OK:
>>> https://html.spec.whatwg.org/multipage/server-sent-events.html#parsing-an-event-stream
>>> field value can use any scalar value other than line break char.
>>
>> Why do you need the status there, is it part of the standard?
>
> That was meant to separate object name from notification name.
>
OK, I understand.
>
>>> We should use some special character as separator of object name and
>>> notification name. It must be something that ubus doesn't use in any of
>>> them. Should space be OK? Or should we use some more fancy char? I
>>> quickly tested space and it seems to work well in Firefox and Chromium.
>>
>> Oh, I'm nut sure. But I think space is fine.
>>
>> Did you use a special uhttpd version. I couldn't apply your patch to the
>> uhttpd in openwrt master.
>
> There are few more uhttpd pending patches that I sent, see:
> https://patchwork.ozlabs.org/project/openwrt/list/?series=&submitter=5824&state=*&q=uhttpd&archive=&delegate=
Okay, will give it a try again at the weekend.
Kind regards,
André
smime.p7s
Description: S/MIME Cryptographic Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH V2 uhttpd] ubus: add new RESTful API
On 04.08.2020 09:57, Jo-Philipp Wich wrote:
Regarding parsing events stream, event names with spaces seem to be OK:
https://html.spec.whatwg.org/multipage/server-sent-events.html#parsing-an-event-stream
To me it feels quirky to separate the path and the type of the event by space.
Personally I'd only report the type as "event:" and move the source path into
the JSON data portion,
This seems to break hierarchy. I see correct hierarchy as:
1. Object
2. Notification type
3. Notification data
If we put type in "event:" and object path and notification data in
"data:" it seems unnatural.
> or even omit it entirely.
I'm sure one may need to distinct notifications from wlan0 vs. wlan1.
That's probably not an option unless I missed something.
Considering the design of the client side API:
eventSource.addEventListener(type, handler);
Most use-cases probably want to register a handler for a specific event type,
e.g. "status", and not N handlers to handle the different object path
variations, so given the subscribe examples in the previous mail:
eventSource.addEventListener("status", (ev) => { ... })
instead of
eventSource.addEventListener("hostapd.wlan0 status", (ev) => { ... })
eventSource.addEventListener("hostapd.wlan0-1 status", (ev) => { ... })
eventSource.addEventListener("hostapd.wlan1 status", (ev) => { ... })
eventSource.addEventListener("hostapd.wlan1-1 status", (ev) => { ... })
I see how it simplifies JavaScript code though so I'm confused.
Should we maybe totally drop "event:" and just put everything (object
path, event type, data) in "data:"?
Granted, one could use the `onmessage` event to implement a catch-all handler
which is then filtering and dispatching according to the type, but even then
string operations like split(), indexOf(), regex matches or similar would be
required to match event types, that feels unelegant and not very performant.
I'm not sure if "message" event fires for *named* events (event: foo).
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH V2 uhttpd] ubus: add new RESTful API
On 04.08.2020 09:43, Andre Valentin wrote:
Am 03.08.20 um 07:49 schrieb Rafał Miłecki:
On 31.07.2020 13:02, Andre Valentin wrote:
this is really great stuff. It would help me to get forward with my wifi
controller.
Could it be possible to subsribe to multiple sources to limit the connections
to ubus?
2 SSIDs with 2.4 ad 5GHz would me 4 concurrent channels if I understand right.
I'm happy someone finds it useful!
If you mean hostapd.* objects, that's right. That would require you to
use:
/ubus/subscribe/hostapd.wlan0
/ubus/subscribe/hostapd.wlan0-1
/ubus/subscribe/hostapd.wlan1
/ubus/subscribe/hostapd.wlan1-1
For subscribing to multiple objects we would need to:
1. Stick to GET due to the way EventSource works
2. Pick some more generic URL
3. Adjust output format ("event" and "data" fields)
So my guess would be something like:
$ curl http://192.168.1.1/ubus/subscribe?path=hostapd.wlan0&path=hostapd.wlan1
Good idea!
event: hostapd.wlan1 status
data: {"count":5}
event: hostapd.wlan0-1 status
data: {"count":5}
event: hostapd.wlan1 status
data: {"count":7}
Regarding parsing events stream, event names with spaces seem to be OK:
https://html.spec.whatwg.org/multipage/server-sent-events.html#parsing-an-event-stream
field value can use any scalar value other than line break char.
Why do you need the status there, is it part of the standard?
That was meant to separate object name from notification name.
We should use some special character as separator of object name and
notification name. It must be something that ubus doesn't use in any of
them. Should space be OK? Or should we use some more fancy char? I
quickly tested space and it seems to work well in Firefox and Chromium.
Oh, I'm nut sure. But I think space is fine.
Did you use a special uhttpd version. I couldn't apply your patch to the uhttpd
in openwrt master.
There are few more uhttpd pending patches that I sent, see:
https://patchwork.ozlabs.org/project/openwrt/list/?series=&submitter=5824&state=*&q=uhttpd&archive=&delegate=
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH V2 uhttpd] ubus: add new RESTful API
Hi,
> Regarding parsing events stream, event names with spaces seem to be OK:
> https://html.spec.whatwg.org/multipage/server-sent-events.html#parsing-an-event-stream
To me it feels quirky to separate the path and the type of the event by space.
Personally I'd only report the type as "event:" and move the source path into
the JSON data portion, or even omit it entirely.
Considering the design of the client side API:
eventSource.addEventListener(type, handler);
Most use-cases probably want to register a handler for a specific event type,
e.g. "status", and not N handlers to handle the different object path
variations, so given the subscribe examples in the previous mail:
eventSource.addEventListener("status", (ev) => { ... })
instead of
eventSource.addEventListener("hostapd.wlan0 status", (ev) => { ... })
eventSource.addEventListener("hostapd.wlan0-1 status", (ev) => { ... })
eventSource.addEventListener("hostapd.wlan1 status", (ev) => { ... })
eventSource.addEventListener("hostapd.wlan1-1 status", (ev) => { ... })
Granted, one could use the `onmessage` event to implement a catch-all handler
which is then filtering and dispatching according to the type, but even then
string operations like split(), indexOf(), regex matches or similar would be
required to match event types, that feels unelegant and not very performant.
~ Jo
signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH V2 uhttpd] ubus: add new RESTful API
Hi!
Am 03.08.20 um 07:49 schrieb Rafał Miłecki:
> On 31.07.2020 13:02, Andre Valentin wrote:
>> this is really great stuff. It would help me to get forward with my wifi
>> controller.
>> Could it be possible to subsribe to multiple sources to limit the
>> connections to ubus?
>> 2 SSIDs with 2.4 ad 5GHz would me 4 concurrent channels if I understand
>> right.
>
> I'm happy someone finds it useful!
>
> If you mean hostapd.* objects, that's right. That would require you to
> use:
> /ubus/subscribe/hostapd.wlan0
> /ubus/subscribe/hostapd.wlan0-1
> /ubus/subscribe/hostapd.wlan1
> /ubus/subscribe/hostapd.wlan1-1
>
> For subscribing to multiple objects we would need to:
> 1. Stick to GET due to the way EventSource works
> 2. Pick some more generic URL
> 3. Adjust output format ("event" and "data" fields)
>
> So my guess would be something like:
>
> $ curl http://192.168.1.1/ubus/subscribe?path=hostapd.wlan0&path=hostapd.wlan1
Good idea!
> event: hostapd.wlan1 status
> data: {"count":5}
>
> event: hostapd.wlan0-1 status
> data: {"count":5}
>
> event: hostapd.wlan1 status
> data: {"count":7}
>
>
> Regarding parsing events stream, event names with spaces seem to be OK:
> https://html.spec.whatwg.org/multipage/server-sent-events.html#parsing-an-event-stream
> field value can use any scalar value other than line break char.
Why do you need the status there, is it part of the standard?
> We should use some special character as separator of object name and
> notification name. It must be something that ubus doesn't use in any of
> them. Should space be OK? Or should we use some more fancy char? I
> quickly tested space and it seems to work well in Firefox and Chromium.
Oh, I'm nut sure. But I think space is fine.
Did you use a special uhttpd version. I couldn't apply your patch to the uhttpd
in openwrt master.
Kind regards,
André
smime.p7s
Description: S/MIME Cryptographic Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH V2 uhttpd] ubus: add new RESTful API
On Fri, 31 Jul 2020 at 14:35, Nicolas Pace wrote: > On 7/31/20 1:49 AM, Rafał Miłecki wrote: > > From: Rafał Miłecki > > > > Initial uhttpd ubus API was fully based on JSON-RPC. That restricted it > > from supporting ubus notifications that don't fit its model. > > > > Notifications require protocol that allows server to send data without > > being polled. There are two candidates for that: > > 1. Server-sent events > > I did a quick and dirty implementation of it some time ago, that works > with everything as it is. > You might want to check it out. > https://bugs.openwrt.org/index.php?do=details&task_id=2248 > > Still, eager to see this work done! My first initial implementation was also PHP based :) It didn't work well with lighttpd though as I had to disable buffering using server.stream-response-body That and looking for something more generic (not PHP based) made me look at uhttpd. -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH V2 uhttpd] ubus: add new RESTful API
On 31.07.2020 13:02, Andre Valentin wrote:
this is really great stuff. It would help me to get forward with my wifi
controller.
Could it be possible to subsribe to multiple sources to limit the connections
to ubus?
2 SSIDs with 2.4 ad 5GHz would me 4 concurrent channels if I understand right.
I'm happy someone finds it useful!
If you mean hostapd.* objects, that's right. That would require you to
use:
/ubus/subscribe/hostapd.wlan0
/ubus/subscribe/hostapd.wlan0-1
/ubus/subscribe/hostapd.wlan1
/ubus/subscribe/hostapd.wlan1-1
For subscribing to multiple objects we would need to:
1. Stick to GET due to the way EventSource works
2. Pick some more generic URL
3. Adjust output format ("event" and "data" fields)
So my guess would be something like:
$ curl http://192.168.1.1/ubus/subscribe?path=hostapd.wlan0&path=hostapd.wlan1
event: hostapd.wlan1 status
data: {"count":5}
event: hostapd.wlan0-1 status
data: {"count":5}
event: hostapd.wlan1 status
data: {"count":7}
Regarding parsing events stream, event names with spaces seem to be OK:
https://html.spec.whatwg.org/multipage/server-sent-events.html#parsing-an-event-stream
field value can use any scalar value other than line break char.
We should use some special character as separator of object name and
notification name. It must be something that ubus doesn't use in any of
them. Should space be OK? Or should we use some more fancy char? I
quickly tested space and it seems to work well in Firefox and Chromium.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH V2 uhttpd] ubus: add new RESTful API
On 7/31/20 1:49 AM, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> Initial uhttpd ubus API was fully based on JSON-RPC. That restricted it
> from supporting ubus notifications that don't fit its model.
>
> Notifications require protocol that allows server to send data without
> being polled. There are two candidates for that:
> 1. Server-sent events
I did a quick and dirty implementation of it some time ago, that works
with everything as it is.
You might want to check it out.
https://bugs.openwrt.org/index.php?do=details&task_id=2248
Still, eager to see this work done!
> 2. WebSocket
>
> The later one is overcomplex for this simple task so ideally uhttps ubus
> should support text-based server-sent events. It's not possible with
> JSON-RPC without violating it. Specification requires server to reply
> with Response object. Replying with text/event-stream is not allowed.
>
> All above led to designing new API that:
> 1. Uses GET and POST requests
> 2. Makes use of RESTful URLs
> 3. Uses JSON-RPC in cleaner form and only for calling ubus methods
>
> This new API allows:
> 1. Listing all ubus objects and their methods using GET /list
> 2. Listing object methods using GET /list/
> 3. Listening to object notifications with GET /subscribe/
> 4. Calling ubus methods using POST /call/
>
> JSON-RPC custom protocol was also simplified to:
> 1. Use "method" member for ubus object method name
>It was possible thanks to using RESTful URLs. Previously "method"
>had to be "list" or "call".
> 2. Reply with Error object on ubus method call error
>This simplified "result" member format as it doesn't need to contain
>ubus result code anymore.
>
> This patch doesn't break or change the old API. The biggest downside of
> the new API is no support for batch requests. It's cost of using RESTful
> URLs. It should not matter much as uhttpd supports keep alive.
>
> Example usages:
>
> 1. Getting all objects and their methods:
> $ curl http://192.168.1.1/ubus/list
> {
> "dhcp": {
> "ipv4leases": {
>
> },
> "ipv6leases": {
>
> }
> },
> "log": {
> "read": {
> "lines": "number",
> "stream": "boolean",
> "oneshot": "boolean"
> },
> "write": {
> "event": "string"
> }
> }
> }
>
> 2. Getting object methods:
> $ curl http://192.168.1.1/ubus/list/log
> {
> "read": {
> "lines": "number",
> "stream": "boolean",
> "oneshot": "boolean"
> },
> "write": {
> "event": "string"
> }
> }
>
> 3. Subscribing to notifications:
> $ curl http://192.168.1.1/ubus/subscribe/foo
> event: status
> data: {"count":5}
>
> 4. Calling ubus object method:
> $ curl -d '{
> "jsonrpc": "2.0",
> "id": 1,
> "method": "login",
> "params": {"username": "root", "password": "password" }
> }' http://192.168.1.1/ubus/call/session
> {
> "jsonrpc": "2.0",
> "id": 1,
> "result": {
> "ubus_rpc_session": "01234567890123456789012345678901",
> (...)
> }
> }
>
> $ curl -H 'Authorization: Bearer 01234567890123456789012345678901' -d '{
> "jsonrpc": "2.0",
> "id": 1,
> "method": "write",
> "params": {"event": "Hello world" }
> }' http://192.168.1.1/ubus/call/log
> {
> "jsonrpc": "2.0",
> "id": 1,
> "result": null
> }
>
> Signed-off-by: Rafał Miłecki
> ---
> V2: Use "Authorization" with Bearer for rpcd session id / token
> Treat missing session id as UH_UBUS_DEFAULT_SID
> Fix "result" format (was: "result":{{"foo":"bar"}})
> ---
> main.c | 8 +-
> ubus.c | 326 +++
> uhttpd.h | 5 +
> 3 files changed, 318 insertions(+), 21 deletions(-)
>
> diff --git a/main.c b/main.c
> index 26e74ec..73e3d42 100644
> --- a/main.c
> +++ b/main.c
> @@ -159,6 +159,7 @@ static int usage(const char *name)
> " -U file Override ubus socket path\n"
> " -a Do not authenticate JSON-RPC requests
> against UBUS session api\n"
> " -X Enable CORS HTTP headers on JSON-RPC
> api\n"
> + " -e Events subscription reconnection time
> (retry value)\n"
> #endif
> " -x string URL prefix for CGI handler, default is
> '/cgi-bin'\n"
> " -y alias[=path] URL alias handle\n"
> @@ -262,7 +263,7 @@ int main(int argc, char **argv)
> init_defaults_pre();
> signal(SIGPIPE, SIG_IGN);
>
> - while ((ch = getopt(argc, argv,
> "A:aC:c:Dd:E:fh:H:I:i:K:k:L:l:m:N:n:P:p:qRr:Ss:T:t:U:u:Xx:y:")) != -1) {
> + while ((ch = getopt(argc, argv,
> "A:aC:c:Dd:E:e:fh:H:I:i:K:k:L:l:m:N:n:P:p:qRr:Ss:T:t:U:u:Xx:y:")) != -1) {
> switch(ch) {
> #if
Re: [PATCH V2 uhttpd] ubus: add new RESTful API
Hi Rafel,
this is really great stuff. It would help me to get forward with my wifi
controller.
Could it be possible to subsribe to multiple sources to limit the connections
to ubus?
2 SSIDs with 2.4 ad 5GHz would me 4 concurrent channels if I understand right.
Kind regards,
André
Am 31.07.20 um 06:49 schrieb Rafał Miłecki:
> From: Rafał Miłecki
>
> Initial uhttpd ubus API was fully based on JSON-RPC. That restricted it
> from supporting ubus notifications that don't fit its model.
>
> Notifications require protocol that allows server to send data without
> being polled. There are two candidates for that:
> 1. Server-sent events
> 2. WebSocket
>
> The later one is overcomplex for this simple task so ideally uhttps ubus
> should support text-based server-sent events. It's not possible with
> JSON-RPC without violating it. Specification requires server to reply
> with Response object. Replying with text/event-stream is not allowed.
>
> All above led to designing new API that:
> 1. Uses GET and POST requests
> 2. Makes use of RESTful URLs
> 3. Uses JSON-RPC in cleaner form and only for calling ubus methods
>
> This new API allows:
> 1. Listing all ubus objects and their methods using GET /list
> 2. Listing object methods using GET /list/
> 3. Listening to object notifications with GET /subscribe/
> 4. Calling ubus methods using POST /call/
>
> JSON-RPC custom protocol was also simplified to:
> 1. Use "method" member for ubus object method name
>It was possible thanks to using RESTful URLs. Previously "method"
>had to be "list" or "call".
> 2. Reply with Error object on ubus method call error
>This simplified "result" member format as it doesn't need to contain
>ubus result code anymore.
>
> This patch doesn't break or change the old API. The biggest downside of
> the new API is no support for batch requests. It's cost of using RESTful
> URLs. It should not matter much as uhttpd supports keep alive.
>
> Example usages:
>
> 1. Getting all objects and their methods:
> $ curl http://192.168.1.1/ubus/list
> {
> "dhcp": {
> "ipv4leases": {
>
> },
> "ipv6leases": {
>
> }
> },
> "log": {
> "read": {
> "lines": "number",
> "stream": "boolean",
> "oneshot": "boolean"
> },
> "write": {
> "event": "string"
> }
> }
> }
>
> 2. Getting object methods:
> $ curl http://192.168.1.1/ubus/list/log
> {
> "read": {
> "lines": "number",
> "stream": "boolean",
> "oneshot": "boolean"
> },
> "write": {
> "event": "string"
> }
> }
>
> 3. Subscribing to notifications:
> $ curl http://192.168.1.1/ubus/subscribe/foo
> event: status
> data: {"count":5}
>
> 4. Calling ubus object method:
> $ curl -d '{
> "jsonrpc": "2.0",
> "id": 1,
> "method": "login",
> "params": {"username": "root", "password": "password" }
> }' http://192.168.1.1/ubus/call/session
> {
> "jsonrpc": "2.0",
> "id": 1,
> "result": {
> "ubus_rpc_session": "01234567890123456789012345678901",
> (...)
> }
> }
>
> $ curl -H 'Authorization: Bearer 01234567890123456789012345678901' -d '{
> "jsonrpc": "2.0",
> "id": 1,
> "method": "write",
> "params": {"event": "Hello world" }
> }' http://192.168.1.1/ubus/call/log
> {
> "jsonrpc": "2.0",
> "id": 1,
> "result": null
> }
>
> Signed-off-by: Rafał Miłecki
> ---
> V2: Use "Authorization" with Bearer for rpcd session id / token
> Treat missing session id as UH_UBUS_DEFAULT_SID
> Fix "result" format (was: "result":{{"foo":"bar"}})
> ---
> main.c | 8 +-
> ubus.c | 326 +++
> uhttpd.h | 5 +
> 3 files changed, 318 insertions(+), 21 deletions(-)
>
> diff --git a/main.c b/main.c
> index 26e74ec..73e3d42 100644
> --- a/main.c
> +++ b/main.c
> @@ -159,6 +159,7 @@ static int usage(const char *name)
> " -U file Override ubus socket path\n"
> " -a Do not authenticate JSON-RPC requests
> against UBUS session api\n"
> " -X Enable CORS HTTP headers on JSON-RPC
> api\n"
> + " -e Events subscription reconnection time
> (retry value)\n"
> #endif
> " -x string URL prefix for CGI handler, default is
> '/cgi-bin'\n"
> " -y alias[=path] URL alias handle\n"
> @@ -262,7 +263,7 @@ int main(int argc, char **argv)
> init_defaults_pre();
> signal(SIGPIPE, SIG_IGN);
>
> - while ((ch = getopt(argc, argv,
> "A:aC:c:Dd:E:fh:H:I:i:K:k:L:l:m:N:n:P:p:qRr:Ss:T:t:U:u:Xx:y:")) != -1) {
> + while ((ch = getopt(argc, argv,
> "A:aC:c:Dd:E:e:fh:H:I:i:K:k:L:l:m:N:n:P:p:qRr:Ss
[PATCH V2 uhttpd] ubus: add new RESTful API
From: Rafał Miłecki
Initial uhttpd ubus API was fully based on JSON-RPC. That restricted it
from supporting ubus notifications that don't fit its model.
Notifications require protocol that allows server to send data without
being polled. There are two candidates for that:
1. Server-sent events
2. WebSocket
The later one is overcomplex for this simple task so ideally uhttps ubus
should support text-based server-sent events. It's not possible with
JSON-RPC without violating it. Specification requires server to reply
with Response object. Replying with text/event-stream is not allowed.
All above led to designing new API that:
1. Uses GET and POST requests
2. Makes use of RESTful URLs
3. Uses JSON-RPC in cleaner form and only for calling ubus methods
This new API allows:
1. Listing all ubus objects and their methods using GET /list
2. Listing object methods using GET /list/
3. Listening to object notifications with GET /subscribe/
4. Calling ubus methods using POST /call/
JSON-RPC custom protocol was also simplified to:
1. Use "method" member for ubus object method name
It was possible thanks to using RESTful URLs. Previously "method"
had to be "list" or "call".
2. Reply with Error object on ubus method call error
This simplified "result" member format as it doesn't need to contain
ubus result code anymore.
This patch doesn't break or change the old API. The biggest downside of
the new API is no support for batch requests. It's cost of using RESTful
URLs. It should not matter much as uhttpd supports keep alive.
Example usages:
1. Getting all objects and their methods:
$ curl http://192.168.1.1/ubus/list
{
"dhcp": {
"ipv4leases": {
},
"ipv6leases": {
}
},
"log": {
"read": {
"lines": "number",
"stream": "boolean",
"oneshot": "boolean"
},
"write": {
"event": "string"
}
}
}
2. Getting object methods:
$ curl http://192.168.1.1/ubus/list/log
{
"read": {
"lines": "number",
"stream": "boolean",
"oneshot": "boolean"
},
"write": {
"event": "string"
}
}
3. Subscribing to notifications:
$ curl http://192.168.1.1/ubus/subscribe/foo
event: status
data: {"count":5}
4. Calling ubus object method:
$ curl -d '{
"jsonrpc": "2.0",
"id": 1,
"method": "login",
"params": {"username": "root", "password": "password" }
}' http://192.168.1.1/ubus/call/session
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"ubus_rpc_session": "01234567890123456789012345678901",
(...)
}
}
$ curl -H 'Authorization: Bearer 01234567890123456789012345678901' -d '{
"jsonrpc": "2.0",
"id": 1,
"method": "write",
"params": {"event": "Hello world" }
}' http://192.168.1.1/ubus/call/log
{
"jsonrpc": "2.0",
"id": 1,
"result": null
}
Signed-off-by: Rafał Miłecki
---
V2: Use "Authorization" with Bearer for rpcd session id / token
Treat missing session id as UH_UBUS_DEFAULT_SID
Fix "result" format (was: "result":{{"foo":"bar"}})
---
main.c | 8 +-
ubus.c | 326 +++
uhttpd.h | 5 +
3 files changed, 318 insertions(+), 21 deletions(-)
diff --git a/main.c b/main.c
index 26e74ec..73e3d42 100644
--- a/main.c
+++ b/main.c
@@ -159,6 +159,7 @@ static int usage(const char *name)
" -U file Override ubus socket path\n"
" -a Do not authenticate JSON-RPC requests
against UBUS session api\n"
" -X Enable CORS HTTP headers on JSON-RPC
api\n"
+ " -e Events subscription reconnection time
(retry value)\n"
#endif
" -x string URL prefix for CGI handler, default is
'/cgi-bin'\n"
" -y alias[=path] URL alias handle\n"
@@ -262,7 +263,7 @@ int main(int argc, char **argv)
init_defaults_pre();
signal(SIGPIPE, SIG_IGN);
- while ((ch = getopt(argc, argv,
"A:aC:c:Dd:E:fh:H:I:i:K:k:L:l:m:N:n:P:p:qRr:Ss:T:t:U:u:Xx:y:")) != -1) {
+ while ((ch = getopt(argc, argv,
"A:aC:c:Dd:E:e:fh:H:I:i:K:k:L:l:m:N:n:P:p:qRr:Ss:T:t:U:u:Xx:y:")) != -1) {
switch(ch) {
#ifdef HAVE_TLS
case 'C':
@@ -490,11 +491,16 @@ int main(int argc, char **argv)
case 'X':
conf.ubus_cors = 1;
break;
+
+ case 'e':
+ conf.events_retry = atoi(optarg);
+ break;
#else
case 'a':
case 'u':
case 'U':
case 'X':
+ case 'e':
f
