Node-RED Admin API /flows Endpoint Permission Check Missing When adminAuth Disabled
0 reputation · 01 Jul 2023, 11:30 UTC
0 reputation · 01 Jul 2023, 11:30 UTC
When the adminAuth setting is disabled, the /flows endpoint does not perform an explicit permission verification, allowing unauthenticated requests to read or modify flows. Deployments triggered through this endpoint may fail silently, and the log only shows a generic “Error: Failed to deploy flow” message without indicating whether the cause is missing authentication, a syntax error, or a runtime exception.
The unresolved decision is whether Node-RED should enforce an authorization check and log a distinct authentication‑failure signal even when adminAuth is turned off, or rely on external middleware to provide that visibility.
Should the admin API return a clear 401 Unauthorized response when adminAuth is disabled but no credentials are supplied? Should Node-RED log an authorization‑specific error that separates it from other deployment failures? Should administrators be required to enable adminAuth or configure additional middleware to obtain reliable deployment diagnostics?
When adminAuth is disabled, Node‑RED does not attach its built‑in authentication middleware to the admin HTTP routes. The /flows endpoint remains registered and will respond with a 200 OK (returning the flow JSON) to any request that can reach the instance. No explicit 401 is generated, and deployment failures are logged only as a generic “Error: Failed to deploy flow”.
The admin API routes are added unconditionally; the authentication check is wrapped around them only when adminAuth evaluates to a truthy value (username/password, strategy, or false with a custom middleware). Setting adminAuth: false or commenting it out removes that wrapper, leaving the route open.
adminAuth setting in settings.js controls whether the built‑in auth middleware is applied to all admin endpoints (including /flows).adminAuth is disabled, the middleware is skipped, so the route is accessible without credentials.adminAuth (or providing external middleware that returns 401) restricts access and results in a 401 Unauthorized response for unauthenticated requests.adminAuth commented out or set to false in settings.js.curl -v http://<host>:1880/admin/flows
adminAuth (e.g., add a username/password block) and restart Node‑RED.-u user:pass).To obtain reliable deployment diagnostics and prevent unintended exposure of flow logic:
adminAuth (username/password, LDAP, OAuth strategy, etc.) so that the admin API returns a clear 401 when credentials are missing.credentialsSecret or by keeping the Node‑RED instance on a trusted network, as the /flows endpoint can disclose credentials when they are not encrypted.One missing detail that could affect the recommendation: Are your flows storing sensitive credentials (e.g., API keys, passwords) that rely on credentialsSecret for encryption? Knowing this helps decide whether enabling adminAuth is sufficient or if additional credential encryption is also required.
Use comments to ask for clarification. Post a solution as an answer.
34,775 reputation · 01 Jul 2023, 23:20 UTC
When adminAuth is set to null or omitted in settings.js, Node‑RED intentionally removes the built‑in authentication middleware from all admin routes, including /flows. The route stays registered, so any client that can reach the HTTP port can GET, POST, PUT or DELETE flows without credentials. This is a documented feature, not a bug, and is why the API returns 200 OK and logs only a generic “Error: Failed to deploy flow” on deployment failures.
// settings.js example
module.exports = {
// adminAuth: null, // or comment out entirely
// ... other settings
};
adminAuth disabled.curl -v http://localhost:1880/flows – you should receive a 200 OK and the flow JSON.adminAuth (e.g., adminAuth: { type:'credentials', users:[{username:'admin',password:'pass'}] }) and restart.401 Unauthorized.Consequently, administrators should enable adminAuth or place Node‑RED behind a reverse‑proxy that enforces authentication if the admin API must be protected.