Skip to content

fix(plugin): use native auth IDs for engine bans - #1572

Merged
rumblefrog merged 1 commit into
mainfrom
fix/1507-synergy-native-ban-id
Sep 18, 2026
Merged

rumblefrog merged 1 commit into
mainfrom
fix/1507-synergy-native-ban-id

Conversation

@rumblefrog

@rumblefrog rumblefrog commented Sep 18, 2026 •

Copy link
Copy Markdown
Member

Summary

  • enforce reconnect bans through SourceMod’s game-native auth path so Synergy receives Steam3 IDs
  • persist engine-native IDs in the SQLite fallback queue and migrate existing queues safely
  • keep Steam2 IDs canonical in the panel database while converting legacy Synergy queue rows when needed

Testing

  • compiled all top-level SourceMod plugins with SourcePawn 1.12.0.7253

Closes #1507

@rumblefrog
rumblefrog requested a review from a team September 18, 2026 21:35
@rumblefrog
rumblefrog force-pushed the fix/1507-synergy-native-ban-id branch from 260106f to dc680e6 Compare September 18, 2026 21:37
@rumblefrog
rumblefrog merged commit dde6267 into main Sep 18, 2026
3 checks passed
@rumblefrog
rumblefrog deleted the fix/1507-synergy-native-ban-id branch September 18, 2026 21:40
Rushaway added a commit to srcdslab/sourcebans-pp that referenced this pull request Sep 22, 2026
…bpp#1571/sbpp#1572

Two bugs surfaced while comparing this fork's Synergy/queue-related
plugin fixes against upstream sbpp#1572 ("use native
auth ids for engine bans") — upstream's diff touches the same
functions and happens to carry the fix for the first one as a side
effect.

1. ProcessQueueCallback re-INSERTs a matured queue row into the main
   `%!s_bans` table, but was building and executing that query against
   `db` — the local SQLite queue connection this callback fires on
   (bound via SQLiteDB.Query(ProcessQueueCallback, ...) in
   ProcessQueue()) — instead of `DB`, the main panel database the
   `%!s_bans` table actually lives on. SQLite has no such table, so the
   INSERT would fail every time; AddedFromSQLiteCallback's
   `results == null` branch just re-arms the temporary in-game hold and
   leaves the row in the queue, so the ban would keep getting
   re-enforced locally but NEVER actually land in the permanent
   database once it came back up after an outage — silently defeating
   the entire point of the offline queue. Switched both the
   `.Format()` call (MySQL vs SQLite escaping rules differ) and the
   final `.Query()` to `DB`. Paired with a `DB == INVALID_HANDLE`
   guard at the top of the callback (matching upstream) so this
   doesn't trade "silently fails forever" for "throws a native error"
   on a cycle where the main DB is still down.

2. AddedFromSQLiteCallback's success path calls
   `RemoveBan(auth, BANFLAG_AUTHID)` with the raw Steam2 identity to
   clear the temporary in-game hold once the real ban lands in the
   main database. But the temp hold was created by SBPP_BanIdentity(),
   which converts to SteamID3 whenever it can (some engines, e.g.
   Synergy, reject the STEAM_ format for the "banid" console command,
   so SBPP_BanIdentity works around it) — a Steam2-only RemoveBan()
   call silently misses a SteamID3-keyed entry, leaving a stale
   temporary ban sitting in SourceMod's cache until it expires on its
   own. Try the SteamID3 form too; removing an identity with no
   matching ban is a harmless no-op.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
rumblefrog added a commit that referenced this pull request Sep 28, 2026
…1580)

VerifyBan runs from OnClientAuthorized, which can land before
OnClientPutInServer. BanClient() resolves the client through
ReferenceToIndex(), which returns -1 while the edict has no entity, so
SourceMod threw "Client index -1 is invalid" and the banned player was
never kicked. #1572 introduced the BanClient call; the previous
banid + KickClient path did not depend on the entity.

Mirror BanClient's BANFLAG_AUTO with entity-independent natives: ban
the engine auth string via BanIdentity (keeps Synergy's native Steam3
form) and KickClient; when the auth lookup fails or the server is LAN,
KickClientEx then ban the IP, matching BanClient's kick-then-addip
order.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Ban in Synergy by Steamid2 is not supported

1 participant