facebook / facebook/capi-param-builder
_fbi cookie value gets its version suffix duplicated 3x on a single processAndCollectAllParams call
- Dominant language
- JavaScript
- Stars
- 33
- Forks
- 9
- PR merge metrics
- No merged PRs in 30d
Description
Package: meta-capi-param-builder-clientjs v1.3.1
Context: Per [#13](https://github.com/facebook/capi-param-builder/issues/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('.');
for (
let subdomainIndex = 0;
subdomainIndex < domainParts.length;
subdomainIndex++
) {
const domain = getSubdomainAtIndex(domainParts, subdomainIndex);
value = [value, appendix].join('.'); // <-- mutates `value` on every iteration
if (needEncoding) {
writeCookieRaw(name, value, domain, ttlInMs);
} else {
writeCookieRawWithoutEncoding(name, value, domain, ttlInMs);
}
if (readCookieRaw(name) === value) {
return true;
}
}
return false;
}
```
Since value is never reset, the appendix gets concatenated once per loop iteration. The number of iterations equals domainParts.length (the number of dot-separated parts in window.location.hostname), which is why a hostname with 3 parts (e.g. www.example.com) produces the appendix 3 times.
Steps to reproduce:
Clear the _fbi cookie (and confirm no prior value exists).
Call processAndCollectAllParams(url, getIpFn) exactly once, where getIpFn returns a valid IPv6 address (confirmed via Network tab: only a single request to the IP-resolving endpoint is made).
Inspect the resulting _fbi cookie value.
Expected:
.
Actual:
...
Concrete example observed:
2800:2364:3200:3634:3521:ab6c:c3e9:96d5.AQYCAQMB.AQYCAQMB.AQYCAQMB
Suggested fix:
Compute the final value once, outside the loop, instead of mutating it across iterations:
```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.
Contributor guide
Research direction
Start in cookieUtil.js at writeCookieWithToken and reproduce the issue by calling processAndCollectAllParams once with a fresh _fbi cookie on a hostname with three parts. Verify the resulting cookie against the expected IPv6 address plus one appendix, and confirm that existing cookie-writing behavior still works across the hostname's domain levels.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- web-dev
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 88/100