fix(experiments): support /cmsHomePage vanity for experiment URL matching

[dsolistorres]

Summary

Fixes the remaining scope of #34747 — Experiments not firing when the experiment page is reached via the legacy /cmsHomePage vanity URL fallback.

• VanityUrlAPIImpl.resolveVanityUrl has a legacy fallback (dotCMS/src/main/java/com/dotcms/vanityurl/business/VanityUrlAPIImpl.java:257-261) that, when a visitor requests / and no vanity directly matches, resolves /cmsHomePage instead and forwards (action=200) to the configured target page. The browser URL bar stays at /.
• ExperimentUrlPatternCalculator.getVanityUrlsRegex was only adding the vanity's own URI (/cmsHomePage) as a regex alternative — so the incoming analytics URL http://site/ (or http://site) never matched and the Experiment engine always served the Original variant.
• This PR adds a /? alternative (matching / and empty) to the generated regex when any returned vanity has URI /cmsHomePage. The approach mirrors the existing permissive pattern used in RootIndexRegexUrlPatterStrategy for the real root-index page.

An earlier PR (#26803, commit 53718e0) fixed the common vanity-URL case but did not cover the /cmsHomePage legacy fallback — details in the issue comment thread.

Also removes an unused CMS_HOME_PAGE constant from VisitorFilter.

Test plan

• New integration test ExperimentUrlPatternCalculatorIntegrationTest#experimentWithCmsHomePageVanity — fails on main, passes on this branch.
• Regression run of the four pre-existing vanity tests in the same class — all still pass (Tests run: 5, Failures: 0, Errors: 0).
• QA: see "Notes for QA" on the issue — confirm fix for the /cmsHomePage scenario and regression-check other vanity-URL + Experiment combinations.

Refs: #34747

🤖 Generated with Claude Code

[claude]

Claude finished @dsolistorres's task in 4m 8s —— View job

---

🔍 dotCMS Backend Review

• Load dotCMS conventions
• Get the Java diff
• Run security, database, Java standards, and REST API sub-agents in parallel
• Consolidate findings and post review

Review posted to comment #4277243445. Found 5 medium-severity findings across security, database, and Java standards domains. REST API review was clean (NO_FINDINGS).

[claude]

🔍 dotCMS Backend Review

[🟡 Medium] dotCMS/src/main/java/com/dotcms/experiments/business/ExperimentUrlPatternCalculator.java:122

When CachedVanityUrl.normalize() returns "" for an invalid URI, vanity.pattern.pattern() returns "". That empty string is embedded verbatim into DEFAULT_URL_REGEX_TEMPLATE, producing a path alternative that matches any URL — not just the experiment's page. The assembled catch-all regex is then serialized into the Analytics SDK payload, which could cause the experiment to record page-view events for every URL the visitor navigates to. This is pre-existing in the prior .pattern toString path as well, but the explicit .pattern() call makes it easy to guard here.

// line 122 — empty pattern source yields a catch-all template expansion
.map(vanity -> String.format(DEFAULT_URL_REGEX_TEMPLATE, vanity.pattern.pattern()))

💡 Add a guard to skip blank pattern sources:

vanityUrls.stream()
    .filter(vanity -> !vanity.pattern.pattern().isEmpty())
    .map(vanity -> String.format(DEFAULT_URL_REGEX_TEMPLATE, vanity.pattern.pattern()))

---

Next steps

• 🟡 You can ask me to handle mechanical fixes inline: @claude fix <issue description> in <File.java>
• Every new push triggers a fresh review automatically

[dsolistorres]

Tracked the client-side ReDoS hardening discussion as a follow-up: #35379.

Surfaced during this review but scoped out of the PR — it's a cross-cutting SDK hardening decision (Worker + timeout, static regex linting, re2-wasm, or input-length cap) that deserves its own design review rather than being bolted onto the /cmsHomePage fix.

[claude]

Pull Request Unsafe to Rollback!!!

• Category: M-4 — OSGi Public Interface / Service Change
• Risk Level: 🟡 MEDIUM
• Why it's unsafe: VanityUrlAPI.findByForward is a public interface method whose signature changed from 4 parameters to 5 parameters (new boolean includeSystemHost appended). The old 4-argument overload is gone — not deprecated, not kept as a default. Any OSGi plugin that (a) calls APILocator.getVanityUrlAPI().findByForward(host, language, forward, 200) will get NoSuchMethodError at runtime on N, or (b) implements VanityUrlAPI will fail activation with AbstractMethodError because the new method is not implemented. For rollback: if an operator has updated a plugin to use the new 5-arg signature compiled against N, rolling back the dotCMS JAR to N-1 immediately breaks that plugin with NoSuchMethodError.
• Code that makes it unsafe: dotCMS/src/main/java/com/dotcms/vanityurl/business/VanityUrlAPI.java — old declaration List<CachedVanityUrl> findByForward(Host host, Language language, String forward, int action) is replaced (not overloaded) by List<CachedVanityUrl> findByForward(Host host, Language language, String forward, int action, boolean includeSystemHost).
• Alternative (if possible): Add the 5-arg overload as a new default interface method and keep the old 4-arg signature as a deprecated default that delegates to the new one with includeSystemHost = false. This preserves binary compatibility for all existing callers and implementors while surfacing the new behavior. Example: default List<CachedVanityUrl> findByForward(Host h, Language l, String f, int a) { return findByForward(h, l, f, a, false); }

---

• Category: M-4 — OSGi Public Interface / Service Change (constant removal from Impl)
• Risk Level: 🟡 MEDIUM
• Why it's unsafe: VanityUrlAPIImpl.LEGACY_CMS_HOME_PAGE was a public static final field that was removed from the Impl class and moved to the VanityUrlAPI interface. Java does not make static members of interfaces accessible via implementing classes at the binary level, so any OSGi plugin that imported com.dotcms.vanityurl.business.VanityUrlAPIImpl.LEGACY_CMS_HOME_PAGE will get NoSuchFieldError on N. After rollback to N-1 such a plugin works again — but the N-to-N-1 rollback window is the risk.
• Code that makes it unsafe: dotCMS/src/main/java/com/dotcms/vanityurl/business/VanityUrlAPIImpl.java line removed: public static final String LEGACY_CMS_HOME_PAGE = "/cmsHomePage";. Confirmed consumer migration in dotcms-integration/src/test/java/com/dotmarketing/filters/FiltersTest.java: import changed from VanityUrlAPIImpl.LEGACY_CMS_HOME_PAGE to VanityUrlAPI.LEGACY_CMS_HOME_PAGE.
• Alternative (if possible): Keep VanityUrlAPIImpl.LEGACY_CMS_HOME_PAGE as a @Deprecated forwarding constant pointing at the new interface constant (public static final String LEGACY_CMS_HOME_PAGE = VanityUrlAPI.LEGACY_CMS_HOME_PAGE;) for one release cycle, then remove it.

[claude]

Pull Request Unsafe to Rollback!!!

• Category: M-4 — OSGi Public Interface / Service Change (residual — partially mitigated since prior analysis)
• Risk Level: 🟡 MEDIUM
• Why it's unsafe: VanityUrlAPI now declares findByForward(Host, Language, String, int, boolean) as a new abstract method. Any OSGi plugin that previously implemented VanityUrlAPI (as an alternative provider registered with APILocator) implemented only the old 4-arg abstract form. On N, that plugin's class has no implementation of the 5-arg abstract method. When ExperimentUrlPatternCalculator calls APILocator.getVanityUrlAPI().findByForward(host, language, uri, 200, true), the JVM dispatches to the registered provider; if that provider is a plugin instance lacking the 5-arg method, it throws AbstractMethodError.
  • What is now safe (improvements since prior analysis): The old 4-arg overload is preserved as a default method — so OSGi plugins that only call findByForward(4-arg) are no longer affected. Additionally, VanityUrlAPIImpl.LEGACY_CMS_HOME_PAGE is retained as a forwarding alias (= VanityUrlAPI.LEGACY_CMS_HOME_PAGE), so plugins referencing the field on the Impl class still compile and run correctly.
  • What remains unsafe: The 5-arg method is declared abstract (not default). A plugin that implements VanityUrlAPI — i.e., provides an alternative provider registered via the OSGi service registry — does not implement findByForward(5-arg). Any invocation of the 5-arg method on that plugin instance raises AbstractMethodError.
• Code that makes it unsafe: dotCMS/src/main/java/com/dotcms/vanityurl/business/VanityUrlAPI.java lines 142–143 — List<CachedVanityUrl> findByForward(Host host, Language language, String forward, int action, boolean includeSystemHost); is abstract with no default body. The only call site is ExperimentUrlPatternCalculator.getVanityUrlsRegex() (line 112), which reaches this through APILocator.getVanityUrlAPI().
• Alternative (if possible): Give the 5-arg method a default body that delegates to the host-only load path (matching the pre-PR behavior), so plugins that do not override it get a safe, backward-compatible implementation automatically. Example:

  default List<CachedVanityUrl> findByForward(Host host, Language language,
                                               String forward, int action,
                                               boolean includeSystemHost) {
      // default: host-only; override to include SYSTEM_HOST
      return findByForward(host, language, forward, action);
  }

  Then have VanityUrlAPIImpl override this default with the SYSTEM_HOST-aware logic. This makes the 5-arg a non-breaking addition for all existing implementors.

[claude]

🔍 dotCMS Backend Review

[🟡 Medium] dotCMS/src/main/java/com/dotcms/vanityurl/business/VanityUrlAPIImpl.java:484

cachedVanityUrl.forwardTo.equals(forward) calls .equals on the field, not the parameter. If any CachedVanityUrl in the cache has a null forwardTo (corrupted or partially-constructed entry), this throws NullPointerException inside the stream and aborts experiment URL pattern calculation. CachedVanityUrl's own equals/hashCode already guard against null forwardTo, indicating the authors know it can be null.

.filter(cachedVanityUrl -> cachedVanityUrl.forwardTo.equals(forward))

💡 Flip the receiver: forward.equals(cachedVanityUrl.forwardTo), or use Objects.equals(cachedVanityUrl.forwardTo, forward).

---

[🟡 Medium] dotCMS/src/main/java/com/dotcms/vanityurl/business/VanityUrlAPIImpl.java:462-469

The 4-arg findByForward delegates to the 5-arg overload via a direct this.findByForward(...) self-call. The inline comment asserts "ByteBuddy advice fires on the self-invocation" — this is factually incorrect. ByteBuddy/CDI proxy advice only intercepts calls arriving through the proxy, not this. direct invocations within the same class. As a result, the @CloseDBIfOpened annotation on the 5-arg method does not fire when the 4-arg overload is the external entry point, leaving any DB connection opened by the load() → findInDb() cold-cache path potentially unclosed.

// "ByteBuddy advice fires on the self-invocation" ← factually incorrect
return findByForward(host, language, forward, action, false);

💡 Remove the incorrect comment. Add @CloseDBIfOpened directly to the 4-arg overload so the annotation fires correctly when it is the proxy-dispatched entry point.

---

[🟡 Medium] dotCMS/src/main/java/com/dotcms/vanityurl/business/VanityUrlAPIImpl.java:70

VanityUrlAPIImpl.LEGACY_CMS_HOME_PAGE is retained as a forwarding alias for source compatibility, and the Javadoc correctly says new code should use VanityUrlAPI.LEGACY_CMS_HOME_PAGE. However, the field is missing @Deprecated, so IDEs and compilers will not warn callers who reference the old location — defeating the migration signal the compat alias is supposed to provide.

public static final String   LEGACY_CMS_HOME_PAGE = VanityUrlAPI.LEGACY_CMS_HOME_PAGE;

💡 Add @Deprecated to the field so callers see the IDE warning to migrate to VanityUrlAPI.LEGACY_CMS_HOME_PAGE.

---

[🟡 Medium] dotCMS/src/main/java/com/dotcms/vanityurl/business/VanityUrlAPI.java:142-147

findByForward(..., includeSystemHost=true) performs no permission check before broadening the result to include SYSTEM_HOST vanities. The restriction to system-user / internal contexts is documented only in Javadoc, with no enforcement at the API boundary. Any future caller in a request-scoped path (REST endpoint, rendering pipeline) that passes includeSystemHost=true will silently receive SYSTEM_HOST vanity forwardTo paths and URI patterns for a host the caller may not be authorized to inspect.

default List<CachedVanityUrl> findByForward(..., final boolean includeSystemHost) {
    return findByForward(host, language, forward, action); // no permission guard
}

💡 Consider moving the SYSTEM_HOST-broadened query to a package-private helper in VanityUrlAPIImpl so it is not accessible through the public interface flag.

---

[🟡 Medium] dotCMS/src/main/java/com/dotcms/experiments/business/ExperimentUrlPatternCalculator.java:127

vanity.pattern.pattern() embeds raw admin-authored regex source verbatim into the Analytics SDK payload, which is evaluated client-side via new RegExp(...).test(...). VanityUrlUtil.isValidRegex verifies Java syntax validity but does not bound complexity. A vanity URI with nested quantifiers (e.g. /(a+)+$) that passes Java validation is a ReDoS pattern in browser JS engines. The code's own Javadoc acknowledges this and links to follow-up #35379; surfaced here because the assembled pattern ships to every visitor's browser for any page under an active experiment.

.map(vanity -> String.format(DEFAULT_URL_REGEX_TEMPLATE, vanity.pattern.pattern()))

💡 A server-side complexity heuristic (e.g. reject patterns containing (x+)+, (x*)*) at assembly time would eliminate the client-side DoS vector before #35379 ships.

---

Next steps

• 🟡 You can ask me to handle mechanical fixes inline: @claude fix <issue description> in <File.java>
• Every new push triggers a fresh review automatically