Add a configurable nickname ban filter, similar to the chat filter except this is defined in the properties file since it doesn't need unicode. Any user that attempts to use a nick that contains anything on this list will be denied.
Fix a bug with /kick and /ban that caused it to only work against users with entirely lower-case nicknames.
Add a check that the user's IP address hasn't changed. This probably isn't as needed now that /kick actually works against everybody.
When users connect (or reload the page), show a permalink to that session's games as well as a permalink to their entire play history, if they haven't opted out of that tracking. When a game starts, or a player/specator joins a game in progress, show a permalink to that game's rounds.
The "when a game starts" bit required removing the tracking of the 'dealing' state, as there was no other easy way to determine that a game was starting. Nothing actually used that dealing state, so it was harmless to remove. Now, a transition from lobby to playing can be detected as a game start, as opposed to a transition from round over to playing.
This takes advantage of the metrics logging, the metrics processor, and the metrics viewer to provide a permalink to a particular round, instead of requiring players to take a screenshot of the round. This will not be enabled immediately as the viewer is not quite ready for deployment, but this is all that needs done on the game server to support this, so it can just be dynamically enabled when it's ready.
First load handler needs to send those things so the client actually has it. Doesn't really need the persistent id there, but it definitely needs the sigil to avoid undefined errors.
Server startup time is included in first load response, and game creation time is included in game info. IRC bridge uses these, and perhaps a way to see them in the web client will be added too.
Trying to figure out why some people can still get in while banned. I cannot reproduce this, and it does not make sense that it is possible as the admin page lists their current IP address in the ban list... and those are all trimmed, so it can't be spaces. Weird.
Unicode characters weren't getting loaded correctly for some reason, either literally or via escape sequences. Change to specifying a class name which has a compile-coded list of shadowbanned strings. This prevents changing on the fly, but at least it works for now until a proper database can be implemented.
Update the privacy policy about chat logging due to shadowbans.
CAPS LOCK FILTER if a line is long enough and contains mostly caps.
Shadowban filter blocks messages with configurable substrings present in them. Does not permanently shadowban the user, yet, just drops the message.
Add a test that was missed in a previous commit.
* A certain amount of characters in the message must be latin-ish, if the message is longer than a certain length.
* There must be a certain number of spaces in the message, if the message is longer than a certain length.
* The same message cannot be repeated twice in the same location.
* Switched the separator between parts for the chat control config value from _ to . for the scope.
The fix for #124 apparently introduced another bug wherein logging out while playing in a game caused an NPE while ensuring that the user was also not spectating the game. Hold onto that value a little bit longer to make sure we can call that method as well, even though it shouldn't need to be called at that point (but an NPE is worse).
Split the configuration value into two. Add a tracking object to ChatFilter per user which currently contains the two different last message times. Removed the last message times from the User object. Show chat error messages only in the tab that caused them, not both tabs.
Refactored out the flood protection, empty message, and message too long errors out to the new class. This will also easily allow adding other chat protections in the future, in one location. Further refactoring should be possible to not have to hold chat-protection related information in the User object, as well.
* GameId needs to be an *int not an int so we can tell the difference between lack of value and value 0.
* Add the description strings to DisconnectReason.
* Add Sigil and IdCode to NewPlayer messages.
* Add if join/quit events are being broadcast to JavascriptConfigServlet. It works much better if they are but it should still work if they aren't.
Add annotations to Constants to specify that a Go struct should be created, and what data type the fields should use (if not string). Rough pass at assigning these annotations correctly. It almost certainly will need further tweaking after trying to use the results in the Go code extensively.
Previously, when users disconnected (either manually or automatically via ping timeout or whatever), they were only being removed from their game if they were a player, not a spectator. This is not consolidated inside the Game class for whatever reason, so add this call to the path that runs when a user is logging out. I've verified other code paths that remove players and all of the ones that need to remove a spectator already do so.
Fixes#124.
Refactor out the formatting code from CardcastService to its own class.
Add [img][/img] support for white cards to have images on cards.
Force line wrapping for cards with words that do no fit onto a card.
Cleaned up some synchronization around ConnectedUsers.users while I was in there. The list itself wasn't synchronized, which could have been a slight problem.
Users can specify an identification code when they connect (8-100 characters), only if they are using HTTPS. This code is combined with their nickname and a server-side secret, hashed with SHA-256, and condensed down to 64 bits by XORing every 8th byte with each other, and finally converted to base64 (with the trailing = removed). This code is displayed in a tooltip when hovering over the user's chat (TODO: mobile way to view it).
Sigils have been added to be displayed before the user's name in the chat. Admins get @, users with an ID code get +, and normal users get nothing. The IS_ADMIN field is now deprecated, as this can be determined from the user's sigil. It will be removed eventually, but is still being included in events even though the official client should not be using it anymore.
Kicks and bans are now always displayed to all users, even if the server isn't transmitting quit events normally.
Andy Janata
Gianlu
Ruben
Tyler Dence