morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[GH-ISSUE #2552] fix(jeb): accepts endpoint paths beyond the MCP route #869

New issue

Closed

opened 2026-10-15 18:29:09 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-15 18:29:09 +00:00

Owner

Originally created by @coygeek on GitHub (Oct 13, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/2552

Summary

A caller can configure REA_JEB_MCP_URL with a path beyond the supported MCP route, and REA accepts the setting and forwards that URL to the JEB connection. This violates the endpoint parser's stated rejection contract and lets an invalid route proceed to transport initialization instead of producing a configuration diagnostic.

Runtime or environment

The failure was verified at source baseline a2d8b94dd5 and is still present at 8b181716ac, Node v26.10.0, npm 11.19.1, Vitest 5.0.3, and installed lockfile dependencies. No JEB engine is required to reproduce the validation failure.

Steps to reproduce

At the stated baseline, create src/jeb/JebEndpointRouteVerification.test.ts with the fixture below.
Run npm run test:focused -- src/jeb/JebEndpointRouteVerification.test.ts.
Observe that the rejection assertion fails for each input, while the documented route passes the control.

import { expect, it } from "vitest";
import { parseJebMcpEndpoint } from "./JebMcpEndpoint.js";

it("accepts the documented route", () => {
  expect(parseJebMcpEndpoint("http://127.0.0.1:8425/mcp").ok).toBe(true);
});

it.each(["/mcp/extra", "/not-mcp"])("rejects %s", (path) => {
  expect(parseJebMcpEndpoint(`http://127.0.0.1:8425${path}`).ok).toBe(false);
});

The verifier ran an equivalent fixture plus a production-composition test with an injected connection factory. That test set REA_JEB_MCP_URL to each URL and observed the factory receive the exact URL. The factory simulated an unavailable transport; it did not contact a server.

Expected behavior

An endpoint with additional path segments beyond the MCP route must fail endpoint validation. For http://127.0.0.1:8425/mcp/extra, the parser should return an input error rather than success. When the same URL arrives through REA_JEB_MCP_URL, provider composition should report the invalid setting before creating a connection. The documented http://127.0.0.1:8425/mcp route must continue to pass.

Actual behavior

Both http://127.0.0.1:8425/mcp/extra and http://127.0.0.1:8425/not-mcp returned success with their pathnames preserved. The production composition guard also accepted both settings and passed each URL unchanged to its connection factory. Both rejection assertions failed with expected true to be false; the complete verifier fixture reported two failed tests and two passed tests, exit status 1.

With a fixture that throws fixture transport unavailable, availability reported that transport reason rather than the invalid-setting diagnostic. This establishes the validation and error-routing behavior locally. An actual JEB server response for these paths was not tested.

Evidence

Expected source: src/jeb/JebMcpEndpoint.ts:9-15 promises rejection of paths with segments beyond the MCP route; the default /mcp route is declared at line 7. docs/jeb-analysis.md:9 documents REA_JEB_MCP_URL and the default route, but does not separately state the path restriction.
Failure source: src/jeb/JebMcpEndpoint.ts:19-56 returns success after checking other URL components without checking pathname. The focused probe observed success for both inputs and exact forwarding through src/composition/jeb.ts:13-33 and src/jeb/JebProvider.ts:106-114.
Evidence provenance: observed
Local verification: reproduced
Reproduction completeness: complete

The real connection's use of the accepted URL as the StreamableHTTPClientTransport endpoint is established from src/jeb/JebMcpConnection.ts:157-159. The verifier did not execute that HTTP transport. Passing controls covered the default route and rejection of unsupported schemes, remote hosts, embedded credentials, empty queries, and empty fragments.

Related report #2143 concerned already-invalid endpoint values crashing unrelated CLI/MCP workflows. Its merged fix isolated those errors in provider composition and did not add path validation. The present failure is a separate contract violation, and that closed report is reference-only.

Restoration check

For the two reproduced URLs, endpoint parsing must return failure instead of success. Through REA_JEB_MCP_URL, the same invalid route must produce a configuration diagnostic naming the setting without creating a connection. The documented /mcp route and its default must remain accepted. Existing scheme, literal-loopback-host, credential, query, and fragment rejection controls must remain intact. This check does not prescribe behavior for untested trailing-slash or encoded path variants.

Triage assessment

Impact level: P2
Assessment status: supported
Impact basis: Invalid endpoint paths pass configuration validation and reach connection construction, so affected callers receive transport handling instead of the promised route rejection. This is a bounded behavior defect; the probe established no data loss or failure of unrelated providers.
Workaround status: available
Workaround basis: Configure the documented /mcp route instead of either invalid path. The verifier observed that the documented URL and the default pass endpoint validation; this workaround restores the route setting without a code change.

Originally created by @coygeek on GitHub (Oct 13, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/2552 ## Summary A caller can configure REA_JEB_MCP_URL with a path beyond the supported MCP route, and REA accepts the setting and forwards that URL to the JEB connection. This violates the endpoint parser's stated rejection contract and lets an invalid route proceed to transport initialization instead of producing a configuration diagnostic. ## Runtime or environment The failure was verified at source baseline a2d8b94dd50dab8d966239dd63ab84718aa8b4b4 and is still present at 8b181716aca2cb467be499cba226abfb5ae19141, Node v26.10.0, npm 11.19.1, Vitest 5.0.3, and installed lockfile dependencies. No JEB engine is required to reproduce the validation failure. ## Steps to reproduce 1. At the stated baseline, create `src/jeb/JebEndpointRouteVerification.test.ts` with the fixture below. 2. Run `npm run test:focused -- src/jeb/JebEndpointRouteVerification.test.ts`. 3. Observe that the rejection assertion fails for each input, while the documented route passes the control. ```ts import { expect, it } from "vitest"; import { parseJebMcpEndpoint } from "./JebMcpEndpoint.js"; it("accepts the documented route", () => { expect(parseJebMcpEndpoint("http://127.0.0.1:8425/mcp").ok).toBe(true); }); it.each(["/mcp/extra", "/not-mcp"])("rejects %s", (path) => { expect(parseJebMcpEndpoint(`http://127.0.0.1:8425${path}`).ok).toBe(false); }); ``` The verifier ran an equivalent fixture plus a production-composition test with an injected connection factory. That test set REA_JEB_MCP_URL to each URL and observed the factory receive the exact URL. The factory simulated an unavailable transport; it did not contact a server. ## Expected behavior An endpoint with additional path segments beyond the MCP route must fail endpoint validation. For `http://127.0.0.1:8425/mcp/extra`, the parser should return an input error rather than success. When the same URL arrives through REA_JEB_MCP_URL, provider composition should report the invalid setting before creating a connection. The documented `http://127.0.0.1:8425/mcp` route must continue to pass. ## Actual behavior Both `http://127.0.0.1:8425/mcp/extra` and `http://127.0.0.1:8425/not-mcp` returned success with their pathnames preserved. The production composition guard also accepted both settings and passed each URL unchanged to its connection factory. Both rejection assertions failed with `expected true to be false`; the complete verifier fixture reported two failed tests and two passed tests, exit status 1. With a fixture that throws `fixture transport unavailable`, availability reported that transport reason rather than the invalid-setting diagnostic. This establishes the validation and error-routing behavior locally. An actual JEB server response for these paths was not tested. ## Evidence - Expected source: `src/jeb/JebMcpEndpoint.ts:9-15` promises rejection of paths with segments beyond the MCP route; the default `/mcp` route is declared at line 7. `docs/jeb-analysis.md:9` documents REA_JEB_MCP_URL and the default route, but does not separately state the path restriction. - Failure source: `src/jeb/JebMcpEndpoint.ts:19-56` returns success after checking other URL components without checking pathname. The focused probe observed success for both inputs and exact forwarding through `src/composition/jeb.ts:13-33` and `src/jeb/JebProvider.ts:106-114`. - Evidence provenance: observed - Local verification: reproduced - Reproduction completeness: complete The real connection's use of the accepted URL as the StreamableHTTPClientTransport endpoint is established from `src/jeb/JebMcpConnection.ts:157-159`. The verifier did not execute that HTTP transport. Passing controls covered the default route and rejection of unsupported schemes, remote hosts, embedded credentials, empty queries, and empty fragments. Related report [#2143](https://github.com/morluto/rea/issues/2143) concerned already-invalid endpoint values crashing unrelated CLI/MCP workflows. Its merged fix isolated those errors in provider composition and did not add path validation. The present failure is a separate contract violation, and that closed report is reference-only. ## Restoration check For the two reproduced URLs, endpoint parsing must return failure instead of success. Through REA_JEB_MCP_URL, the same invalid route must produce a configuration diagnostic naming the setting without creating a connection. The documented `/mcp` route and its default must remain accepted. Existing scheme, literal-loopback-host, credential, query, and fragment rejection controls must remain intact. This check does not prescribe behavior for untested trailing-slash or encoded path variants. ## Triage assessment - Impact level: P2 - Assessment status: supported - Impact basis: Invalid endpoint paths pass configuration validation and reach connection construction, so affected callers receive transport handling instead of the promised route rejection. This is a bounded behavior defect; the probe established no data loss or failure of unrelated providers. - Workaround status: available - Workaround basis: Configure the documented `/mcp` route instead of either invalid path. The verifier observed that the documented URL and the default pass endpoint validation; this workaround restores the route setting without a code change.

bsakaguchi

2026-10-15 18:29:09 +00:00

closed this issue
added the
area: mcp

bug
labels

bsakaguchi commented

2026-10-15 18:29:10 +00:00

Author

Owner

@morluto commented on GitHub (Oct 14, 2026):

Verified the reported defect is addressed on main by d4bd65c53c.

Root cause and resolution: The endpoint parser accepted unsupported routes and passed the URL to transport setup.

Validation: src/jeb/JebMcpEndpoint.test.ts — accepts only the declared MCP route accepts /mcp and /mcp/, rejects /mcp/extra, /not-mcp, and /, before connection setup; adjacent assertion rejects empty query/fragment.

Evidence: CI run 500e: owner unchanged and assertions passed.

Verification scope: Route parser contract only; no JEB engine session claimed.

Current main CI has separate failures under repair; this closure does not claim the complete main workflow is green.

@morluto commented on GitHub (Oct 14, 2026): Verified the reported defect is addressed on main by d4bd65c53c0254d0195cc7ab8da163dcadfd3b9b. Root cause and resolution: The endpoint parser accepted unsupported routes and passed the URL to transport setup. Validation: `src/jeb/JebMcpEndpoint.test.ts` — `accepts only the declared MCP route` accepts `/mcp` and `/mcp/`, rejects `/mcp/extra`, `/not-mcp`, and `/`, before connection setup; adjacent assertion rejects empty query/fragment. Evidence: CI run 500e: owner unchanged and assertions passed. Verification scope: Route parser contract only; no JEB engine session claimed. Current main CI has separate failures under repair; this closure does not claim the complete main workflow is green.

bsakaguchi referenced this issue

2026-10-16 21:17:03 +00:00

[PR #869] [MERGED] refactor: give Inspector its own capability directory #2307

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#869

No description provided.

Rows
Columns