Description of the JSON in menu.d and acl.d?

Are there any written descriptions about the JSON options in /usr/share/luci/menu.d. /usr/share/rpcd/acl.d/ and /usr/share/acl.d?

It looks like the LuCi top level menu bar is drawn based on the contents of the file menu.d/luci-base.json. Is that specific file always processed first, and then the other JSON files in the same directory? Is this described anywhere?


Hi @ twinkleLED.
Did you manage to improve on this question?

I'm looking for an description of the syntax of the keys in this files.
"cors", "action", "type", "module", "recurse", etc, etc, etc.

  • /usr/share/acl.d belongs to ubusd and was introduced later, it is unrelated to LuCI and can be ignored (the defaults are sufficient for LuCI to operate)
  • /usr/share/rpcd/acl.d/ controls rpcd's ACL mechanism. Details here:
  • /usr/share/luci/menu.d/ is a directory of JSON files describing the LuCI menu nodes.
    • Name and order of files does not matter
    • Contents from all files are merged into one common tree.
    • Possible fields here:
      • action: server side action to invoke; can be one of:
        • call - invoke method in Lua class, example { "type": "call", "module": "luci.example", "function": "my_method", "parameters": [ "static", "args", "to", "pass" ] }
        • view - render JavaScript view, example { "type": "view", "path": "my/view" }
        • template - render server side Lua template, example { "type": "template", "path": "my/template" }
        • cbi - render a server side Lua CBI from, example { "type": "cbi", "path": "my/cbi", "config": "example-uci" }
        • form - render a server side Lua non-uci form, example { "type": "form", "path": "my/form" }
        • firstchild - redirect to first visible subnode, example { "type": "firstchild" }
        • arcombine - legacy action type, don't use
        • alias - redirect to another node, example { "type": "alias", "path": "somewhere/else" }
        • rewrite - replace first N URL segments with another path, example { "type": "rewrite", "path": "somewhere/else", "remove": 3 } (would rewrite /foo/bar/baz/lala to /somewhere/else/lala)
      • auth - authentication required on this node and all subnodes (empty auth object to disable authentication on a subtree)
        • login - boolean indicating whether to offer a login form on unauthenticated accesses to this node (true) or not (false)
        • methods - array of accepted login methods
          • cookie:xxx - extract session ID from HTTP cookie named xxx
          • query:xxx - extract session ID from query string parameter xxx
          • param:xxx - extract session ID from POST parameter xxx
      • cors - boolean indicating whether XHR preflight (HTTP OPTIONS) requests should be handled by this node and its children
      • depends - dependency constraints for this node, node is disabled if unfulfilled
      • order - sort index for node
      • setgroup - for server side processing, setgid() to this user when doing node action
      • setuser - for server side processing, setuid() to this user when doing node action
      • title - human readable menu title, node is hidden from menu but accessible by URL if absent
      • wildcard - boolean indicating whether subsequent URL path segments should be ignored for routing and be passed as arguments to the server side action instead
    • firstchild_ineligible - boolean marking a node as unsuitable for selection by firstchild action in parent node (e.g. to prevent a non-visible/non-ui node becoming the default choice of a firstchild parent node)

  • Type view paths are expanded to /www/luci-static/resources/view/${path}.js
  • Type template paths are expanded to /usr/lib/lua/luci/view/${path}.htm
  • Type cbi and form paths are expanded to /usr/lib/lua/luci/model/cbi/${path}.lua

JavaScript (type view) views are included by a default server side template /usr/lib/lua/luci/view/view.htm

For dependencies, multiple fields in a dependency object form logical and expressions, multiple objects in an array form logical or expressions:

"depends": {
    "fs": [
        { "/sys/class/leds": "directory", "/etc/init.d/led": "executable" },
        { "/sbin/ledconfig": "executable" }

The example above read: require either at least one entry in /sys/class/leds/ as well as an executable /etc/init.d/led or an /sbin/ledconfig executable. Otherwise menu node is disabled.


Thanks @jow.
This was fantastic. I took a quick read and I believe that the main questions I had, are answered here. I will do my best to document this in a way that everyone can understand.
I've been a fan of OpenWRT since version 15 and I've always found everything I was looking for in the documentation. This was the first time I felt lost.
I program for pleasure, but on a more end-user level. Bare metal was never my specialty.