* Add loadout names
Did it for AI, breaking change for pgsql + migrations in general. Nothing atm uses it.
* the box
* Spawning cherry pick
* Fix nit
* revert
* Final cleanup
* Real
* Name UI fix
* Migrations
* a
* Review
* Re-run migrations
---------
Co-authored-by: Pieter-Jan Briers <pieterjan.briers+git@gmail.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.
Fixes formatting of owned entity type property names. These are normally named "FooBar_Baz" by EF Core, but the snake case thing was turning them into "foo_bar__baz". The double underscore is now fixed.
We don't *yet* have any EF Core owned entity in use, but I am planning to add one. I don't know if downstreams are using any so this should still be marked as a breaking change.
Also fixed it creating and dropping a Compiled Regex instance for every name, the regex is now cached (and pregenerated).
* Beginnings of making the breadmemes jobs easier
* stuff
* stuff pt. 2
* Stuff pt.3
* Stuff I forgot last time
* Basic whitelist
Only people that are added to the whitelist with the addwhitelist command will be able to join. I call this the "legacy" whitelist
* Remove always deny condition in favor of just breaking if playtime check fails
* Change default whitelist
Default whitelist is now the "legacy" whitelist.
* localization
* Admin check
* minor spelling change
* Fix build
* Whitelist message
* Fix vars not being datafield and spelling mistakes
* Minor spelling mistake
* Change config for salamander
* Reviews and stuff
* Add summaries
* Fix whitelists
* Forgot to add a datafield
* Fixing stuff I guess
* Reuse admin remarks to reduce load when connecting.
* Update log messages to be verbose instead of debug
* Reviews
* whoops
* Explain a bit more how whitelist checking works
* Apply CE's review
* Append Membership to Blacklist and Whitelist conditions
* Fix review comments
* Uncapitalize playerConnectionWhitelist, add to ignored client prototypes
* Make note count field work
* Fix cvar for thingy
---------
Co-authored-by: Pieter-Jan Briers <pieterjan.briers+git@gmail.com>
* 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>
* add debug logs
* Update Model.cs
* fix playtime logic for null playtime
* remove unnecessary condition
* either me or the compiler is having a C# skill issue
To help out admins, so they can easily fill out datacenter bans and stuff. Supports ban exemption flags and everything.
This is for use with SS14.Admin so it's just DB models here.
* 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
* initial commit
* IOC
* no lists in toml
* maybe
* hm
* dependent
* undo
* no tolerance
* maybe no instantiate
* double
* maybe strings
* patch
* proper string handling
* go back
* redo
* lets try this way eh
* auth cmon
* test logging
* whoops
* our own record
* put it inside the if
* eh
* the worlds a stage
* or not
* hu
* cleanup
* rearrange the try catch to include the initial connection call as well
* shorten it up try to simplify
* no jack
* locale
This was removed in #25280 as the relevant DB entities didn't go outside the DB layer anymore. SS14.Admin however still uses them directly (as it only supports Postgres), so the interface is still useful there.
How can ONE DATABASE COLUMN have so many cursed issues I don't know, but it certainly pissed off the devil in its previous life.
The start_date column on round entities in the database was added by https://github.com/space-wizards/space-station-14/pull/21153. For some reason, this PR gave the column a nonsensical default value instead of making it nullable. This default value causes the code from #25280 to break. It actually trips an assert though that's not what the original issue report ran into.
This didn't get noticed on wizden servers because we at some point backfilled the start_date column based on the stored admin logs.
So I change the database model to make this column nullable, updated the C# code to match, and made the existing migration set the invalid values to be NULL instead. Cool.
Wait how's SQLite handle in this scenario anyways? Well actually turns out the column was *completely broken* in the first place!
The code for inserting into the round table was copy pasted between SQLite and PostgreSQL, with the only difference being that the SQLite key manually assigned the primary key instead of letting SQLite AUTOINCREMENT it. And then the code to give a start_date value was only added to the PostgreSQL version (which is actually in the base class already). So for SQLite that column's been filled up with the same invalid default the whole time.
Why was the code manually assigning a PK? I checked the SQLite docs for AUTOINCREMENT[1], and the behavior seems appropriate.
I removed the SQLite-specific code path and it just seems to work regardless. The migration just sets the old values to NULL too.
BUT WAIT, THERE'S MORE!
Turns out just doing the migration on SQLite is a pain in the ass! EF Core has to create a new table to apply the nullability change, because SQLite doesn't support proper ALTER COLUMN. This causes the generated SQL commands to be weird and the UPDATE for the migration goes BEFORE the nullability change... I ended up having to make TWO migrations for SQLite. Yay.
Fixes#26800
[1]: https://www.sqlite.org/autoinc.html
Ilya246