Repository navigation
[Feature]: Support BiliBili Cookie injection to unlock 1080p/4K streams and bypass WAF risk control (-352) #287
Description
Type of request
New feature
What problem would this solve?
Currently, watching BiliBili videos on TypeType suffers from two major limitations:
-
Low Video Quality (Capped at 360p / 480p):
Unauthenticated BiliBili video stream requests are restricted to 360p or 480p by Bilibili's official guest policy (try_look=1). There is currently no way to supply account credentials or cookies, making HD/4K playback impossible even for users with Bilibili accounts or VIP status. -
Datacenter IP Risk Control (
-352):
When hosting TypeType on cloud VPS / datacenter server IPs (ByteVirt, Hetzner, AWS, etc.), Bilibili's anti-scraping WAF frequently intercepts extraction requests with:
{"code": -352, "message": "风控校验失败"}
This causes channel feeds and search results to return 0 items.
What would you like to see?
I would like to see a mechanism to inject BiliBili account cookies into TypeType, similar to how YouTube authentication is handled.
The underlying PipePipe / NewPipeExtractor engine already supports BiliBili tokens natively:
// BiliBiliStreamExtractor.java:
if (ServiceList.BiliBili.hasTokens() && ServiceList.BiliBili.getCookieFunctions().contains("high_res")) {
headers.put("Cookie", Collections.singletonList(ServiceList.BiliBili.getTokens()));
} else if (this.isPremiumContent != 1) {
params.put("try_look", "1"); // forces guest low resolution!
}Suggested implementation options:
- Environment Variables:
Allow configuringBILIBILI_COOKIE(orSESSDATA,bili_jct,buvid3) indocker-compose.yml. On server boot, TypeType-Server can pass this to:ServiceList.BiliBili.setTokens(configuredBilibiliCookie);
- Admin Web Settings:
Allow instance administrators to paste the cookie string under/admin/settings. - Optional QR Code / Remote Login:
Similar to YouTube Remote Browser, provide a QR code login flow to capture and store cookies automatically.
Benefits:
- Unlocks official 1080p, 1080p60, and 4K streams for users with Bilibili accounts.
- Effectively bypasses WAF risk control
-352for self-hosted instances on cloud VPS.
Area
Token / remote login
Activity
Priveetee commentedon Sep 22, 2026
It's already in beta, so if u can test it, it'd be cool to get some feedback. Otherwise, just wait for the next release ;p (I don't have a Bilibili account, so I can't test it myself! :0)
How to setup beta
Priveetee commentedon Sep 22, 2026
Or u can test it directly on the beta, Beta Website Public Instance
Aquarius-Situla commentedon Sep 26, 2026
Hi @Priveetee, thanks for the update! We tested the Bilibili session feature on our self-hosted beta instance (
1.8.2-beta.324web /1.8.2-dev.937server) with a logged-in Bilibili account:QR Code Login & Session Encryption:
BILIBILI_SESSION_ENCRYPTION_KEY) in PostgreSQL work great!-352.Observations & Feedback:
TypeType-Video/TypeType).env.exampleanddocker-compose.ymlcurrently don't exposeBILIBILI_SESSION_ENCRYPTION_KEYtotypetype-server. I have opened a PR to add it to the environment templates so self-hosters can easily configure it.TypeType-Frontendto address these.Thanks again for the great work on Bilibili support!
Aquarius-Situla commentedon Sep 26, 2026
Just a quick follow-up: we opened the following PRs addressing the issues we identified so far:
BILIBILI_SESSION_ENCRYPTION_KEYto environment and compose templates)Please note that these PRs only resolve some of the known surface issues (toast spam, compose envs, and height matching). Based on our testing results on the self-hosted beta instance, the high-resolution playback issues don't seem to be completely resolved yet (playback may still feel blurry or struggle to consistently switch/stick to higher DASH representations).
We will continue testing and investigating further, but wanted to get these initial fixes in first so other maintainers can build on them.
Priveetee commentedon Sep 29, 2026
Thanks again for the thorough testing and for opening PRs #291, #33, and #34. Could you retest BiliBili playback on TypeType 1.9.0 and let me know whether higher-resolution streams now switch consistently and stay sharp? If playback still looks blurry, details about the selected quality and what you actually see would be really helpful. I’ll keep this issue open while we investigate.
Aquarius-Situla commentedon Sep 30, 2026
Hi @Priveetee! I retested Bilibili playback on TypeType 1.9.0 on my self-hosted instance with an authenticated Bilibili account.
On stock 1.9.0, playback was indeed locked to 480p, and the Quality selector wasn't showing up in the player settings.
Looking into
bilibili-manifest.ts, the cause seems to be:videoScore()explicitly gave 480p the top score/priority.buildBilibiliDashManifest()only picked the first video candidate (videos[0]) when constructing the DASH manifest, creating an AdaptationSet with only one single representation.I refactored
bilibili-manifest.tsto include all available representations in descending order of resolution (1080p, 720p, 480p, 360p) grouped by codec family, and tested it on my deployment. Videos now start in full 1080p right away, and all resolutions appear and switch cleanly in the player's Quality menu.I have opened a PR with the fix and test cases here:
TypeType-Video/TypeType-Frontend#36