previously the server would send [speak] commands that had no undo=no attributes so that the game would remove the speak command from the replay instead of the actual undoable action when undoing an action.
(cherry-picked from commit 02bed5c0335893542f5f3732ea013ab1ca705c55)
previously both were broken:
1) 'require_scenario' was only checked if the scenario was installed
which obviously doesn't make any sense at all.
2) 'require_scenario' was read from the local scenario data instead from
the remote scenario.
3) 'require_era' was only checked when the scenario was not installed,
so people who do have an outated version of the era installed could not
join bacause it assumed require_era=yes in that case.
4) the server tried to read 'require_scenario' from the wrong wml node,
'require_scenario' is an attribute of [scenario] and not of savefile
toplevel.
(cherry-picked from commit eec8b674de6d04f13f5b875c1b1e6b953e45ef9e)
previously it would happen that for example an attribute like
`side_name=_"female^Footpads"` in side would get its translatable mark (_)
removed after the game has started. This meant that observers that enterd
the game after it started would see the literal string "female^Footpads"
in the status side overview window.
The new code marks all translatable simple_wml attributes to make sure their
translatable mark is preserved along with their textdomain. It can still
happen though that attributes will appear in the the wrong textdomain area
after simple_wml processing though because in some cases note::output
might skip over textdomain markers. It is still not as bad as string like
"female^Footpads" appearing in the ui though.
An alterntive appraoch to fix this issue would be to carefully make sure
not to change any atributes of wml tags that can also contain translatable
attributes, which would probably imply not editing the wml objects received
by the client at all and instead storing the new information (in particular
side information like is_local=yes/no) in a seperate wml object. (that would
then be sended to the clients along with the original scenario wml objects.)
fixes#1420
(cherry-picked from commit eb23ac56461c8d57dc5d1aee018832c2dc7dcf36)
instead we use a custom struct. std::pair is bad becasue you never know
what "first" or "second" mean.
(cherry-picked from commit c4aacbe31f31799861e03f4b7f7b241bee64aa65)
Regression from commit 36e9290.
As @gfgtdf pointed out in the bug report, because old_player was a
reference to the shared_ptr, resetting the shared_ptr in sides_ also
changed old_player, and thus 'the player lost his last side' check never
passed.
Thanks to @gfgtdf for figuring out the cause.
(cherry-picked from commit 95f19745ca87a5e7e3beecf69cbc84b1840ed076)
For lobby messages, there was a length cap in place already, but the
truncated message was lost in processing because it ended up in a WML
document that isn't the one relayed to listening clients.
On the other hand, whisper messages were missing the truncate logic
entirely. Oops.
(The logic for in-game messages does truncate messages correctly as far
as I can tell, and additionally the client UI doesn't allow overlong
messages.)
Thanks to Soliton for pointing me towards the faulty code.
(cherry-picked from commit cdc8da25aea2cbc055dc12879d2c4333fecfc3e1)
If dc happens during asio read that would call server::add_player
then a "ghost" player will appear in games_and_users_list_. Fix works by
moving the list update into the handler, it will be called only if read is
successful.
This should prevent issue #2989 unless it has some other mechanism
(cherry-picked from commit 787a1a0dae41e68d237cacd9ceca381d6dad76df)
A few catch blocks modify something in their exceptions, so those are kept non-const.
(cherry-picked from commit 2bf4d68c87b69256266b7745a9e3453693794e35)
There isn't much point in doing more expensive ban look ups first.
(Also, yes, I am aware that as it is there's still two SELECT queries
that could be coalesced into a single one -- namely, the ones for the
user_email and user_id columns.)
(cherry-picked from commit d48c84236c17adca9421fe15d0d0666f1c2b96cb)
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 749e684f03982fe268ab15074f28d701d0e55f18)
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 f2c06f0a4e0d82a8e2a78d4ad25c91c09a6c2b63)
as is done in rest of wesnothd. This also fixes crash from self-kick
due to it trying to continue processing looking for further tags
after /query kick kicked the user in quesion.
(cherry-picked from commit 6a310f0c79d002cbe53d9ee4f12b95a3b31c721b)
