mirror of
https://github.com/Evil0ctal/Douyin_TikTok_Download_API.git
synced 2026-10-22 00:17:53 +08:00
Evil0ctal
3183665d27
A demo whose password lives only in a README is a demo most visitors give up on. So the login page now fills the form in and they click, and the API keys page shows the demo key in full so they can try the API. Both need the pair to be readable, which is the one place this schema stores a credential it can recover. Two nullable columns, encrypted with the instance key like a cookie jar or a proxy URL, NULL for every other account and every other key. Authentication is untouched — argon2 still verifies the login and sha256 still resolves the key — so these are for display and nothing else. That NULL is the interesting part. An operator's key cannot be revealed on the keys page because there is no plaintext to reveal, not because a check says no, and the note under the table says exactly that. It is a stronger promise than a permission would be. GET /auth/demo is unauthenticated, because the login page is. It can name one account — the one that exists to be published — and only while the switch is on; off, it answers `enabled: false` and an instance that never ran a demo is indistinguishable from one that stopped. Also opened /api-keys to the demo account, which contradicts what I listed earlier as closed. Leaving it shut meant a visitor could never get the key, which defeats the API half of the demo. It is opened and then filtered in the query to that one row, so the operator's names, scopes, rate limits and last-used times are never loaded, let alone drawn. Creating and revoking are still refused. Plus the banner: on the login page, and on every console page while the demo account is signed in. Keyed on the session's role rather than on whether a demo is running, so the operator on their own instance is not told they are looking at a demo. Local stack rebuilt and migrated to 0009.