Some gloox headers need workarounds to be included, so mark the header
"lib/external_libraries/gloox.h" as source for all gloox symbols and
collect all headers we use under it.
Further make include-what-you-use happy with files in source/lobby and
fix what needs to be fixed after.
Ref: #8086
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
This makes using STUN mandatory for games hosted using the multiplayer
lobby. The motivation for that is a reduction in complexity, because
right now if STUN is disabled we use a home-grown STUN-like logic, which
got implemented before Pyrogenesis got STUN support.
That home-grown logic relies on a custom ejabberd module (mod_ipstamp),
which inserts the external IP-address of a host in the response messages
when a host registers a game. Originally mod_ipstamp was also used to
inform all potential players of a hosts IP-address, however that has
already been removed to let hosts to only share their IP-address with
players actually joining their game.
Removing the home-grown logic and instead always relying on STUN removes
complexity in Pyrogenesis and the lobby server and also eases hosting
games for players, as they don't have to figure out anymore whether they
need to enable STUN or not.
These changes shouldn't negatively impact the ability of Pyrogenesis to
handle different types of NAT or broken networks. There is one
difference though: While the custom logic using mod_ipstamp utilized TCP
as transport protocol, the STUN implementation in Pyrogenesis currently
uses UDP. That doesn't allow hosts with UDP-connectivity issues to
resolve their external IP-address anymore, however without
UDP-connectivity they aren't able to successfully host games anyway, as
the actual game updates are transferred using UDP as well.
This wrapper was meant to support multiple C++ ABIs with a single
pre-built gloox library wrap as a C library. A new ABI change was
rejected a few years back, so this will probably take a while for it to
be on the table again. With the bug tracker and mailing list currently
unavailable and known TLS issues we might have replaced gloox by then
anyway.
Supporting multiple ABIs with the current setup isn't an issue either
and is already done for 32bit vs 64bit ABI on Windows.
Therefore use gloox types directly in lobby code instead of wrapper
types and delete the wrapper and build-integration.
Migrate to override where applicable, as it helped avoid subtle
differences in signatures and finding missing inheritance of LogHandler.
Finally use version check instead of os check to work around Windows
using the 1.1 development branch instead of releases.
Fixes: #7198
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
Avoid cases of filenames
Update years in terms and other legal(ish) documents
Don't update years in license headers, since change is not meaningful
Will add linter rule in seperate commit
Happy recompiling everyone!
Original Patch By: Nescio
Comment By: Gallaecio
Differential Revision: D2620
This was SVN commit r27786.
The purpose of our client-side hashing for lobby game passwords is to
prevent malicious hosts from getting valuable passwords from clients
(e.g. accidentally typing their lobby password instead of the game, or
even their email password, etc).
However, the hashing was deterministic (and rather simple), making it
possible to compute rainbow tables and recover user passwords anyways.
By adding more variation, including some that cannot so easily be
controlled by the host (the client name), this becomes impractical. The
password hashing function used is rather fast, but given the base low
probability of mistypes, this seems fine.
Differential Revision: https://code.wildfiregames.com/D3459
This was SVN commit r25459.
This allows joining a lobby game hosted on the same network (behind the
same NAT gateway).
This is relatively primitive to keep things simple: if the server and
the client have the same public IP, it is assumed that they are on the
same network and the client instead requests the local IP.
Differential Revision: https://code.wildfiregames.com/D3944
This was SVN commit r25448.
Follow-up to 1a8de6d2b8. This makes it again possible to host without
STUN via the lobby.
The lobby bot will answer the host "Register" command with the external
IP. This is only sent to the host, avoiding IP leakage.
There is a small window in which a client might try to join and the
public IP isn't up, and the request goes through, but that seems rather
unlikely to be a problem in practice.
Refs #5913
Differential Revision: https://code.wildfiregames.com/D3490
This was SVN commit r24858.
Current issue with the lobby, is that we make ips of hosts public for
anyone to read. This patch consists of 3 parts.
1.) Removing ips and ports from lobby javascript
2.) Removing need of script on the server to attach public ips to game
stanza by asking the host using xmppclient as proxy.
3.) Implementing password protected matches, to deny this information to
not trusted players.
Further description:
Do not send ports and stunip to the bots.
Removed from stanza.
Do not send ip to the lobby.
Removed from mapping gamelist from backend to gui (still on the backend
side, because it is done by script on 0ad server).
Get ip and ports on request when trying to connect.
On the host side, ask stun server what is host's public ip and remember
it.
On the client side, send iq through xmppclient to the hosting player and
ask for ip, port and if Stun is used, then if answer is success,
continue
with connecting, else fail.
Add optional password for matches.
Add password required identifier to the stanza.
Allow host to setup password for the match. Hash it on the host side and
store inside Netserver. If no password is given, matches will behave
as it is not required.
On the client side, if password for the match is required, show
additional window before trying to connect and ask for password, then
hash it
and send with iq request for ip, port and stun.
Server will answer with ip, port and stun only if passwords matches,
else will asnwer with error string.
Some security:
Passwords are hashed before sending, so it is not easy to guess what
users typed. (per wraitii)
Hashes are using different salt as lobby hashing and not using usernames
as salt (as that is not doable), so they are different even typing the
same password as for the lobby account.
Client remembers which user was asked for connection data and iq's id of
request. If answer doesn't match these things, it is ignored. (thnx
user1)
Every request for connection data is logged with hostname of the
requester to the mainlog file (no ips).
If user gets iq to send connection data and is not hosting the match,
will respond with error string "not_server".
If server gets iq::result with connection data, request is ignored.
Differential revision: D3184
Reviewed by: @wraitii
Comments by: @Stan, @bb, @Imarok, @vladislavbelov
Tested in lobby
This was SVN commit r24728.
