mrdevel2002-ui opened a new pull request, #3364:
URL: https://github.com/apache/tika/pull/3364
tika-server's allowPerRequestConfig gate covers the /config routes
(ConfigEndpointSecurityFilter) and the multipart config part
(TikaResource.setupMultipartConfig), and tika-grpc refuses parse_context_json
under the same flag, but PipesResource.postRmeta and AsyncResource.post passed
a tuple's `parse-context` straight to ParseContextUtils.resolveAll. On a server
with allowPipes=true and allowPerRequestConfig=false a caller could therefore
still send
`{"parse-context":{"timeout-limits":{"progressTimeoutMillis":100}}}`, a
`pdf-parser` or `tesseract-ocr-parser` block, or any other self-configuring
entry, which the restricted wire deserializer deliberately leaves unscanned
because this flag is what is meant to cover it (serialization-4x.adoc). The fix
refuses such a tuple with the same 403 the config part gets, before anything in
the context is resolved, and both resources take the flag from
TikaServerConfig; a tuple's `preset` is unaffected.
PipesPerRequestConfigDisabledTest and PerR
equestConfigGateTest fail on main with `expected: <403> but was: <200>`; the
two TikaPipesTests opt in because their tuples carry parse contexts.
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.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
