This requires three more tables to be added to any database with the forum user handler enabled, the structures of which are defined in the wesnothd man page:
* `db_game_info_table` - stores information about each game.
* `db_game_player_info_table` - stores information about each player in the game.
* `db_game_modification_info_table` - stores information about any modifications that are enabled for the game.
This should make it less confusing for players who might assume that
their ban is permanent otherwise. If the ban is permanent the duration
is not sent to clients, however. Since permanent bans can be revoked on
appeal, it seems like a good idea to me to avoid using any wording that
would allude to their otherwise infinite duration.
Closes#3766.
This enables reporting back to the client the specific type of ban that
affects the account. This information is already normally provided by
phpBB when trying to view a page while banned, so we are not leaking any
new information here.
There isn't an API to retrieve the (user-visible) ban reason from the
ban list yet. It's probably not worth worrying about it since affected
users can see it when navigating to forums.wesnoth.org anyway.
(cherry-picked from commit 749e684f03)
This adds a user_is_banned() method to the user_handler classes that
returns whether a given username (and optionally IP address) is banned
by the user_handler platform. Obviously right now this is only intended
to work with forum_user_handler and phpBB.
Forum bans are checked against entries in the banlist table using
username (actually user id), IP address, and email address where
applicable. A user matching a ban on any of those three items will not
be permitted into the server *unless* they have the moderator flag set.
It might be worth making an exception for board founders as well,
although that is probably orthogonal to this patchset.
Right now there are a few missing items:
* The server sends clients an error that allows them to try again with
a different username/password combination immediately. Nothing stops
them from causing noise in the server logs this way, so we probably
need to ensure this counts as an authentication failure for the
purpose of temporarily and automatically banning the IP address.
* The user handler doesn't allow retrieving details about the ban, so
all that the main server code can do is report back to the client as
their nickname being banned, when this is not necessarily the case
(email or IP address bans). I need to figure out a better API for
retrieving this info.
* Likewise, the server does not log the specifics about the matched ban
yet unless the mp_user_handler log domain is set to the info log
level.
* There's no i18n support on the client side for the error message sent
by the server -- which is going to change anyway.
* Testing this patch uncovered an issue with the MP client not
displaying messages sent during the login sequence, including the mod
authentication notice.
(cherry-picked from commit f2c06f0a4e)
The word salt was used to mean both the password salt and the password challenge nonce.
The word pepper was used to represent the password challenge.
Also renamed the MD5 nonce generator to make it clear it's not secure.
Turns out I mistook @celticminstrel's opinion that we should use include guards over pragma (737916e).
Since all major compilers support `#pragma once`, there's no reason not to use it.
For future mergability reasons, this excludes src/spirit_po and src/xBRZ. It also excludes src/boost-patched.
...for checking whether a user account is active and can claim
ownership or a nickname or not
Right now this code is unused in the auth logic. Both suh and fuh
implementations are provided, only the latter works (using phpBB 3.0's
rules).
