capi-param-builder

Package: meta-capi-param-builder-clientjs v1.3.1 Context: Per #13, the appendix suffix on generated values (e.g. _fbc) is intentional — used for param builder analysis (SDK language, version, whether the data is new). This issue is not about what the appendix is for, but that for _fbi specifically it gets applied 3 times in a single processing pass instead of once. Description: When calling processAndCollectAllParams(url, getIpFn) a single time with a fresh (no pre-existing _fbi cookie) session, the resulting _fbi cookie value has its appendix/version suffix repeated 3 times instead of once. Root cause: The bug is in writeCookieWithToken (cookieUtil.js). Inside the for loop that iterates over possible subdomain levels (used to write the cookie at the highest domain level possible), value is reassigned on every iteration instead of being derived from a fixed base value: javascript function writeCookieWithToken(name, value, needEncoding, ttlInMs, appendix) { if (!value) return false; const fullHostname = window.location.hostname; const domainParts = fullHostname.split('.'); const finalValue = [value, appendix].join('.'); for ( let subdomainIndex = 0; subdomainIndex < domainParts.length; subdomainIndex++ ) { const domain = getSubdomainAtIndex(domainParts, subdomainIndex); if (needEncoding) { writeCookieRaw(name, finalValue, domain, ttlInMs); } else { writeCookieRawWithoutEncoding(name, finalValue, domain, ttlInMs); } if (readCookieRaw(name) === finalValue) { return true; } } return false; } ``` Impact: This produces malformed _fbi cookie values with an unbounded/inconsistent number of appendix repetitions (proportional to hostname depth), which likely breaks downstream parsing that expects the appendix as a single trailing segment.

See https://packaging.python.org/en/latest/specifications/core-metadata/#license-expression.

Summary For an apex host under a multi-label eTLD — , , — resolves the eTLD+1 to the public suffix itself () and emits / with . Browsers reject cookies scoped to a public suffix, so the cookies are never stored: every request mints a new browser id and CAPI receives no stable . Single-label eTLDs () are unaffected, and the same host with a prefix is resolved correctly, which is probably why this has gone unnoticed. Reproduction Output with 1.3.1 (and current ): Expected for the first row: . Cause In , the domain-list branch confirms the candidate is a suffix of the host and then requires the preceding character to be a dot: When the candidate is the host, is , so this reads — which since PHP 7.1 is the last character of the string, not a boundary check. It is for , the candidate is discarded, and control falls through to: which strips the first label and yields . For a two-label host the fallback returns the host, which is why sites look fine. Suggested fix Accept the exact match in the domain-list branch: That makes the configured domain list authoritative, as intended. The label-stripping fallback is still wrong for multi-label suffixes when no list is supplied, so it may be worth refusing to return a candidate that consists solely of a known public suffix. Impact (3.7.6, latest) constructs the builder as and passes straight to , so every WooCommerce store on a -style apex domain is currently unable to persist or . It also hands the same domain to the browser in the consent-release path. Verified on a live store: .