This is the first commit in a pattern that I'd like to follow. The
concept is that we specifically create handlers for things that are
"illegal per se." That is, there are no possible situations (in the
current protocol) where a packet of this type is received from a client.
In this case, I moved the emoji handler out of the Handler just for
emoji, since it seemed like an obvious case.
The rule of thumb is simple: if something is illegal per se, there
should be no possible way in the vanilla client to achieve this result.
If a player sends this combination of packets they *must* be hacking.
Not that there is a 99.9% chance they're hacking, but that there is a
100% unambiguous chance that they're hacking.
Something is illegal per se if it can only be created by a hacked
client. If there's a crashing bug that a normal player can do with a
complex series of vanilla events, that is not illegal per se.
The goal of this namespace and class of handlers is to handle exactly
one type of protocol violation, and remove the packet accordingly. If it
is ever reported that the packet can be sent from a vanilla client, the
check must be removed as it is no longer a per se violation of the
protocol.
This fixes false positive cheat detection when throwing rotten eggs at town NPCs while wearing Frost armor set. Also made the debug and kick messages more clear for future reference.
This commit adds a fallback to address problems with FindByNameOrID
potentially returning ambiguous results. Now, in response to a multiple
match error, a player can specify tsi:[number] or tsn:[exact name] to
match a user ID or name exactly. This behaves analogous to the old
behavior of the search method.
Currently, the TSPlayer FindbyNameOrID method aborts if it finds an
"exact match" based on this criteria:
1. If the player ID is on the server, it must be the thing we're looking
for. Therefore, return that.
2. If the case sensitive "exact match" is on the server that isn't an
ID, that must be what we're looking for. Therefore, return that.
3. Just yolo and downcase everything and return any number of matching
players next.
This commit changes the behavior because some players have been joining
servers with ambiguous names, like `1`. In the current system, this
player is difficult to query because they're an "ID" and therefore an
exact match will be returned even if a player name exists that matches
the criteria.
This also alleviates the issue of a case exact match falling down the
same trap. It's ambiguous enough in all of these situations that an
admin should just be using a player ID instead.`
Okay, now we're at problem 74 with github actions. Basically, github
actions doesn't send secrets to forks because duh, that makes sense. So
even if you make a super restricted token you still can't send it to
forks because github still doesn't understand how to make a security
platform when they just copy paste azure pipelines into github and then
say "well looks good to me" and ship fucking arbitrary code execution to
the entire fucking world and then try to retroactively fix all of their
mistakes and fail miserably in the process
Look, let's just be real here: GitHub needs to redo the entire
permission model for GitHub. There is no way to create a secure
combination of the following elements: post comment, edit comment, and
post status check.
If you want to be able to post comments, you have to authorize a token
or app to have full authority to do literally anything that the user can
do on a public repo. Full stop.
If you want to post a status check, you have to give the user write
access to the entire repo, which makes the first issue a problem.
You can't just explicitly make a token that says "only allow this user
to post and edit its own comments" and "allow this user to post status
checks" because write access on the repo implies authority over all
other issues/PRs opened by other people.
Now Cardinal's token is restricted to just status checks, and we're
using a different action.
Thanks a ton for the huge mess Github.
This change uses Cardinal's PAT for GitHub Actions CI. The way this
works is very convoluted, but it makes sense in theory.
1. Cardinal is a member of the Pryaxis org, in a group called "untrusted
robots." She has write access to Pryaxis/TShock, so she can create
status messages. This is because GitHub only allows status messages to
be created if a user has write access.
2. Cardinal has a PAT, and that PAT only has access to creating
repository status messages.
3. Danger requires permission to post comments and update CI status.
4. Cardinal's PAT is only authorized to create repo status messages, and
cannot privilege escalate.
5. GitHub implicitly gives everyone the ability to post comments on
public repositories.
Thus, this really interesting and weird flow should mean that Cardinal
can post comments and update status messages, by having write access but
functionally being unable to use it.
At least, that's the theory.
UsingBiomeTorches: Whether or not the player has the torchgod biometorches ability enabled
HappyFunTorchTime: Whether or not the player has fought the torchgod before (for logic that checks for torchgod spawning)
unlockedBiomeTorches: Whether or not the player has the torchgod biome torches ability unlocked
This fixes a ridiculous typo in GetDataHandlers where we were setting
the UsingBiomeTorches flag based on having unlocked biome torches,
rather than actually being used. Thanks to @Arthri for the tip!
If a player has the tshock.ignore.ssc permission, odds are that they may
want to know that their data isn't being saved or not. This change
allows users to be notified if they have SSC data stored in the DB but
they aren't having it loaded due to the aforementioned permission.
This permission causes great confusion, but we can't really change it
because we would break existing setups. This is an easy change that
gives people a reason why they suddenly "have no items."
This new option can be turned off in the config file for SSC if it's not
desired.
This change also modifies some of the log messages so that it's clear
why the SSC save didn't occur for a given player.
This commit adds Danger via GitHub Actions. Dangerfiles are ruby files
that have a DSL for interacting with GitHub. They can do arbitrary
things. See: https://danger.systems/reference.html
The point of this commit is to automate the process of asking people to
update the changelog. This is a really really annoying thing that we
have to do too often. Editing a pull request will automatically re-run
the check.
Truly trivial commits can be marked as trivial easily by using the
hashtag trivial in the PR body. This is really just useful for actually
trivial things. Most commits actually do need to have associated
changelog entries.
