When to use which? RED.httpNode vs RED.httpAdmin

Whenever I'm working on custom nodes, the following situation has me diving back into the docs every single time, and the docs kindly explain that this is still a TODO waiting to be added. I'm hoping this topic can become detailed enough that the documentation for it can be written and published.

When needing to add an endpoint to the node I'm working on, I always wonder whether I need to use RED.httpNode or RED.httpAdmin for it. The API reference says that httpNode is "the Express application for HTTP Nodes", and that httpAdmin is "the Express application for the Editor Admin API". From previous topics on here I've learned that httpAdmin has the option to use the RED.auth, the editor authentication api, to request permissions, for which the permissions for adminAuth from the settings file are used/checked.
The comments in the default settings file give more suggestions:

    // By default, the Node-RED UI is available at http://localhost:1880/
    // The following property can be used to specify a different root path.
    // If set to false, this is disabled.
    //httpAdminRoot: '/admin',

    // Some nodes, such as HTTP In, can be used to listen for incoming http requests.
    // By default, these are served relative to '/'. The following property
    // can be used to specifiy a different root path. If set to false, this is
    // disabled.
    //httpNodeRoot: '/red-nodes',

    // Securing Node-RED
    // -----------------
    // To password protect the Node-RED editor and admin API, the following
    // property can be used. See http://nodered.org/docs/security.html for details.
    //adminAuth: {
    //    type: "credentials",
    //    users: [{
    //        username: "admin",
    //        password: "$2a$08$zZWtXTja0fB1pzD4sHCMyOCMYz2Z6dNbM6tl8sJogENOMcxWV9DN.",
    //        permissions: "*"
    //    }]
    //},

    // To password protect the node-defined HTTP endpoints (httpNodeRoot), or
    // the static content (httpStatic), the following properties can be used.
    // The pass field is a bcrypt hash of the password.
    // See http://nodered.org/docs/security.html#generating-the-password-hash
    //httpNodeAuth: {user:"user",pass:"$2a$08$zZWtXTja0fB1pzD4sHCMyOCMYz2Z6dNbM6tl8sJogENOMcxWV9DN."},
    //httpStaticAuth: {user:"user",pass:"$2a$08$zZWtXTja0fB1pzD4sHCMyOCMYz2Z6dNbM6tl8sJogENOMcxWV9DN."},

To me, it suggests that RED.httpAdmin is primarily aimed at providing interaction between the runtime and the editor, and that RED.httpNode adds additional endpoints to the runtime, like the use of HTTP-In/HTTP-Response nodes would do. As the settings for adminAuth are used on the login form, it makes sense for RED.auth.needsPermission to be meant for the active user logged in to the editor. From experience, enabling the httpNodeAuth results in a Basic Authentication login, and as there are no permissions present there it makes sense for this to be for all runtime exposing endpoints.

Am I correct in the assumptions above?

Lena,
I always call RED.httpAdmin (together with permissions) from my node's config screen in the flow editor.
And I call RED.httpNode (without permissions) from my UI dashboard nodes. That conforms what you are saying...
Bart

The more I think about it, the more it starts to make sense, which it previously didn't. So I guess writing that all out today was good for something :slight_smile:

I'm wondering about a specific use case now, OAuth callbacks in a config node. For an external server to make a callback, RED.httpNode seems the correct use. However, if you set up httpNodeAuth it will fail as it needs the basic auth to come through. I can only think of one solution there, and that is to have a button in the config node to request an OAuth login to take place based on the consumer key/secret present in the config node, for the rest to be filled in automatically after it completes. Since it will need the username and password, the user pressing that button has to supply that on the configuration screen so it can be embedded in the callback url in the protocol://username@password:domain/path format.

Is there a better way to do this, beyond not offering the option to authorise an account?

To summarise:

  • if the end point is related to editing the flows, then it should be attached to RED.httpAdmin.
  • if the end point is related to the runtime behaviour of the flows, it should be attached to RED.httpNode.

RED.httpAdmin is protected by the adminAuth settings if it includes the RED.auth.needsPermission middleware. If it doesn't include that middleware then the endpoint will not be secured.

RED.httpNode is protected by httpNodeAuth which is limited to Basic Auth and has no users/permissions associated with it.

No - it should be on RED.httpAdmin as it is related to editing the flows. And you don't use the RED.auth.needsPermission middleware so the callback can be made without having to provide the Node-RED access tokens etc. You can see that in action in various of the web nodes - for example: node-red-web-nodes/fitbit/fitbit.js at master · node-red/node-red-web-nodes · GitHub and you can see how the editor constructs the callback url dynamically here: node-red-web-nodes/fitbit/fitbit.html at master · node-red/node-red-web-nodes · GitHub

3 Likes

Perfect, thanks a lot Nick!

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.