oscerd opened a new pull request, #1897:
URL: https://github.com/apache/camel-spring-boot/pull/1897
Aligns `SpringBootPlatformHttpBinding.populateAttachments()` with the
equivalent bindings in the other
HTTP server components. Three items, all in that one method.
### 1. `fileNameExtWhitelist` was evaluated against the multipart field name
`getFileMap().forEach((name, multipartFile) -> ...)` gives `name` = the
multipart **field** key, not the
submitted file name — but line 135 propagated
`multipartFile.getOriginalFilename()` downstream regardless.
With `fileNameExtWhitelist=pdf`, a part with field name `file` carrying
`filename="shell.jsp"` was accepted,
because `FileUtil.onlyExt("file")` is `null` and the check was skipped.
Two further problems in the same block:
- **Fail-open on a missing extension.** `if (ext != null)` left `accepted =
true` when the name had no
extension, so a whitelist never rejected an extension-less name.
- **Substring matching.** `getFileNameExtWhitelist().contains(ext)` meant a
whitelist of `pdf` also matched
`invoice.pd`.
The check now runs against `getOriginalFilename()`, fails closed when a
whitelist is configured and the name
has no extension, and compares whole comma-separated tokens
case-insensitively. `FileUtil.onlyExt`'s
first-dot semantics are preserved so a whitelist entry such as `tar.gz`
keeps working.
### 2. Rejected uploads were still written to the servlet temp directory
`transferTo()` ran before the whitelist decision and the rejection branch
only logged, so a rejected upload
stayed on disk for the lifetime of the process. The decision now happens
first — `getOriginalFilename()` is
available without transferring — so a rejected file never reaches disk.
### 3. `CamelFileName` set from the raw submitted name
`Exchange.FILE_NAME` is a control header consumed by the file/ftp producers.
CAMEL-24293 applied
`FileUtil.stripPath(...)` to externally-derived names in
`camel-platform-http-vertx`, `camel-zipfile` and
`camel-tarfile`; this binding lives in camel-spring-boot and was not covered
by that change. Same
normalisation applied here, with the same comment.
`Exchange.FILE_PATH` and `FILE_LENGTH` are left as they are — they are
deliberate (added in
`2c0d67f9f87`) and the vertx reference implementation sets `FILE_PATH` too.
### Tests
`SpringBootPlatformHttpFileNameExtWhitelistTest` — 7 cases. Verified
meaningful: the 5 defect cases all fail
against the unpatched binding and pass with it; the 2 happy-path cases pass
either way as regression guards.
Full module suite: 124 tests, 0 failures.
### Deliberately not in this PR
**Path variables from the raw URI** (also listed on CAMEL-24496).
`populateRequestParameters()` evaluates
placeholders against `getRawPath()`, which returns the undecoded
`request.getRequestURI()`. Changing that is
wider than it looks: the base-class `getRawPath()` also feeds
`Exchange.HTTP_PATH` for every request, and the
override exists on purpose (CAMEL-22116, refined by CAMEL-23191 for
context-path handling). Worth doing, but
it deserves its own change and its own discussion rather than riding along
here.
### Note for CAMEL-24427
While checking the reference implementations: the **fail-open** and
**substring** problems above are not
specific to this starter. `DefaultHttpBinding.populateAttachments()` in
`camel-http-common` has both, and so
does `VertxPlatformHttpConsumer`. Only the wrong-value defect is
camel-spring-boot's own. Since CAMEL-24427
is already open for camel-servlet/camel-jetty, those two may be worth
folding into its scope so all the
engines agree — otherwise this binding is now stricter than the others.
---
_Filed by Claude Code on behalf of Andrea Cosentino._
--
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]
