Repository navigation
fix: Remote access restrictions not enforced when running behind a reverse proxy - #3436
Conversation
|
🚀 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
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. Our CI and AI review are safeguards, not development tools. If many issues are flagged, rethink your development approach. Invest more effort in planning and design rather than using review cycles to fix low-quality code. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughLocal request detection now rejects configured proxies and forwarding headers. Remote-access checks separate connection HTTPS enforcement from strict local authentication. Tests cover dashboard and agent endpoints. ChangesRemote access security
Estimated code review effort: 3 (Moderate) | ~20 minutes 🚥 Pre-merge checks | ✅ 7✅ Passed checks (7 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
ESLint install failed. For unrecoverable errors, disable the tool in CodeRabbit configuration. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@Parse-Dashboard/app.js`:
- Around line 90-109: Update the forwarding-header detection in isLocalRequest
to reject every x-forwarded-* header, including X-Forwarded-Proto and
X-Forwarded-Port, rather than relying only on the current explicit list. Add
coverage for a request containing only X-Forwarded-Proto and verify it cannot
receive the unauthenticated master-key response.
🪄 Autofix
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: 3bdff889-c74c-4655-9436-96199ba01a11
📒 Files selected for processing (2)
Parse-Dashboard/app.jssrc/lib/tests/RemoteAccess.test.js
|
@coderabbitai full review |
✅ Action performedFull review finished. |
|
@coderabbitai review your feedback conversations and resolve where you found a consensus |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: #!/bin/bash
set -euo pipefail
repo="parse-community/parse-dashboard"
pr="3436"
echo "== Review threads =="
gh api graphql \
-F owner="${repo%%/*}" \
-F name="${repo#*/}" \
-F number="$pr" \
-f query='
query($owner: String!, $name: String!, $number: Int!) {
repository(owner: $owner, name: $name) {
pullRequest(number: $number) {
reviewThreads(first: 100) {
nodes {
id
isResolved
isOutdated
path
line
originalLine
comments(first: 100) {
nodes {
id
body
createdAt
author { login }
}
}
}
}
}
}
}' \
--jq '.data.repository.pullRequest.reviewThreads.nodes[] |
{
id, isResolved, isOutdated, path, line, originalLine,
comments: [.comments.nodes[] | {author: .author.login, createdAt, body}]
}'
echo
echo "== Top-level PR comments =="
gh api "repos/$repo/issues/$pr/comments?per_page=100" \
--jq '.[] | {id, created_at, user: .user.login, body}'Length of output: 16722
The only CodeRabbit review thread has a confirmed fix and is already resolved. No unresolved consensus threads remain on PR You are interacting with an AI system. |
Addressed in cae50af: the locality check now rejects every x-forwarded-* header, with regression tests covering X-Forwarded-Proto and X-Forwarded-Port. CodeRabbit re-reviewed and subsequently ran a full review, both reporting no actionable comments.
mtrezza
changed the title
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@Parse-Dashboard/app.js`:
- Around line 105-110: Update isLoopbackPeer to recognize every address in the
127.0.0.0/8 range, including IPv4-mapped representations, while retaining ::1
support. Add coverage verifying a non-127.0.0.1 address such as 127.0.0.2 is
treated as loopback.
🪄 Autofix
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: a1141341-6cae-4d0b-9895-50460b7bd933
📒 Files selected for processing (2)
Parse-Dashboard/app.jssrc/lib/tests/RemoteAccess.test.js
# [9.3.0-alpha.5](9.3.0-alpha.4...9.3.0-alpha.5) (2026-08-11) ### Bug Fixes * Remote access restrictions not enforced when running behind a reverse proxy ([#3436](#3436)) ([60cb379](60cb379))
|
🎉 This change has been released in version 9.3.0-alpha.5 |
2 participants
Issue
The check that decides whether a request comes from localhost reads the TCP peer address, so a reverse proxy running on the same host makes every request it relays look local. The requirement that
usersbe configured for remote access is gated on that check and was therefore not enforced behind such a proxy.Approach
Split the two decisions that were sharing one check. Whether the connection needs encrypting stays keyed on the socket peer, since a loopback connection cannot be observed off the host. Whether a client may be granted access is now keyed on evidence that the request was relayed: any
X-Forwarded-*,X-Real-IPorForwardedheader, or a configuredtrustProxy, means the request is not local.The forwarded client address is deliberately not trusted as a substitute, because with
trust proxyenabled Express derives it from client-supplied headers.Tasks
Summary by CodeRabbit
Bug Fixes
Tests