Skip to content

[Feature]: Support BiliBili Cookie injection to unlock 1080p/4K streams and bypass WAF risk control (-352) #287

Description

@Aquarius-Situla

Type of request

New feature

What problem would this solve?

Currently, watching BiliBili videos on TypeType suffers from two major limitations:

  1. 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.

  2. 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:

  1. Environment Variables:
    Allow configuring BILIBILI_COOKIE (or SESSDATA, bili_jct, buvid3) in docker-compose.yml. On server boot, TypeType-Server can pass this to:
    ServiceList.BiliBili.setTokens(configuredBilibiliCookie);
  2. Admin Web Settings:
    Allow instance administrators to paste the cookie string under /admin/settings.
  3. 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 -352 for self-hosted instances on cloud VPS.

Area

Token / remote login

Activity

  1. Priveetee commented on Sep 22, 2026

    @Priveetee
    Member

    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

  2. Priveetee commented on Sep 22, 2026

    @Priveetee
    Member

    Or u can test it directly on the beta, Beta Website Public Instance

  3. moved this from Backlog to Testing in TypeType Roadmapon Sep 22, 2026
  4. Aquarius-Situla commented on Sep 26, 2026

    @Aquarius-Situla
    ContributorAuthor

    Hi @Priveetee, thanks for the update! We tested the Bilibili session feature on our self-hosted beta instance (1.8.2-beta.324 web / 1.8.2-dev.937 server) with a logged-in Bilibili account:

    1. QR Code Login & Session Encryption:

      • The QR code generation, scanning via the official Bilibili mobile app, and encrypted session storage (BILIBILI_SESSION_ENCRYPTION_KEY) in PostgreSQL work great!
      • Extraction requests successfully authenticate and fetch high-resolution DASH stream representations (1080p, 720p, etc.) without triggering WAF risk control -352.
    2. Observations & Feedback:

      • The central stack repository (TypeType-Video/TypeType) .env.example and docker-compose.yml currently don't expose BILIBILI_SESSION_ENCRYPTION_KEY to typetype-server. I have opened a PR to add it to the environment templates so self-hosters can easily configure it.
      • On the frontend player side, we noticed two minor UX issues during DASH playback (a false-positive "Original audio unavailable" toast due to Bilibili's single-language audio tracks, and representation height matching in the quality selector). We are opening separate PRs in TypeType-Frontend to address these.

    Thanks again for the great work on Bilibili support!

  5. Aquarius-Situla commented on Sep 26, 2026

    @Aquarius-Situla
    ContributorAuthor

    Just a quick follow-up: we opened the following PRs addressing the issues we identified so far:

    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.

  6. Priveetee commented on Sep 29, 2026

    @Priveetee
    Member

    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.

  7. Aquarius-Situla commented on Sep 30, 2026

    @Aquarius-Situla
    ContributorAuthor

    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:

    1. videoScore() explicitly gave 480p the top score/priority.
    2. buildBilibiliDashManifest() only picked the first video candidate (videos[0]) when constructing the DASH manifest, creating an AdaptationSet with only one single representation.
    3. Because only a single representation was in the MPD, Dash.js had no alternative bitrates/resolutions to switch to, and the player automatically hid the Quality menu since only 1 quality was available.

    I refactored bilibili-manifest.ts to 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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area: backendTypeType-Server API or extractionarea: frontendFrontend web apparea: self-hostingSelf-hosting, installation, updates, and deployment stackbugSomething isn't workingpriority: mediumMedium priority

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions