Skip to content

feat: Add route block with new server option routeAllowList#10389

Merged
mtrezza merged 13 commits intoparse-community:alphafrom
mtrezza:feat/add-routeAllowList
Apr 3, 2026
Merged

feat: Add route block with new server option routeAllowList#10389
mtrezza merged 13 commits intoparse-community:alphafrom
mtrezza:feat/add-routeAllowList

Conversation

@mtrezza
Copy link
Copy Markdown
Member

@mtrezza mtrezza commented Apr 2, 2026

Pull Request

Issue

Apps that run all logic in Cloud Code have no need for clients to access API routes directly. While CLP can restrict per-class access, it operates deep in the request pipeline and leaks information that enables class enumeration attacks. There is no way to categorically block external network access at the middleware level.

A core principle of defense-in-depth is to reject unwanted requests as early as possible in the processing chain — before authentication, authorization, parsing, or business logic can be reached. The earlier a request is blocked, the smaller the attack surface and the less code an attacker can interact with.

Approach

Adds a new opt-in server option routeAllowList (array of regex patterns) that blocks all external non-master-key requests unless the route matches a configured pattern. When not set, behavior is unchanged.

  • Deny-all by default when the option is set; only matching routes pass through
  • Master key and maintenance key requests bypass the restriction
  • Internal calls from Cloud Code, Cloud Jobs, and triggers are unaffected (they bypass Express middleware via ParseServerRESTController)
  • Blocked requests return OPERATION_FORBIDDEN with sanitized "Permission denied" message, indistinguishable from CLP denials
  • Regex patterns are auto-anchored (^pattern$) and compiled once at startup
  • Covers all 82 API routes including health endpoint; file routes are excluded (controlled separately by fileUpload options)

Tasks

  • Add tests
  • Add changes to documentation (guides, repository pages, code comments)
  • Add security check
  • Add new Parse Error codes to Parse JS SDK

Summary by CodeRabbit

  • New Features

    • Added routeAllowList option to restrict external API access; external non-master-key requests are denied by default and only allowed for routes matching provided regex patterns (auto-anchored). Empty list ([]) blocks all external non-master-key requests. Master/maintenance keys and internal Cloud Code/Jobs/triggers bypass the restriction. Health endpoint now enforces the allow list.
  • Documentation

    • Added docs and PARSE_SERVER_ROUTE_ALLOW_LIST env var guidance; notes on file upload routes handled separately.
  • Tests

    • New test suite validating config, matching semantics, bypasses, and sanitized error responses.

@parse-github-assistant
Copy link
Copy Markdown

parse-github-assistant bot commented Apr 2, 2026

🚀 Thanks for opening this pull request! We appreciate your effort in improving the project. Please let us know once your pull request is ready for review.

Tip

  • Keep pull requests small. Large PRs will be rejected. Break complex features into smaller, incremental PRs.
  • Use Test Driven Development. Write failing tests before implementing functionality. Ensure tests pass.
  • Group code into logical blocks. Add a short comment before each block to explain its purpose.
  • We offer conceptual guidance. Coding is up to you. PRs must be merge-ready for human review.
  • Our review focuses on concept, not quality. PRs with code issues will be rejected. Use an AI agent.
  • Human review time is precious. Avoid review ping-pong. Inspect and test your AI-generated code.

Note

Please respond to review comments from AI agents just like you would to comments from a human reviewer. Let the reviewer resolve their own comments, unless they have reviewed and accepted your commit, or agreed with your explanation for why the feedback was incorrect.

Caution

Pull requests must be written using an AI agent with human supervision. Pull requests written entirely by a human will likely be rejected, because of lower code quality, higher review effort and the higher risk of introducing bugs. Please note that AI review comments on this pull request alone do not satisfy this requirement.

@coderabbitai
Copy link
Copy Markdown

coderabbitai bot commented Apr 2, 2026

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 9998ffa7-98e8-48db-999f-9fc5ab10ad08

📥 Commits

Reviewing files that changed from the base of the PR and between f5e285c and 5cd7719.

📒 Files selected for processing (3)
  • src/Options/Definitions.js
  • src/Options/docs.js
  • src/Options/index.js
🚧 Files skipped from review as they are similar to previous changes (3)
  • src/Options/index.js
  • src/Options/Definitions.js
  • src/Options/docs.js

📝 Walkthrough

Walkthrough

Adds a new routeAllowList Parse Server option (validated and precompiled to anchored regexes), a middleware to enforce allow-listing for external non-master requests, integrates the middleware into the request pipeline (including /health), updates option docs/definitions, and adds end-to-end tests.

Changes

Cohort / File(s) Summary
Documentation
README.md, src/Options/docs.js
Added TOC and docs for routeAllowList: semantics, normalized route identifiers, auto-anchoring, empty-list behavior, covered routes table, and env var format.
Options Definitions
src/Options/Definitions.js, src/Options/index.js
Introduced routeAllowList option (PARSE_SERVER_ROUTE_ALLOW_LIST), parsed via parsers.arrayParser, added JSDoc/Flow option signature and help text.
Configuration & Validation
src/Config.js
Added validateRouteAllowList() and updated Config.put to compile/cache anchored RegExp instances on _routeAllowListRegex; validation rejects non-strings and invalid regex entries.
Middleware Implementation
src/middlewares.js
Refactored header auth into resolveKeyAuth, added handleParseAuth(appId), handleParseHealth(options), and enforceRouteAllowList(req,res,next); uses createSanitizedError, reuses req.config, enforces IP/key allowlist checks, and centralizes auth resolution.
Server Integration
src/ParseServer.ts
Moved handleParseAuth earlier in pipeline, inserted enforceRouteAllowList before query parsing, and replaced inline /health handler with enforceRouteAllowList + handleParseHealth.
Tests
spec/RouteAllowList.spec.js
New Jasmine E2E suite covering config validation, regex compilation/caching, middleware enforcement, bypasses (master/maintenance/Cloud Code), sanitized-error modes, and blocked route groups.

Sequence Diagram

sequenceDiagram
    participant Client as External Client
    participant AuthMW as handleParseAuth
    participant AllowMW as enforceRouteAllowList
    participant Config as Server Config
    participant Handler as Route Handler

    Client->>AuthMW: HTTP request (headers, path)
    AuthMW->>Config: load per-app config & keys
    AuthMW->>AuthMW: resolve master/maintenance auth (sets req.auth)
    AuthMW->>AllowMW: next() with req.auth
    AllowMW->>Config: check _routeAllowListRegex for normalized route
    alt routeAllowList not set
        AllowMW->>Handler: next()
    else routeAllowList set
        alt req.auth is master/maintenance/internal
            AllowMW->>Handler: next()
        else pattern matches normalized route
            AllowMW->>Handler: next()
        else no match
            AllowMW-->>Client: OPERATION_FORBIDDEN (sanitized)
        end
    end
    Handler->>Client: Response
Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~28 minutes

Possibly related PRs

Suggested reviewers

  • Moumouls
🚥 Pre-merge checks | ✅ 2 | ❌ 3

❌ Failed checks (3 warnings)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 14.29% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
Security Check ⚠️ Warning The implementation lacks protection against ReDoS attacks, allowing user-supplied regex patterns to be tested synchronously without timeout limits. Implement ReDoS protection by adding timeout limits to regex matching and use safe-regex validation. Add try-catch error handling around the new URL() call.
Engage In Review Feedback ⚠️ Warning User resolved review feedback using an automated bot (CodeRabbit) via GraphQL mutations without evidence of prior engagement in discussions with reviewers. User should manually engage in discussions with reviewers to either implement feedback through commits or convince reviewers to retract feedback before resolving threads.
✅ Passed checks (2 passed)
Check name Status Explanation
Title check ✅ Passed The title begins with the required 'feat:' prefix and clearly describes the main change: introducing route blocking via a new server option called routeAllowList.
Description check ✅ Passed The PR description follows the template structure, includes detailed Issue and Approach sections explaining the security motivation and implementation details, and marks completed tasks with checkmarks.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@mtrezza mtrezza changed the title feat: Add hard route block with new server option routeAllowList feat: Add route block with new server option routeAllowList Apr 2, 2026
Copy link
Copy Markdown

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

🧹 Nitpick comments (1)
src/ParseServer.ts (1)

332-343: /health is now gated by routeAllowList; ensure probe routes are explicitly allowlisted.

With enforceRouteAllowList before the health handler, liveness/readiness checks will be denied unless health matches the configured patterns. Consider adding a startup warning when routeAllowList is set but health is not matched.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@src/ParseServer.ts` around lines 332 - 343, The health endpoint is registered
after api.use(middlewares.enforceRouteAllowList) so liveness/readiness probes
will be blocked unless the configured routeAllowList includes "health"; update
startup logic to either (A) ensure the configured routeAllowList always matches
the "/health" probe route or (B) move the api.use('/health', ...) registration
to run before enforceRouteAllowList, and add a startup warning when a non-empty
routeAllowList is set but does not match the health path; check symbols
api.use(middlewares.enforceRouteAllowList), api.use('/health', ...) and the
routeAllowList configuration to implement the chosen fix.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/Config.js`:
- Around line 749-753: The catch currently declares an unused parameter (catch
(e)) when validating regex patterns for routeAllowList; replace it with an empty
catch block (catch) to satisfy static analysis: update the try/catch around new
RegExp('^' + pattern + '$') so the catch has no parameter and still throws the
existing error message about an invalid regex pattern for routeAllowList.

In `@src/Options/Definitions.js`:
- Around line 563-567: The env parsing for routeAllowList currently uses
parsers.arrayParser which naively splits on commas and breaks regexes
(routeAllowList / parsers.arrayParser); update the source option in
src/Options/index.js to use a parser that preserves regex commas (e.g., swap to
parsers.moduleOrObjectParser or implement a new regex-aware parser such as
parsers.regexArrayParser) and ensure the option still maps to routeAllowList in
Definitions.js, then regenerate the auto-generated file by running npm run
definitions.

---

Nitpick comments:
In `@src/ParseServer.ts`:
- Around line 332-343: The health endpoint is registered after
api.use(middlewares.enforceRouteAllowList) so liveness/readiness probes will be
blocked unless the configured routeAllowList includes "health"; update startup
logic to either (A) ensure the configured routeAllowList always matches the
"/health" probe route or (B) move the api.use('/health', ...) registration to
run before enforceRouteAllowList, and add a startup warning when a non-empty
routeAllowList is set but does not match the health path; check symbols
api.use(middlewares.enforceRouteAllowList), api.use('/health', ...) and the
routeAllowList configuration to implement the chosen fix.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: a6844f27-be24-4b83-a20d-566f5545d589

📥 Commits

Reviewing files that changed from the base of the PR and between 73dde76 and 6e8658b.

📒 Files selected for processing (8)
  • README.md
  • spec/RouteAllowList.spec.js
  • src/Config.js
  • src/Options/Definitions.js
  • src/Options/docs.js
  • src/Options/index.js
  • src/ParseServer.ts
  • src/middlewares.js

Copy link
Copy Markdown

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick comments (1)
src/Config.js (1)

103-107: Consider compiling routeAllowList regexes once and reusing the result.

Patterns are compiled in validateRouteAllowList for validation and then compiled again in Config.put. You can compile once in validation and assign the compiled array.

♻️ Proposed refactor
 static put(serverConfiguration) {
-  Config.validateOptions(serverConfiguration);
+  const routeAllowListRegex = Config.validateOptions(serverConfiguration);
   Config.validateControllers(serverConfiguration);
-  if (serverConfiguration.routeAllowList) {
-    serverConfiguration._routeAllowListRegex = serverConfiguration.routeAllowList.map(
-      pattern => new RegExp('^' + pattern + '$')
-    );
-  }
+  if (routeAllowListRegex) {
+    serverConfiguration._routeAllowListRegex = routeAllowListRegex;
+  }
   Config.transformConfiguration(serverConfiguration);
   AppCache.put(serverConfiguration.appId, serverConfiguration);
   Config.setupPasswordValidator(serverConfiguration.passwordPolicy);
   return serverConfiguration;
 }

 static validateOptions({
   ...
   routeAllowList,
 }) {
   ...
-  this.validateRouteAllowList(routeAllowList);
+  return this.validateRouteAllowList(routeAllowList);
 }

 static validateRouteAllowList(routeAllowList) {
   if (routeAllowList === undefined || routeAllowList === null) {
-    return;
+    return null;
   }
   if (!Array.isArray(routeAllowList)) {
     throw 'Parse Server option routeAllowList must be an array of strings.';
   }
+  const compiled = [];
   for (const pattern of routeAllowList) {
     if (typeof pattern !== 'string') {
       throw `Parse Server option routeAllowList contains a non-string value.`;
     }
     try {
-      new RegExp('^' + pattern + '$');
+      compiled.push(new RegExp('^' + pattern + '$'));
     } catch {
       throw `Parse Server option routeAllowList contains an invalid regex pattern: "${pattern}".`;
     }
   }
+  return compiled;
 }

Also applies to: 738-755

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@src/Config.js` around lines 103 - 107, The code currently compiles
routeAllowList patterns twice (once in validateRouteAllowList and again in
Config.put); change validation to compile the patterns once and store the
resulting RegExp array on the config object
(serverConfiguration._routeAllowListRegex) so Config.put (and other callers)
reuse that precompiled array instead of recompiling; update
validateRouteAllowList to return/assign the compiled array and remove the second
new RegExp map in the block that currently sets _routeAllowListRegex to avoid
duplicate compilation (references: validateRouteAllowList,
serverConfiguration._routeAllowListRegex, Config.put).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@src/Config.js`:
- Around line 103-107: The code currently compiles routeAllowList patterns twice
(once in validateRouteAllowList and again in Config.put); change validation to
compile the patterns once and store the resulting RegExp array on the config
object (serverConfiguration._routeAllowListRegex) so Config.put (and other
callers) reuse that precompiled array instead of recompiling; update
validateRouteAllowList to return/assign the compiled array and remove the second
new RegExp map in the block that currently sets _routeAllowListRegex to avoid
duplicate compilation (references: validateRouteAllowList,
serverConfiguration._routeAllowListRegex, Config.put).

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: c1a22320-10f6-412b-a629-80ebe8d897d2

📥 Commits

Reviewing files that changed from the base of the PR and between 6e8658b and 16bf989.

📒 Files selected for processing (4)
  • src/Config.js
  • src/Options/Definitions.js
  • src/Options/docs.js
  • src/Options/index.js
🚧 Files skipped from review as they are similar to previous changes (1)
  • src/Options/docs.js

coderabbitai[bot]
coderabbitai bot previously approved these changes Apr 2, 2026
coderabbitai[bot]
coderabbitai bot previously approved these changes Apr 3, 2026
@codecov
Copy link
Copy Markdown

codecov bot commented Apr 3, 2026

Codecov Report

❌ Patch coverage is 96.70330% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 92.50%. Comparing base (dd7cc41) to head (5cd7719).
⚠️ Report is 3 commits behind head on alpha.

Files with missing lines Patch % Lines
src/middlewares.js 95.94% 3 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##            alpha   #10389      +/-   ##
==========================================
- Coverage   92.52%   92.50%   -0.02%     
==========================================
  Files         192      192              
  Lines       16568    16620      +52     
  Branches      231      229       -2     
==========================================
+ Hits        15330    15375      +45     
- Misses       1216     1223       +7     
  Partials       22       22              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

Copy link
Copy Markdown

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/middlewares.js`:
- Around line 493-516: The middleware handleParseAuth does not catch errors from
async calls (notably resolveKeyAuth and config.loadKeys), which can cause
unhandled promise rejections; wrap the async section in a try-catch, call
next(error) on catch, and only continue to set req.auth and call next() when no
error occurred. Specifically, in handleParseAuth, surround the await
config.loadKeys() and await resolveKeyAuth({...}) calls with try { ... } catch
(error) { return next(error); } so thrown errors (e.g., from resolveKeyAuth) are
forwarded to Express error handlers.
- Around line 530-557: The allow-list check uses mount-relative req.url which
becomes '' for the health mount, causing documented pattern 'health' to never
match; update enforceRouteAllowList to derive the matchable path from
req.originalUrl (falling back to req.url) before trimming leading '/' and query
string so patterns like 'health' match as documented (adjust the existing path
normalization logic around req.url to use originalUrl when present and preserve
current fallbacks and regex matching against config._routeAllowListRegex).
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: b3165fc9-db0d-4dcf-8d14-bfbacfad7ac9

📥 Commits

Reviewing files that changed from the base of the PR and between dde1a23 and 6808667.

📒 Files selected for processing (1)
  • src/middlewares.js

@mtrezza
Copy link
Copy Markdown
Member Author

mtrezza commented Apr 3, 2026

@coderabbitai resolve conversations where we found a consensus

@coderabbitai
Copy link
Copy Markdown

coderabbitai bot commented Apr 3, 2026

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

Let me fetch the open review conversations on this PR to identify which ones have reached consensus.


🏁 Script executed:

#!/bin/bash
# Fetch all review comments on the PR to identify conversations
gh pr view 10389 --repo parse-community/parse-server --json reviews,comments

# Also fetch review threads
gh api repos/parse-community/parse-server/pulls/10389/comments --paginate | jq '[.[] | {id: .id, body: .body[0:200], path: .path, line: .line, in_reply_to_id: .in_reply_to_id, user: .user.login}]'

Length of output: 45846


Let me fetch the review thread IDs so I can resolve the right ones.


🏁 Script executed:

#!/bin/bash
# Fetch pull request review threads to get thread IDs for resolving
gh api graphql -f query='
{
  repository(owner: "parse-community", name: "parse-server") {
    pullRequest(number: 10389) {
      reviewThreads(first: 50) {
        nodes {
          id
          isResolved
          path
          line
          comments(first: 5) {
            nodes {
              author { login }
              body
              createdAt
            }
          }
        }
      }
    }
  }
}' | jq '.data.repository.pullRequest.reviewThreads.nodes[] | {id: .id, isResolved: .isResolved, path: .path, line: .line, firstComment: .comments.nodes[0].body[0:120], lastAuthor: (.comments.nodes | last | .author.login), lastComment: (.comments.nodes | last | .body[0:120])}'

Length of output: 1722


🏁 Script executed:

#!/bin/bash
# Resolve the two threads where consensus was reached

# Thread: src/middlewares.js line 516 - Express 5 handles async errors (consensus reached)
gh api graphql -f query='
mutation {
  resolveReviewThread(input: {threadId: "PRRT_kwDOAwQnRs54o7-_"}) {
    thread {
      id
      isResolved
    }
  }
}'

# Thread: src/middlewares.js line 557 - health endpoint fix via req.originalUrl (fix confirmed)
gh api graphql -f query='
mutation {
  resolveReviewThread(input: {threadId: "PRRT_kwDOAwQnRs54o7_C"}) {
    thread {
      id
      isResolved
    }
  }
}'

Length of output: 184


@mtrezza Here's a summary of what was resolved:

Thread Status
src/Config.js line 753 — unused catch parameter e Already resolved ✓
src/Options/Definitions.js line 567 — arrayParser comma limitation Already resolved ✓
src/middlewares.js line 516 — async error not caught Resolved now — Express 5 automatically forwards async middleware errors to error handlers
src/middlewares.js line 557 — health endpoint route mismatch Resolved now — fix confirmed via req.originalUrl + config.mount pathname stripping

🧠 Learnings used
Learnt from: mtrezza
Repo: parse-community/parse-server PR: 0
File: :0-0
Timestamp: 2025-11-08T13:46:04.940Z
Learning: When reviewing Parse Server PRs that add new features, always check whether the feature is documented in the README.md file, though for new Parse Server options this is optional rather than required.

Learnt from: mtrezza
Repo: parse-community/parse-server PR: 0
File: :0-0
Timestamp: 2025-11-17T15:02:48.786Z
Learning: For Parse Server PRs, always suggest an Angular commit convention PR title that would make a meaningful changelog entry for developers. Update the PR title suggestion on every commit. The format should be: type(scope): description. Common types include feat, fix, perf, refactor, docs, test, chore. The scope should identify the subsystem (e.g., graphql, rest, push, security). The description should be action-oriented and clearly convey the change's impact to developers.

Learnt from: mtrezza
Repo: parse-community/parse-server PR: 0
File: :0-0
Timestamp: 2026-03-23T22:11:01.903Z
Learning: In Parse Server PRs (parse-community/parse-server), when the commit/PR type prefix is `fix:`, the PR title must describe the bug (the broken behavior), not the fix (the expected or corrected behavior). For example, instead of "fix: Strip undefined values in ParseServerRESTController to match HTTP mode" (describes the fix), prefer "fix: directAccess update with undefined field values persists them as null in MongoDB" (describes the broken behavior).

Learnt from: Moumouls
Repo: parse-community/parse-server PR: 0
File: :0-0
Timestamp: 2026-03-28T19:24:55.383Z
Learning: In parse-community/parse-server (PR `#10341`), `requestComplexity.batchRequestLimit` intentionally defaults to `-1` (unlimited) in PS9. This is by design: batch request limiting is opt-in in the current major version and will become a hard default (safe non-unlimited value) in PS10, consistent with the same opt-in policy already established for other `requestComplexity` sub-options (e.g., `includeLimit`). Do not flag the `-1` default as a security gap for PS9.

Learnt from: mtrezza
Repo: parse-community/parse-server PR: 10237
File: src/Routers/PagesRouter.js:552-573
Timestamp: 2026-03-18T17:53:35.669Z
Learning: In parse-community/parse-server, `src/Routers/PagesRouter.js`: the `encodeURIComponent` call in `composePageParamHeaders` is pre-existing behavior extracted from inline code in `pageResponse` and `redirectResponse`. The potential URIError on malformed Unicode (lone surrogates) when `encodePageParamHeaders` is enabled is a known pre-existing issue, not introduced by the CRLF sanitization refactor. Do not flag it as a new issue in PRs that only refactor or consolidate this call.

Learnt from: mtrezza
Repo: parse-community/parse-server PR: 0
File: :0-0
Timestamp: 2025-12-02T06:55:53.808Z
Learning: When reviewing Parse Server PRs that add or modify Parse Server options, always verify that changes are properly reflected in three files: src/Options/index.js (where changes originate), src/Options/Definitions.js, and src/Options/docs.js. The correct workflow is: make changes in index.js first, then run `npm run definitions` to automatically replicate the changes to Definitions.js and docs.js.

Learnt from: mtrezza
Repo: parse-community/parse-server PR: 0
File: :0-0
Timestamp: 2025-11-17T15:02:24.824Z
Learning: For Parse Server PRs, always suggest an Angular-style PR title that would make a meaningful changelog entry for developers. Update the PR title suggestion with every new commit to the PR.

Learnt from: mtrezza
Repo: parse-community/parse-server PR: 0
File: :0-0
Timestamp: 2025-11-08T13:46:04.940Z
Learning: For new Parse Server options, verify that the option is documented in src/Options/index.js and that npm run definitions has been executed to reflect changes in src/Options/docs.js and src/Options/Definitions.js. README.md documentation is a bonus but not required for new options.

Learnt from: mtrezza
Repo: parse-community/parse-server PR: 10389
File: src/Options/Definitions.js:563-567
Timestamp: 2026-04-02T21:46:45.869Z
Learning: In parse-community/parse-server, `parsers.arrayParser` splits env variable values on commas. This is a known, pre-existing limitation that applies to all `string[]` options (e.g., `masterKeyIps`, `allowHeaders`, `routeAllowList`). Regex patterns containing commas (e.g., `\d{2,4}`) cannot be set via environment variable; users must use the programmatic API instead. Do not flag this as a new issue or suggest fixing `arrayParser` within individual feature PRs — fixing `arrayParser` itself is out of scope.

coderabbitai[bot]
coderabbitai bot previously approved these changes Apr 3, 2026
@mtrezza
Copy link
Copy Markdown
Member Author

mtrezza commented Apr 3, 2026

@coderabbitai resume

@coderabbitai
Copy link
Copy Markdown

coderabbitai bot commented Apr 3, 2026

✅ Actions performed

Reviews resumed.

Copy link
Copy Markdown

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/middlewares.js`:
- Around line 449-457: The maintenance-key branch currently logs an error and
falls through when checkIp fails, allowing the request to continue as a regular
user; change it to reject the request with a 403 like the master/read-only
master key branches: when maintenanceKeyValue === config.maintenanceKey and
checkIp(...) returns false, use the same error-handling path used for
master/read-only keys (log via config.loggerController || defaultLogger and
return/throw an HTTP 403 response or auth rejection) instead of returning new
auth.Auth({ ..., isMaintenance: true }) or falling through, ensuring the
invalid-IP maintenance key holder is blocked.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: c59859a8-4cd9-4caa-8ce8-f5b1c80034d1

📥 Commits

Reviewing files that changed from the base of the PR and between 6808667 and f5e285c.

📒 Files selected for processing (2)
  • spec/RouteAllowList.spec.js
  • src/middlewares.js
✅ Files skipped from review due to trivial changes (1)
  • spec/RouteAllowList.spec.js

@mtrezza
Copy link
Copy Markdown
Member Author

mtrezza commented Apr 3, 2026

@coderabbitai resolve conversations where we found a consensus

@coderabbitai
Copy link
Copy Markdown

coderabbitai bot commented Apr 3, 2026

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Fetch all review threads with their resolution status and last comments
gh api graphql -f query='
{
  repository(owner: "parse-community", name: "parse-server") {
    pullRequest(number: 10389) {
      reviewThreads(first: 50) {
        nodes {
          id
          isResolved
          path
          line
          comments(first: 10) {
            nodes {
              author { login }
              body
              createdAt
            }
          }
        }
      }
    }
  }
}' | jq '.data.repository.pullRequest.reviewThreads.nodes[] | select(.isResolved == false) | {id: .id, isResolved: .isResolved, path: .path, line: .line, comments: [.comments.nodes[] | {author: .author.login, body: .body[0:200]}]}'

Length of output: 865


🏁 Script executed:

#!/bin/bash
# Resolve the middlewares.js line 457 thread - consensus reached, fix tracked in `#10390`
gh api graphql -f query='
mutation {
  resolveReviewThread(input: {threadId: "PRRT_kwDOAwQnRs54ueQc"}) {
    thread {
      id
      isResolved
    }
  }
}'

Length of output: 92


@mtrezza Here's the updated summary — one additional thread was resolved:

Thread Status
src/Config.js line 753 — unused catch parameter e Already resolved ✓
src/Options/Definitions.js line 567 — arrayParser comma limitation Already resolved ✓
src/middlewares.js line 516 — async error not caught Already resolved ✓
src/middlewares.js line 557 — health endpoint route mismatch Already resolved ✓
src/middlewares.js line 457 — maintenance key IP restriction inconsistency Resolved now — pre-existing behavior, fix tracked in #10390

All open threads where consensus was reached are now resolved.


🧠 Learnings used
Learnt from: mtrezza
Repo: parse-community/parse-server PR: 0
File: :0-0
Timestamp: 2025-12-02T06:55:53.808Z
Learning: When reviewing Parse Server PRs that add or modify Parse Server options, always verify that changes are properly reflected in three files: src/Options/index.js (where changes originate), src/Options/Definitions.js, and src/Options/docs.js. The correct workflow is: make changes in index.js first, then run `npm run definitions` to automatically replicate the changes to Definitions.js and docs.js.

Learnt from: mtrezza
Repo: parse-community/parse-server PR: 0
File: :0-0
Timestamp: 2025-11-08T13:46:04.940Z
Learning: When reviewing Parse Server PRs that add new features, always check whether the feature is documented in the README.md file, though for new Parse Server options this is optional rather than required.

Learnt from: mtrezza
Repo: parse-community/parse-server PR: 10237
File: src/Routers/PagesRouter.js:552-573
Timestamp: 2026-03-18T17:53:35.669Z
Learning: In parse-community/parse-server, `src/Routers/PagesRouter.js`: the `encodeURIComponent` call in `composePageParamHeaders` is pre-existing behavior extracted from inline code in `pageResponse` and `redirectResponse`. The potential URIError on malformed Unicode (lone surrogates) when `encodePageParamHeaders` is enabled is a known pre-existing issue, not introduced by the CRLF sanitization refactor. Do not flag it as a new issue in PRs that only refactor or consolidate this call.

Learnt from: mtrezza
Repo: parse-community/parse-server PR: 10389
File: src/middlewares.js:449-457
Timestamp: 2026-04-03T14:45:43.857Z
Learning: In `src/middlewares.js` (`resolveKeyAuth`), the maintenance key IP restriction currently only logs an error and falls through (request continues as a regular user) when `checkIp` fails — unlike master key and read-only master key branches which throw a 403. This is pre-existing behavior preserved during the refactor in PR `#10389`, not introduced by it. The fix is tracked separately in issue `#10390`.

Learnt from: Moumouls
Repo: parse-community/parse-server PR: 0
File: :0-0
Timestamp: 2026-03-28T19:24:55.383Z
Learning: In parse-community/parse-server (PR `#10341`), `requestComplexity.batchRequestLimit` intentionally defaults to `-1` (unlimited) in PS9. This is by design: batch request limiting is opt-in in the current major version and will become a hard default (safe non-unlimited value) in PS10, consistent with the same opt-in policy already established for other `requestComplexity` sub-options (e.g., `includeLimit`). Do not flag the `-1` default as a security gap for PS9.

Learnt from: mtrezza
Repo: parse-community/parse-server PR: 10389
File: src/Options/Definitions.js:563-567
Timestamp: 2026-04-02T21:46:45.869Z
Learning: In parse-community/parse-server, `parsers.arrayParser` splits env variable values on commas. This is a known, pre-existing limitation that applies to all `string[]` options (e.g., `masterKeyIps`, `allowHeaders`, `routeAllowList`). Regex patterns containing commas (e.g., `\d{2,4}`) cannot be set via environment variable; users must use the programmatic API instead. Do not flag this as a new issue or suggest fixing `arrayParser` within individual feature PRs — fixing `arrayParser` itself is out of scope.

Learnt from: mtrezza
Repo: parse-community/parse-server PR: 0
File: :0-0
Timestamp: 2025-11-08T13:46:04.940Z
Learning: For new Parse Server options, verify that the option is documented in src/Options/index.js and that npm run definitions has been executed to reflect changes in src/Options/docs.js and src/Options/Definitions.js. README.md documentation is a bonus but not required for new options.

Learnt from: mtrezza
Repo: parse-community/parse-server PR: 0
File: :0-0
Timestamp: 2025-11-17T15:02:48.786Z
Learning: For Parse Server PRs, always suggest an Angular commit convention PR title that would make a meaningful changelog entry for developers. Update the PR title suggestion on every commit. The format should be: type(scope): description. Common types include feat, fix, perf, refactor, docs, test, chore. The scope should identify the subsystem (e.g., graphql, rest, push, security). The description should be action-oriented and clearly convey the change's impact to developers.

Learnt from: mtrezza
Repo: parse-community/parse-server PR: 0
File: :0-0
Timestamp: 2026-03-23T22:11:01.903Z
Learning: In Parse Server PRs (parse-community/parse-server), when the commit/PR type prefix is `fix:`, the PR title must describe the bug (the broken behavior), not the fix (the expected or corrected behavior). For example, instead of "fix: Strip undefined values in ParseServerRESTController to match HTTP mode" (describes the fix), prefer "fix: directAccess update with undefined field values persists them as null in MongoDB" (describes the broken behavior).

@mtrezza mtrezza merged commit f2d06e7 into parse-community:alpha Apr 3, 2026
23 of 24 checks passed
@mtrezza mtrezza deleted the feat/add-routeAllowList branch April 3, 2026 15:09
parseplatformorg pushed a commit that referenced this pull request Apr 3, 2026
# [9.8.0-alpha.1](9.7.1-alpha.4...9.8.0-alpha.1) (2026-04-03)

### Features

* Add route block with new server option `routeAllowList` ([#10389](#10389)) ([f2d06e7](f2d06e7))
@parseplatformorg
Copy link
Copy Markdown
Contributor

🎉 This change has been released in version 9.8.0-alpha.1

@parseplatformorg parseplatformorg added the state:released-alpha Released as alpha version label Apr 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

state:released-alpha Released as alpha version

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants