Context
#141 / #142 fixed browser-session (xoxc/xoxd) API calls sending a non-browser User-Agent, which Slack's Enterprise Grid session-security policy was flagging as unexpected_user_agent and using to kill the session (forcing a logout of the real browser tab that owned it).
That fix only addressed the User-Agent header. src/slack/client.ts (browserApi, browserApiMultipart), src/slack/files.ts, and src/slack/canvas.ts still send a header set that's otherwise nothing like a real browser request: no Accept, Accept-Language, Accept-Encoding, sec-ch-ua, sec-ch-ua-mobile, sec-ch-ua-platform, or sec-fetch-* headers.
We don't have confirmation that Slack's fingerprinting checks any of these today. But since it's plausible it checks more than just UA, and the failure mode (force-logout of a real browser session, not just a failed API call) is high-cost, it's worth closing the gap defensively rather than waiting for the next flavor of this bug report.
Proposal
Add a shared "browser-shaped headers" helper (mirroring getUserAgent() in src/lib/version.ts) that all three browser-session call sites use, sending a header set consistent with a real Chrome/macOS request:
Accept, Accept-Language, Accept-Encodingsec-ch-ua, sec-ch-ua-mobile, sec-ch-ua-platformsec-fetch-site, sec-fetch-mode, sec-fetch-dest
Same override pattern as AGENT_SLACK_USER_AGENT/--user-agent would make sense here too, so a user whose actual browser/OS differs from the hardcoded defaults can match their own fingerprint more closely.
Out of scope: this only covers request headers. It doesn't address TLS/JA3-level or HTTP-stack-level fingerprinting differences between Bun's fetch and a real Chromium network stack, which no header change can fix.
Context
#141 / #142 fixed browser-session (xoxc/xoxd) API calls sending a non-browser
User-Agent, which Slack's Enterprise Grid session-security policy was flagging asunexpected_user_agentand using to kill the session (forcing a logout of the real browser tab that owned it).That fix only addressed the
User-Agentheader.src/slack/client.ts(browserApi,browserApiMultipart),src/slack/files.ts, andsrc/slack/canvas.tsstill send a header set that's otherwise nothing like a real browser request: noAccept,Accept-Language,Accept-Encoding,sec-ch-ua,sec-ch-ua-mobile,sec-ch-ua-platform, orsec-fetch-*headers.We don't have confirmation that Slack's fingerprinting checks any of these today. But since it's plausible it checks more than just UA, and the failure mode (force-logout of a real browser session, not just a failed API call) is high-cost, it's worth closing the gap defensively rather than waiting for the next flavor of this bug report.
Proposal
Add a shared "browser-shaped headers" helper (mirroring
getUserAgent()insrc/lib/version.ts) that all three browser-session call sites use, sending a header set consistent with a real Chrome/macOS request:Accept,Accept-Language,Accept-Encodingsec-ch-ua,sec-ch-ua-mobile,sec-ch-ua-platformsec-fetch-site,sec-fetch-mode,sec-fetch-destSame override pattern as
AGENT_SLACK_USER_AGENT/--user-agentwould make sense here too, so a user whose actual browser/OS differs from the hardcoded defaults can match their own fingerprint more closely.Out of scope: this only covers request headers. It doesn't address TLS/JA3-level or HTTP-stack-level fingerprinting differences between Bun's
fetchand a real Chromium network stack, which no header change can fix.