Add CSST.at Extension

[TOR968]

CSST.at

plugin that injects a csst.at profile button into Steam community profile pages

Hi @shdwmtr, fair point — the injection setup was a leftover from the period when webkit didn't reach the community browser, and it outlived its purpose. In v1.0.3 the plugin is now plain webkit-only: the CDP path, mode selector and status badge are removed, the backend uses the utils module (get_backend_path, read_file/write_file), there is no raw MILLENNIUM_API access, and the settings panel is a single native ToggleField. The frontend entry is now ~40 lines.

Task Checklist

Developer

• I am the original author or an authorized maintainer of this plugin.
• I have complied with all license requirements for the libraries used, including providing appropriate notices where necessary.
• My plugin is fully open source and does not depend on any external paid services, except for widely trusted and well-known platforms. Additionally, neither I nor anyone associated with me profits from any such services.

Plugin Functionality

• I have tested the plugin on both the Stable and Beta Steam update channels.
• My plugin is unique, or provides additional or alternative functionality to plugins already on the store.

Backend Configuration

• Yes: I use a standard Millennium lua backend in my plugin.
• No: I use custom binaries that or rely on other FOSS projects that aren't written directly using Millennium's lua backend.

Community Contribution

• I have tested and left feedback on two other plugin pull requests.
• I have added links to those feedback comments in this PR.

---

Testing Instructions

• Verified by a third party on Steam Client Stable.
• Verified by a third party on Steam Client Beta.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[MuhammedResulBilkil]

Read the source at the pinned commit aab7491 (v1.0.3), then installed it and ran it on Steam Stable with Millennium. Findings ordered by how much I think each matters.

1. The toggle can end up disagreeing with what's actually stored.

frontend/index.tsx:19-22 sets React state first, then fires saveSettings. In frontend/services/settings.ts:38-45 a failed write restores cachedSettings = previous — but nothing restores the React state, and saveSettings returns Promise<void>, so the caller can't detect the failure either.

I ran that logic verbatim with the backend write forced to return '0':

after failed save -> toggle shows false, cached=true, disk=true
PASS  toggle position diverges from stored value on backend write failure  ui=false stored=true
PASS  reopening the panel silently snaps the toggle back  snaps false -> true

So on a failed write the switch sits where the user put it while the stored value is the old one, and the panel silently reverts next time it mounts. It needs a real write failure to surface, which is why it wouldn't show up in ordinary testing. Returning a boolean, or re-reading getSettings() after the await, closes it.

2. The host check is a substring test on the whole URL.

webkit/index.tsx:4 and webkit/inject.ts:26 both run /steamcommunity\.com\/(id|profiles)\// against location.href. That matches any URL merely containing the string — https://example.com/?u=steamcommunity.com/id/x passes. Testing location.hostname against /(^|\.)steamcommunity\.com$/ is tighter.

3. The SteamID is neither validated nor encoded before it goes into a URL.

getSteamId() (webkit/inject.ts:3-22) returns whatever g_rgProfileData.steamid64 holds, or whatever text sits inside <steamID64> in the fetched XML, with no format check. inject.ts:46 then does 'https://csst.at/profile/' + steamId. On its own that's fine — the source is Steam. It matters in combination with (2): the XML is fetched from location.href, which under that regex need not be a Steam host. A /^\d{17}$/ test plus encodeURIComponent makes both moot. I confirmed the shipped v1.0.3 bundle carries both patterns, not just the repo.

4. Nothing is cleaned up when the plugin is disabled. The anchor, the container div and #csstat-extension-style stay on any page already open. A reload clears it, but someone who toggles the plugin off and looks back at the profile tab they already had open still sees the button.

5. /profiles/{steamid64} does work it doesn't need to. The ID is in the URL, but getSteamId() never looks there — it tries g_rgProfileData, then [data-miniprofile], then a network fetch. Reading the URL first makes the common case free.

6. Trivial. plugin.json's $schema points at .../src/sys/plugin-schema.json, which 404s. The live path is .../src/system/plugin-schema.json. Same in csstats-extension.

---

What I expected to break and didn't. I went in assuming /id/{vanity} resolution would be the weak point, since the SteamID isn't in that URL. It resolves correctly. On both /profiles/{id} and /id/{vanity} the button injects into .profile_rightcol with the right 17-digit ID in its href, #csstat-extension-style is present, and there were no console errors or warnings from the plugin. g_rgProfileData is populated on both page types, so the XML fallback never ran — which also means the network path in (5) is genuinely rare rather than just theoretically rare.

openExternal defaults to true as the source says, and the rendered href was steam://openurl_external/https://csst.at/profile/<id>, so the Cloudflare workaround the panel describes does what it claims. Worth noting the webkit default and the client default agree (webkit/index.tsx:9 and services/settings.ts:8) — a mismatch there would silently route people to the external browser while the panel said otherwise. And the container div is inserted synchronously before the await, so the duplicate-injection guard actually holds; easy to get backwards.

Tested on Steam Stable, plugin confirmed loaded in PLUGIN_LIST with its settings panel registered.

Disclosure: I have a submission open in this queue, also a CS-stats profile button, so weigh this accordingly.

[TOR968]

@MuhammedResulBilkil
Thanks for actually building and running this — the report was precise enough to act on directly.

Fixed in v1.0.4 (4d68fb4). The same patch is applied to the five sibling plugins, which shared all of this code.

(1) Toggle vs. stored value. saveSettings now returns a boolean instead of Promise<void>, and the handler awaits it and re-syncs React state from the store. A failed write snaps the toggle back immediately instead of at the next mount.

(2) Host check. Replaced the substring test on location.href with two separate tests: /(^|\.)steamcommunity\.com$/ against location.hostname, and /^\/(id|profiles)\// against location.pathname.

(3) SteamID. Every resolution path — g_rgProfileData, data-miniprofile, the XML fallback — now goes through a /^\d{17}$/ check, the miniprofile attribute is validated against /^\d+$/ before BigInt(), and the id is URL-encoded when the link is built. Your framing was right: it matters because of (2), since the XML fetch is built from location.href.

(6) $schema. Confirmed 404. src/sys → src/system; it was wrong in all six repos.

Two I decided against, so they don't read as oversights:

(4) Cleanup on disable. There's no hook I can use. The Lua on_unload runs in the backend process and can't reach the community-browser DOM, and the webkit context has no unload hook. Reloading the page clears it — the same thing already required for a settings change.

(5) Reading the id from /profiles/{id}. g_rgProfileData is populated on both page types, so the XML fallback effectively never runs and this would save zero requests — as you observed yourself, that network path is genuinely rare rather than theoretically rare.

Since you checked the shipped bundle rather than just the source: both patterns are gone from the built webkit.js, not only from the repo.

Noted on the disclosure, and appreciated — the findings stood on their own.