ql-script-hub: a flat script collection for the Qinglong panel

One Python file per service, no shared library

ql-script-hub is a collection of standalone Python scripts intended to run inside the Qinglong panel, the scheduler many Chinese home-lab users run on a NAS or a small server. Each target service gets its own file at the top level of the repository: aliyunpan_signin.py for Aliyun Drive, quark_signin.py for Quark Drive, ty_netdisk_checkin.py for Tianyi Drive, baiduwangpan_checkin.py for Baidu Drive, nodeseek_checkin.py for the NodeSeek forum, tieba_checkin.py for Baidu Tieba, nga_checkin.py for NGA, enshan_checkin.py for the Enshan forum, smzdm_checkin.py for Smzdm, SFSU_checkin.py for SF Express, CDRail.py for Chengdu Metro, plus ikuuu, tsthb, deepflood, HiFiti and passnat check-ins. There is no package to install and no framework to learn. You copy a script into the panel and it runs on a cron schedule. That flatness is the main design decision here: it makes adoption trivial, and it also means there is no shared login helper, no retry policy and no common error handling shared across services.

The Qinglong subscription replaces a pip install

The README gives installation as a subscription rather than a package manager step. The documented path is to open the subscription management screen of the Qinglong panel and add the repository address https://github.com/agluo/ql-script-hub.git, which pulls the scripts into the panel and keeps them updated on the next subscription run. The stated environment requirements are Qinglong 2.10 or newer and Node.js 14 or newer. In practice this means the panel, not your shell, is the execution environment, and the scripts are scheduled as panel tasks rather than invoked from a terminal. The repository states that a unified configuration file format is used across scripts and that the directory layout is kept clean for extension, but the README does not describe a shared configuration file that the scripts read, so treat that claim as an aspiration rather than a documented mechanism.

Cookies are the credential, and the credential is the whole attack surface

Every service in the list is configured through environment variables, and the table shows the pattern plainly. Cloud drives want a cookie or a refresh token: QUARK_COOKIE is marked required with multiple accounts separated by && or by a line break, ALIYUN_REFRESH_TOKEN is required with multiple accounts separated by line breaks, and TIEBA_COOKIE takes a complete cookie string such as BDUSS and STOKEN values. The NodeSeek entry requires NODESEEK_COOKIE and shows accounts joined with &, while the Enshan forum takes a single account cookie in enshan_cookie. SF Express is configured differently again, through a login URL captured from traffic and stored in sfsyUrl. Aliyun Drive adds AUTO_UPDATE_TOKEN, default true, which maintains the refresh token automatically, and PRIVACY_MODE, also default true, which masks sensitive values in displayed output. No script in this set uses a documented official API key.

CDRAIL_DATA shows where the pattern gets brittle

The Chengdu Metro script is the most demanding entry in the configuration tables, and it exposes the weak point of the approach. CDRAIL_DATA is required and must be copied out of captured request headers. It needs token, app-token and a Cookie value, and deviceId is recommended, with the README noting that the value inside the repository is a placeholder and that your own captured device identifier should replace it. The variable accepts either a JSON object or a querystring, and multiple accounts can be separated by line breaks or by @. The JSON form is the one the README marks as preferred, and setting it in the shell before a manual run looks like this:

export CDRAIL_DATA='{"token":"xxx","app-token":"yyy","Cookie":"zzz","deviceId":"xxx-xxx"}'

The querystring form carries the same fields in a different shape:

export CDRAIL_DATA='token=xxx&app-token=yyy&cookie=zzz&deviceId=xxx-xxx'

This is the honest limit of the collection: for several services the required input is a sniffed session token rather than a long-lived key, so a script can stop working when the remote side rotates the token or the device binding, and the fix is a manual capture again. The deviceId placeholder is the clearest example of a value that will not work until a human edits it.

Randomization and auto-update are opt-in switches, not a policy

Two flags stand out in the variable tables, and neither changes the underlying automation. NS_RANDOM, described as a check-in random parameter, is optional with the default shown as true and marked as usually not needing modification. AUTO_UPDATE_TOKEN for Aliyun Drive is also optional and defaults to true, letting the script maintain its own token. Neither flag explains what randomness actually varies, such as timing, offset or payload ordering, and the README gives no second value to compare against. So the randomization claim in the project description should be read as an untested behavioural detail rather than a documented feature you can configure. The same caution applies to the push options: TG_BOT_TOKEN and TG_USER_ID for Telegram are listed as recommended, PUSH_KEY for ServerChan and PUSH_PLUS_TOKEN for Push+ are optional, and DD_BOT_TOKEN with DD_BOT_SECRET covers DingTalk group bots. BARK_PUSH takes an iOS Bark address. Notification delivery is pluggable, and none of it changes what the check-in itself does.

No releases, a single master branch, and a README that has drifted

There are no GitHub releases for this repository, so there is no versioned artifact to pin and no changelog to read before an update lands. The default branch is master, and the repository contains an archive directory alongside the scripts, which suggests older files are moved aside rather than deleted. The last push was on 2026-06-11, and the project is not archived, so updates can still arrive without any release marker to warn you. The README itself already shows drift: its directory tree lists leaflow_checkin.py and smzdm_checkin.py, while the repository top level holds SMZDM_checkin.py, HiFiti_checkin.py, baiduwangpan_checkin.py and passnat_checkin.py, entries the tree does not mention. Treat the tree as an illustration rather than a map, and confirm a file name in the repository before writing your own task commands around it.

Editorial conclusion

Adopt ql-script-hub if you already run a Qinglong panel and only want a handful of low-value daily check-ins that you are willing to re-authenticate by hand. Do not adopt it for services where a missed check-in costs you money, or if you cannot keep session cookies refreshed on a schedule. Before adding any script, confirm the exact environment variable name in the README table for that service, check that the file name in the repository matches the one the README lists, and re-read the service terms, since most of these scripts replay a captured browser session rather than calling a supported API.

Frequently asked questions

Official sources

1. agluo/ql-script-hub on GitHub
2. Issues
3. License: MIT
4. README