Add S3 static publishing support for vanity URLs#35643
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0ef2efcf0c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| final List<S3VanityAlias> persistedAliases = | ||
| repository.findByVanityUrlId(context.endpointId, alias.vanityUrlId); | ||
| publishAlias(context, alias, file); | ||
| deleteObsoleteAliases(context, persistedAliases, alias); | ||
| repository.replaceMappingsByVanityUrlId(context.endpointId, alias.vanityUrlId, | ||
| Collections.singletonList(alias)); |
There was a problem hiding this comment.
In multi-language Vanity URLs, the contentlet identifier is shared by language variants while this alias also stores languageId; looking up and then replacing solely by endpointId + vanityUrlId means publishing one translation loads/deletes every persisted alias for the same Vanity URL identifier on that endpoint. If the other language has a different vanity path, deleteObsoleteAliases removes its S3 object and replaceMappingsByVanityUrlId drops its row, so publishing one language can break aliases for the others. Include host/language (or the full lookup) in this operation.
Useful? React with 👍 / 👎.
| publishVanityAliasesForBundleAssetsIfEnabled(endPointPublisher, bucketRegion, | ||
| bucketPrefixProp, endpoint); |
There was a problem hiding this comment.
This post-pass only handles Vanity URL contentlets from config.getAssets(), but when a bundle publishes the canonical page/file that existing Vanity URLs forward to, the vanity S3 clone is left untouched. The new S3VanityAliasService.publishAliases(S3VanityAliasContext) path that would refresh aliases by canonical path is not called anywhere, so users who update a page/file will keep serving stale content from its vanity key until they also republish the Vanity URL itself.
Useful? React with 👍 / 👎.
|
Semgrep found 15
The method identified is susceptible to injection. The input should be validated and properly If this is a critical or high severity finding, please also link this issue in the #security channel in Slack. |
1 participant
Proposed Changes
STATIC_PUSH_S3_VANITY_ALIAS_ENABLED, to enable Vanity URL handling for AWS S3 static publishing. When the flag isfalse, dotCMS behaves exactly as it does today and no Vanity URL alias is generated.true, publishing a Vanity URL to a static S3 endpoint makes dotCMS resolve the target content, identify the live resource, render or copy it, and write the static clone to the S3 path represented by the Vanity URL.s3_vanity_aliastable, which acts as an operational snapshot of the Vanity URL state on S3 and stores the aliases that have actually been materialized.Additional Info
The goal of this change is to make Vanity URLs work on static S3 publishing in the same way they already work at runtime on live dotCMS.
The implementation is intentionally opt-in and does not affect existing installations unless
STATIC_PUSH_S3_VANITY_ALIAS_ENABLED=trueis set.The
s3_vanity_aliastable is used as the source of truth for what was actually written to S3, so publish, republish, unpublish, and delete can all behave consistently without depending only on the current live content state.