Skip to content

Fix CORS preflight OPTIONS to respect PATCH in httpNodeCors#5361

Open
blazinbanana wants to merge 1 commit intonode-red:masterfrom
blazinbanana:fix-cors-options-respect-httpNodeCors
Open

Fix CORS preflight OPTIONS to respect PATCH in httpNodeCors#5361
blazinbanana wants to merge 1 commit intonode-red:masterfrom
blazinbanana:fix-cors-options-respect-httpNodeCors

Conversation

@blazinbanana
Copy link

Summary

This PR fixes an issue where Node-RED's admin API did not respect the user-provided
httpNodeCors.methods list when handling OPTIONS preflight requests. PATCH was not being
recognized, causing CORS failures when users exposed HTTP In nodes expecting PATCH requests.

What this PR does

  • Reads settings.httpNodeCors.methods
  • Ensures PATCH is included if user configured it
  • Applies unified CORS handler before other admin middleware
  • Avoids relying on hardcoded "GET,PUT,POST,DELETE"
  • Prevents redeclaration collisions with existing corsHandler

Why this matters

Modern APIs use PATCH heavily. Users who configured PATCH in their runtime settings still
experienced failed preflight requests. This PR ensures Node-RED respects runtime configuration
as intended.

Testing

  • Verified with a local development build of Node-RED (npm run dev)
  • Confirmed OPTIONS requests return 200 with correct Access-Control-Allow-Methods including PATCH
  • Confirmed no regressions for GET/PUT/POST/DELETE

Thank you for reviewing!

@linux-foundation-easycla
Copy link

linux-foundation-easycla bot commented Dec 1, 2025

CLA Signed
The committers listed above are authorized under a signed CLA.

  • ✅ login: blazinbanana / name: Caleb M Maina (9729323)

@hardillb
Copy link
Member

hardillb commented Dec 1, 2025

Hi, please include a link to the issue this is fixing, I assume it's this one #5356.

We need to decide if this is the correct choice here, when the editor (httpAdminRoot) and the httpNodeRoot are the same (the default), we need to decide if changing the default behaviour is correct, or if moving the editor the real solution.

Will changing CORs settings for the editor break things like nodes while loading 3rd party resources?

@knolleary
Copy link
Member

My concern is this will force PATCH into the list regardless of what the user has chosen to configure. That would be unexpected. We need to think about how to allow the user to provide admin-specific cors configuration, rather than reuse the HTTP Node configuration - as well as what our sensible defaults should be.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants