This PR enables auth cookies to be used simultaneously with plaintext paasswords sent in the cookie authID field.
* Hoist a bunch of checks from the login packet handler into helper functions.
* Rename the LoginType enum to AuthMethod and distinguish it from the iLoginType packet field (see comment in code for why these should be decoupled).
* If the provided token does not pass the cookie check and password auth is enabled, treat it as a plaintext password and authenticate if it is correct.
This is to prevent accidental exposure of the monitor port to the public
internet if a server admin enables the monitor port without it being
properly firewalled. There is now a config option that lets you override
the address to bind to, so that it can still be made available to other
machines over private networks such as Wireguard.
* Support disabling Landlock at compile time or runtime if unsupported,
without disabling seccomp
* Support older Landlock ABI versions
* Support an extra arbitrary RW path, inteded for the coredump dir
* Support database locations other than the working directory
* Auth cookie support
* Add config option for auth cookie support
* Safe handling of TEGid/auth_id strings
* Fix bad size calculation due to pointer cast
* Expiration timestamp instead of valid bit
* Change setting to "allowed auth methods"
This allows plaintext password auth to be disabled altogether
* PR feedback
* Client synchronization improvements
* Remove bad comment
* Remove guard on PC_TICK
* Fix delayed loading of nano skill icons
We actually don't need to wait for post-load to do the second nano book send.
That adds unnecessary delay. Moving it to right after `P_FE2CL_REP_PC_ENTER_SUCC`
does the trick and gives the client plenty of time to fetch the icons before
loading in-game.
* Don't send unnecessary nano book subsets pre-enter
* Fix comment
Note that the warning in TableData.cpp only seems to occur on clang (deprecated-declarations)
Database account/player count message:
Before: [INFO] Database in operation : Found 1 account(s) and 2 player(s)s
After: [INFO] Database in operation: Found 1 account and 2 players
This macro makes it use the stdcall calling convention when compiling
for 32-bit Windows. Its absence was technically a bug, but it's a no-op
on 64-bit Windows.
For a while we had made the temporary rapid-fire anti-cheat optional on
master, but had removed it entirely on the refactor branch. The
modification on master was acidentally only applied to the regular
(non-projectile) combat handler, while the removal on refactor removed
both that and the projectile check.
When the refactor branch was merged, that resulted in the removal of
only the projectile rapid-fire check, while the conditional regular
combat rapid-fire check was kept.
This change restores the projectile rapid-fire check such that it is
conditional, just like for regular combat.
This was initially a merge commit that got ironed out by rebase cleanup.
Notable changes are:
- Copying EntityRef instead of referencing it
- Some changes to includes
Get rid of `iConditionBitFlag` in favor of a system of individual buff
objects that get composited to a bitflag on-the-fly.
Buff objects can have callbacks for application, expiration, and tick,
making them pretty flexible. Scripting languages can eventually use
these for custom behavior, too.
TODO:
- Get rid of bitflag in BaseNPC
- Apply buffs from passive nano powers
- Apply buffs from active nano powers
- Move eggs to new system
- ???
Was getting frustrated by the inconsistency in our include statements,
which were causing me problems. As a result, I went through and manually
re-organized every include statement in non-core files.
I'm just gonna copy my rant from Discord:
FOR HEADER FILES (.hpp):
- everything you use IN THE HEADER must be EXPLICITLY INCLUDED with the exception of things that fall under Core.hpp
- you may NOT include ANYTHING ELSE
FOR SOURCE FILES (.cpp):
- you can #include whatever you want as long as the partner header is included first
- anything that gets included by another include is fair game
- redundant includes are ok because they'll be harmless AS LONG AS our header files stay lean.
the point of this is NOT to optimize the number of includes used all around or make things more efficient necessarily. it's to improve readability & coherence and make it easier to avoid cyclical issues
