v1.8.3: preflight false alarm + disable core telemetry - #10
Merged
Conversation
The core phones home to api.supertokens.io on startup. That endpoint's certificate chains to ISRG Root YR - the same new Let's Encrypt root behind the image-pull failure - and the JVM truststore baked into the core image does not carry it, so every boot logs: javax.net.ssl.SSLHandshakeException: PKIX path building failed It is non-fatal; the core starts and serves normally. But it is alarming noise in the log of the component that signs every session, and a self-hosted game server has no reason to report usage anywhere, so the call is better not made at all. Compose sets DISABLE_TELEMETRY=true by default (overridable), the runbook adds it to the Unraid variable list with the reasoning, and the quick reference gains two entries: this error, and the command that distinguishes a stale CA bundle from a middlebox re-signing TLS - worth ruling out now that two independent trust stores have rejected the same root. Docs and compose only; no code touched. 654 tests green on SQLite, 680 on Postgres. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The API-key probe used a single guessed path, /recipe/users/count, which SuperTokens core 12 does not implement - the path is tenant-scoped (/public/users/count, per supertokens-node's own querier). Every probe returned 404, and the check read "not 401" as "not secured", so a core that was correctly refusing anonymous callers was reported as: The core is running without API_KEYS: anyone who can reach it can mint a login session for any user id, including every value in SUPER_ADMIN_IDS It blamed SUPERTOKENS_API_KEY for the same 404 too, sending the operator to re-check a key that was never the problem. Two fixes, and the second matters more than the first: 1. Probe the tenant-scoped path, falling back to the legacy one, so it works across core versions. 2. A 404 is now "could not determine", never "open". A 404 is evidence about OUR url, not about the core's authentication, and inferring a security verdict from it is how a check ends up crying wolf. A security check that cries wolf is worse than no check, because the next real warning gets ignored too. WARN does not block the cutover; a genuine 200 to an unauthenticated request still does. Tests cover the exact regression: modern path, legacy path, all-404 (WARN and explicitly NOT "open"), a real open core still failing, and 403 treated like 401. The "does not probe /hello" test now asserts the property rather than a literal path, since the literal is what broke. Also ships the telemetry default from the previous commit. 659 tests green on SQLite, 685 on Postgres. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
NeverEndingCode
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The core phones home to
api.supertokens.ioon startup. That endpoint'scertificate chains to
ISRG Root YR— the same new Let's Encrypt rootbehind the image-pull failure — and the JVM truststore baked into the core
image does not carry it. So every boot logs:
It is non-fatal — the core starts and serves normally, and an API key set
alongside it is applied. But it is alarming noise in the log of the component
that signs every session, and a self-hosted game server has no reason to report
usage anywhere, so the call is better not made at all.
Changes
docker-compose.ymlsetsDISABLE_TELEMETRY=trueon the core (overridablevia
SUPERTOKENS_DISABLE_TELEMETRY), with the reasoning inline.error is non-fatal so nobody treats it as a blocker.
a stale CA bundle from a middlebox re-signing TLS — worth ruling out
now that two independent trust stores (Unraid's Docker, the core's JVM) have
rejected the same root.
Docs and compose only; no code touched. 654 SQLite / 680 Postgres green.
🤖 Generated with Claude Code