Headless mode and the flows API

[Stephen Maryka]

It seems that headless mode does not support injecting a flow definition via a POST to the flows URL.

If I set "httpAdminRoot: false" in settings.js, and then attempt to inject a flow like this...

curl -H "Content-Type: application/json" -d '[{"type":"tab","id":"728beed8.8d741","label":"Sheet 1"},{"id":"243995bb.dbc66a","type":"debug","name":"","active":true,"console":"true","complete":"false","x":570,"y":272,"z":"728beed8.8d741","wires":[]},{"id":"a889206e.5776e","type":"http in","name":"","url":"/test","method":"post","x":177,"y":267,"z":"728beed8.8d741","wires":[["243995bb.dbc66a","c3393bc1.3cc6c8"]]},{"id":"c3393bc1.3cc6c8","type":"http response","name":"","x":546,"y":359,"z":"728beed8.8d741","wires":[]}]' http://localhost:1880/flows

I get an error back...

Cannot POST /flows

If I turn headless mode off, this curl command works fine, as does the flow.

If I turn headless mode on, and include the flow in the startup flows file, that also works fine.

Is this the intended functionality of headless mode, or am I doing something wrong here?

We are looking for ways to separate the editor workflows from the production environment.  Editing flows in a headed deployment, and then injecting those flows into a headless production environment is where we want to get to.

Steve

[Nicholas O'Leary]

Hi Stephen,

you are correct in your observation that httpAdminRoot disables _all_ of the REST endpoints associated with the editor. The requirement at the time was to be able to lock down the runtime entirely and prevent remote updates.

Clearly there is a need for a mode that has the editor disabled but leaves the REST api in place. Our next release is due in the next few days; I'll see if we can get something into that - but it may have to wait for the following release.

The sort of use-case you describe is coming up increasingly often and we want to see what else we can do to better support it. For example, whether the basic authentication support we provide is sufficient, or if there needs to be a more pluggable auth scheme.

Nick

--
http://nodered.org
---
You received this message because you are subscribed to the Google Groups "Node-RED" group.
To unsubscribe from this group and stop receiving emails from it, send an email to node-red+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Stephen Maryka]

Thanks for the info.  Hopefully the feature can find its way into the next release.

The Node-RED technology is very intriguing and gaining some traction for sure, but to get to that next level it will have to accommodate production deployments. As other threads in this group suggest, key concerns for production environments include:

1) Access control:  Headless mode and variation on it are included here. A pluggable auth mechanism is definitely warranted, and finer-grained access control is likely required (separate permissions for flow development, deployment and execution).

2) Version control: Flows are software, and we all know version control is a fundamental requirement for production software. Tackling this is on our todo list, so if there are others considering this, we would be eager to collaborate on achieving a solution.

3) Multi-tenancy: A natural requirement in cloud-based offerings.  For our system, a multi-tenant code service for contextual notification, we have used process isolation to sandbox individual instances of the node-red runtime within our security realms.  This has proven to be a pretty heavy-weight solution.

Steve