Repository navigation
refuse wire-blocked component names given as bare strings in request parseContext - #3351
Merged
tballison merged 1 commit intoOct 16, 2026
Merged
Conversation
scanForBlocked only checked object keys, so a request parseContext of
{"metadata-filters":["openai-embedding-filter"]} passed the gate and
resolved to a working embedding filter bound into the request.
Generated-by: Claude Code (Claude Opus 5.5)
Contributor
There was a problem hiding this comment.
Warning
Copilot couldn't run its full agentic review because it didn't start before the timeout. Make sure your repository has a runner available, or add a copilot-code-review.yml file specifying one with the runs-on attribute. See the docs for more details.
Copilot review overview
3 open findings
assertThrows(Exception.class, ...)is broad enough that unrelated failures (including… · Newnode.asText()multiple times. To keep… · New
What changed in this PR
This PR closes a wire-gating bypass where wire-blocked component names could be provided as bare strings (e.g., in metadata-filters) and still resolve to a runnable default instance.
Changes:
- Extend parseContext wire-gate scanning to reject bare-string occurrences of wire-blocked component names.
- Add regression tests covering bare-string wire-blocked references in both server merging and restricted deserialization.
- Update deserializer documentation to reflect the new bare-string handling.
| File | Description |
|---|---|
tika-server/tika-server-standard/src/test/java/org/apache/tika/server/standard/TikaResourceTest.java |
Adds a server-side regression test ensuring bare-string metadata-filters are rejected from request parseContext. |
tika-serialization/src/test/java/org/apache/tika/serialization/WireRestrictedParseContextTest.java |
Adds a serialization-layer regression test for rejecting bare-string wire-blocked component names. |
tika-serialization/src/main/java/org/apache/tika/serialization/serdes/ParseContextDeserializer.java |
Implements bare-string checks for wire-blocked names during subtree scanning and updates related Javadocs. |
🧠 Review effort: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Comment on lines
+212
to
+215
| } else if (node.isTextual() && ComponentNameResolver.isWireBlockedName(node.asText())) { | ||
| throw new IOException("Component '" + node.asText() + "' may not be supplied via a " | ||
| + "request parseContext. It must be configured server-side in the Tika config, " | ||
| + "not at request time."); |
Comment on lines
+165
to
+166
| Exception e = assertThrows(Exception.class, | ||
| () -> restrictedMapper().readValue(json, ParseContext.class), name); |
Comment on lines
+212
to
+215
| } else if (node.isTextual() && ComponentNameResolver.isWireBlockedName(node.asText())) { | ||
| throw new IOException("Component '" + node.asText() + "' may not be supplied via a " | ||
| + "request parseContext. It must be configured server-side in the Tika config, " | ||
| + "not at request time."); |
Copilot stopped reviewing on behalf of
THausherr due to an error
October 16, 2026 03:57
Contributor
|
This will largely be obviated in 4.2.0, I hope. Until then, this makes sense. Thank you for opening this. |
Contributor
Author
|
Thanks for merging. Makes sense as a stopgap until 4.2.0 reworks this. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
ParseContextDeserializer's wire gate refuses openai-embedding-filter and jina-embedding-filter only when they appear as object keys. scanForBlocked skips bare strings as inert defaults, but these two are MetadataFilters, so a request parseContext of
{"metadata-filters":["openai-embedding-filter"]}(tika-server multipart config part, gRPC parse_context_json, FetchEmitTuple parseContext) passes the gate and resolveArrayConfig binds a working no-arg filter that POSTs document text to its default endpoint, which ComponentNameResolver says a wire request must never be able to do. The textual check is limited to the wire-blocked names, so type-blocked bare strings keep failing at the assignability check as before; the new cases in WireRestrictedParseContextTest and TikaResourceTest fail on main.There is no JIRA issue for this yet; I will open one and add the TIKA-XXXX prefix to the title and commit before this is merged.