oscerd opened a new pull request, #25179:
URL: https://github.com/apache/camel/pull/25179
# CAMEL-24279
`GoogleCloudStorageConsumer` builds the local download destination by
appending the remote object
name to the configured `downloadFileName` directory via the `${file:name}`
token, which returns the
name unchanged. A remote object name containing path segments could
therefore resolve outside the
configured directory.
## Change
* New `GoogleCloudStorageFileNameHelper.assertWithinDirectory(...)`
(package-private, no new public
API, no new module dependency): normalizes the resolved path lexically and
compares it against the
configured directory on path-segment boundaries, throwing
`IllegalArgumentException` when it
resolves outside.
* Wired into `GoogleCloudStorageConsumer.evaluateFileExpression`, guarded so
it applies to the branch
where the object name is appended to a plain directory.
This aligns the component with the containment already applied to the
file/FTP/SFTP/SMB consumers
(CAMEL-23765, CAMEL-23868) and to the Azure Storage Blob/DataLake download
paths (CAMEL-23942) —
the same approach as `AzureFileNameHelper.resolveWithinDirectory`.
## Design notes
* **Containment rather than stripping the path component.** Google Cloud
Storage object names
commonly use `/` as a pseudo-directory separator, so using
`${file:onlyname}` /
`FileUtil.stripPath` would flatten nested names and make distinct objects
collide on the same
local file. Nested names keep mapping to sub-directories exactly as
before; only names resolving
outside the configured directory are rejected.
* **A `downloadFileName` that already contains an expression is deliberately
out of scope** — that
local path is constructed by the route author.
## Tests
* `GoogleCloudStorageFileNameHelperTest` (8) — plain, nested and
normalizing-back-inside names
accepted; parent-directory segments (leading, repeated, nested in the key)
rejected; plus a
sibling-directory case that a plain `String.startsWith` check would
wrongly accept.
* `GoogleCloudStorageConsumerDownloadPathTest` (5) — exercises the consumer
path itself, including
the route-author-expression case.
* Full module suite green (25 tests), including the pre-existing
`ConsumerDownloadLocalTest`.
* Full reactor build `mvn clean install -DskipTests` green, no
regenerated-file drift.
Upgrade-guide note added to `camel-4x-upgrade-guide-4_22.adoc`.
Backports to `camel-4.18.x` and `camel-4.14.x` to follow — the same code is
present on both.
_Claude Code on behalf of oscerd_
--
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]
