| Age | Commit message (Collapse) | Author |
|---|
|
Unregister ubus subscriber in notification remove callback.
Without this call, uhttpd crashes when client tries to subscribe to
the ubus object after the object was unregistred and registered again.
It is bacuse the reference to ubus subscriber is not freed but
the memory is cleared in the uh_request_done function.
Signed-off-by: Wojciech Jowsa <wojciech.jowsa@gmail.com>
|
|
The legacy ubus protocol must not include an empty object in the result
array if the invoked ubus procedure yielded no response.
This fixes compatibility with existing legacy ubus api clients that expect
this behaviour, LuCI's fs.js in particular.
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
|
|
Complex GET requests (e.g. those with custom headers) require browsers
to send preflight OPTIONS request with:
Access-Control-Request-Method: GET
It's important to reply to such requests with the header
Access-Control-Allow-Origin (and optionally others) to allow CORS
requests.
Adding GET to the Access-Control-Allow-Methods is cosmetical as
according to the Fetch standard:
> If request’s method is not in methods, request’s method is not a
> CORS-safelisted method, and request’s credentials mode is "include" or
> methods does not contain `*`, then return a network error.
It basically means that Access-Control-Allow-Methods value is ignored
for GET, HEAD and POST methods.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
|
|
With this change ubus will allow users with access to the object pseudo
method ":subscribe" to subscribe for notifications.
1. Move uh_ubus_allowed() up in the code
2. Export "Authorization" parsing code to the uh_ubus_get_auth()
3. Check for ":subscribe" method access
Right now this depends on "Authorization" HTTP header which browsers
don't allow setting for the EventSource. An alternative method of
submitting session token remains to be implemented.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
|
|
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 <prefix>/list
2. Listing object methods using GET <prefix>/list/<path>
3. Listening to object notifications with GET <prefix>/subscribe/<path>
4. Calling ubus methods using POST <prefix>/call/<path>
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 <rafal@milecki.pl>
|
|
Initializing buffer in the uh_ubus_handle_request() didn't handle
batched requests correctly. It resulted in reusing buffer and generating
malformed replies.
Call blob_buf_init() before every usage of the global buf variable.
While at it make two functions take blob_buf pointer as argument:
1. uh_ubus_send_response()
2. uh_ubus_init_json_rpc_response()
This helps following global "buf" variable usage and will help avoiding
similar bugs in the future.
Fixes: 628341fae412 ("ubus: use local "blob_buf" in uh_ubus_handle_request_object()")
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
|
|
Use "_json_rpc_" in their names so it's clear they are related to the
JSON-RPC format. This cleans up code a bit and will allow adding more
formats in the future.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
|
|
This follows two other functions logic: uh_ubus_send_request() and
uh_ubus_allowed(). Thanks to this change global "buf" variable is used
only for replies and doesn't require state tracking & reinitialization.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
|
|
According to the JSON-RPC 2.0 specification "params" value can be either
an Array or Object. This change makes parse_json_rpc() accept both.
Type validation should be handled by a function that actually reads
"params" depending on expected format. This doesn't change existing
behaviour but allows adding more methods (that expect Object) in the
future.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
|
|
Both: uh_ubus_send_request() and uh_ubus_send_list() don't use it.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
|
|
There is no point in parsing "call" specific params for other ("list")
method calls. This is a minor cleanup that doesn't change uhttpd ubus
behaviour.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Acked-by: Jo-Philipp Wich <jo@mein.io>
|
|
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
|
|
After format string checks were activated in libubox the compiler
started to complain about multiple missuses in uhttpd. This fixes the
format strings without changing the behavior.
blobmsg_get_string() just checks if the parameter is not NULL and then
calls blobmsg_data() and casts the result.
I think non of these problem is security relevant.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
|
|
Signed-off-by: John Crispin <blogic@openwrt.org>
|
|
uhttpd modifies the list_head member of the uhttpd_plugin struct when
loading a plugin, therefore we cannot make it const, otherwise we
trigger a security violation if uhttpd is built with RelRO support.
Signed-off-by: Jo-Philipp Wich <jow@openwrt.org>
|
|
In order to support cross-domain AJAX requests to the /ubus endpoint
we need to implement the Cross-Origin Resource Sharing (CORS) spec
in the ubus plugin.
- Implement a new option "-X" to enable CORS support in ubus
- Implement rudimentary support for "OPTIONS" HTTP requests
- Implement essential CORS headers the ubus plugin
The current CORS response headers merely reflect the request headers
sent by the client, this way any requesting origin is automatically
allowed. Cross-domain cookies (Access-Control-Allow-Credentials) are
unconditionally enabled.
Restricting permitted origins and toggle the credential accepting can
be made configurable in a future commit to allow more fine grained
control over permitted AJAX clients.
Signed-off-by: Jo-Philipp Wich <jow@openwrt.org>
|
|
bit of bandwidth
|
|
The ubus plugin calls blocking ubus functions that loop back into
uloop_run. Protect the client data structure with refcounting to ensure
that the outer uloop_run call does not clean up the data that the inner
uloop_run call is still processing.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
|
|
session.access
|
|
injecting different SIDs
|
|
procedure
|
|
information leakage via the post url
|
|
corruption with concurrent requests
|
|
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
|
|
|
|
|
|
|
|
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
|
|
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
|
|
|
|
|
|
|
|
other services provide the session api
|
|
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
|
|
|
|
|
|
|
|
|
|
|
