Ban database refactor (#42495)
* Ban DB refactor seems to work at a basic level for PostgreSQL
* New ban creation API
Supports all the new functionality (multiple players/addresses/hwids/roles/rounds per ban).
* Make the migration irreversible
* Re-implement ban notifications
The server ID check is no longer done as admins may want to place bans spanning multiple rounds irrelevant of the source server.
* Fix some split query warnings
* Implement migration on SQLite
* More comments
* Remove required from ban reason
SS14.Admin changes would like this
* More missing AsSplitQuery() calls
* Fix missing ban type filter
* Fix old CreateServerBan API with permanent time
* Fix department and role ban commands with permanent time
* Re-add banhits navigation property
Dropped this on accident, SS14.Admin needs it.
* More ban API fixes.
* Don't fetch ban exemption info for role bans
Not relevant, reduces query performance
* Regenerate migrations
* Fix adminnotes command for players that never connected
Would blow up handling null player records. Not a new bug introduced by the refactor, but I ran into it.
* Great shame... I accidentally committed submodule update...
* Update GDPR scripts
* Fix sandbox violation
* Fix bans with duplicate info causing DB exceptions
Most notably happened with role bans, as multiple departments may include the same role.
* initial visual nubody
* oops overlay
* im so pheeming rn
* conversion...
* tests
* comeback of the underwear
* oops eyes
* blabbl
* zeds
* yaml linted
* search and visible count constraints
* reordering
* preserve previously selected markings colors
* fix test
* some ui niceties
* ordering
* make DB changes backwards-compatible/downgrade-friendly
* fix things again
* fix migration
* vulpkanin markings limit increase
* wrapping
* code cleanup and more code cleanup and more code cleanup and more code cleanup and
* fix slop ports
* better sampling API
* make filter work + use the method i made for its intended purpose
* fix test fails real quick
* magic mirror cleanup, remove TODO
* don't 0-init the organ profile data
* remove deltastates
---------
Co-authored-by: Princess Cheeseballs <66055347+Pronana@users.noreply.github.com>
This should be the primary changes for the future-proof "Modern HWID" system implemented into Robust and the auth server.
HWIDs in the database have been given an additional column representing their version, legacy or modern. This is implemented via an EF Core owned entity. By manually setting the column name of the main value column, we can keep DB compatibility and the migration is just adding some type columns.
This new HWID type has to be plumbed through everywhere, resulting in some breaking changes for the DB layer and such.
New bans and player records are placed with the new modern HWID. Old bans are still checked against legacy HWIDs.
Modern HWIDs are presented with a "V2-" prefix to admins, to allow distinguishing them. This is also integrated into the parsing logic for placing new bans.
There's also some code cleanup to reduce copy pasting around the place from my changes.
Requires latest engine to support ImmutableArray<byte> in NetSerializer.
* Start work on PostgresNotificationManager
Implement initial version of init and listening code
* Finish implementing PostgresNotificationManager
Implement ban insert trigger
* Implement ignoring notifications if the ban was from the same server
* Address reviews
* Fixes and refactorings
Fix typo in migration SQL
Pull new code in BanManager out into its own partial file.
Unify logic to kick somebody with that when a new ban is placed directly on the server.
New bans are now checked against all parameters (IP, HWID) instead of just user ID.
Extracted SQLite ban matching code into a new class so that it can mostly be re-used by the ban notification code. No copy-paste here.
Database notifications are now not implicitly sent to the main thread, this means basic checks will happen in the thread pool beforehand.
Bans without user ID are now sent to servers. Bans are rate limited to avoid undue work from mass ban imports, beyond the rate limit they are dropped.
Improved error handling and logging for the whole system.
Matching bans against connected players requires knowing their ban exemption flags. These are now cached when the player connects.
ServerBanDef now has exemption flags, again to allow matching full ban details for ban notifications.
Made database notifications a proper struct type to reduce copy pasting a tuple.
Remove copy pasted connection string building code by just... passing the string into the constructor.
Add lock around _notificationHandlers just in case.
Fixed postgres connection wait not being called in a loop and therefore spamming LISTEN commands for every received notification.
Added more error handling and logging to notification listener.
Removed some copy pasting from SQLite database layer too while I was at it because god forbid we expect anybody else to do all the work in this project.
Sorry Julian
---------
Co-authored-by: Pieter-Jan Briers <pieterjan.briers+git@gmail.com>
* Implement a new kind of ip range ban that only applies to new players
* Put determining whether a player record exists to its own function
* Make BlacklistedRange bans get bypassed by any ban exemption
* Stop trying to get another DbGuard while already having one
This does break with convention on the functions in that area but
considering the use of this function it's probably fine?
I could alternatively just move the place it's called from.
Also I was suppossed to wait for tests to finish locally just to be
sure, but nah. I am pushing this now
First bug: if an error occured during pref loading code, it would fail. If the person then readied up, it would likely cause the round to fail to start.
Why could they ready up? The code only checks that the prefs finished loading, not that they finished loading *successfully*. Whoops.
Anyways, now people get kicked if their prefs fail to load. And I improved the error handling.
Second bug: if a user disconnected while their prefs were loading, it would cause an exception. This exception would go unobserved on lobby servers or raise through gameticker on non-lobby servers.
This happened even on a live server once and then triggered the first bug, but idk how.
Fixed this by properly plumbing through cancellation into the preferences loading code. The stuff is now cancelled properly.
Third bug: if somebody has a loadout item with a playtime requirement active, load-time sanitization of player prefs could run into a race condition because the sanitization can happen *before* play time was loaded.
Fixed by moving pref sanitizations to a later stage in the load process.
God bloody christ. There's like three layers of shit here.
So firstly, apparently we were still using Npgsql.EnableLegacyTimestampBehavior. This means that time values (which are stored UTC in the database) were converted to local time when read out. This meant they were passed around as kind Local to clients (instead of UTC in the case of SQLite). That's easy enough to fix just turn off the flag and fix the couple spots we're passing a local DateTime ez.
Oh but it turns out there's a DIFFERENT problem with SQLite: See SQLite we definitely store the DateTimes as UTC, but when Microsoft.Data.Sqlite reads them it reads them as Kind Unspecified instead of Utc.
Why are these so bad? Because the admin notes system passes DateTime instances from EF Core straight to the rest of the game code. And that means it's a PAIN IN THE ASS to run the necessary conversions to fix the DateTime instances. GOD DAMNIT now I have to make a whole new set of "Record" entities so we avoid leaking the EF Core model entities. WAAAAAAA.
Fixes#19897
* Give .props files 2-space indents.
* Move to Central Package Management.
Allows us to store NuGet package versions all in one place. Yay!
* Update NuGet packages and fix code for changes.
Notable:
Changes to ILVerify.
Npgsql doesn't need hacks for inet anymore, now we need hacks to make the old code work with this new reality.
NUnit's analyzers are already complaining and I didn't even update it to 4.x yet.
TerraFX changed to GetLastSystemError so error handling had to be changed.
Buncha APIs have more NRT annotations.
* Remove dotnet-eng NuGet package source.
I genuinely don't know what this was for, and Central Package Management starts throwing warnings about it, so YEET.
* Remove Robust.Physics project.
Never used.
* Remove erroneous NVorbis reference.
Should be VorbisPizza and otherwise wasn't used.
* Sandbox fixes
* Remove unused unit test package references.
Castle.Core and NUnit.ConsoleRunner.
* Update NUnit to 4.0.1
This requires replacing all the old assertion methods because they removed them 🥲
* Oh so that's what dotnet-eng was used for. Yeah ok that makes sense.
* Add Robust.Analyzers.Test
* Update submodule
* commit to re-run CI
Thanks to julian figuring out IDesignTimeDbContextFactory exists in #6327.
All this DbContext configuration and options setup stuff is insane. Microsoft should be absolutely ashamed for coming up with this load of garbage.
* Holy crap auth works
* Fix some usages of UserID instead of UserName
* Refactor preferences.
They be non-async now. Also faster.
* Rename DbContext.
* Guest username assignment.
* Fix saving of profiles.
* Don't store data for guests.
* Fix generating invalid random colors.
* Don't allow dumb garbage for char preferences.
* Bans.
* Lol forgot to fill out the command description.
* Connection log.
* Rename all the tables and columns to be snake_case.
* Re-do migrations.
* Fixing tests and warnings.
* Update submodule
