Open 1Bayshore opened 4 years ago
Password handling here requires high security. Perhaps we hash what the user types in before sending it from the client, and then use the hash as the actual password to the server.
The thing about this is that we still have the actual password being sent across the internet, it's just not seen by the user. I don't understand what this changes, because you would have to ensure a totally secure connection either way. All that hashing does in this case is turn the password into a number.
Currently, all game code, with the exception of a few key git communication pieces, are run under the
gameserver
user. While this is handy for server-side communication, it is not ideal for a number of reasons:git pull
command is run, it causes the Unix permissions on some of the files to change, making thegameserver
user unable to write them.player.py
. This seems a bit clumsy, as it creates unnecessary player for the sole purpose of accessing the state machine. It also allows players to get stuck in the login process if they try to quit during login. We could make several improvements to this code by locating it with the websocket connections.Proposal: Run the
Console
and the websocket server as separate processes in separate usersThe implementation of this would look something like this:
gameadmins
) can run code as this userIn addition to the already mentioned, there are a number of cool features that would be enabled by using more Unix users:
Difficulties:
git pull
. Line endings (see #171) could become a problem as well.ConsoleAccessPoint
class that redirects some of these function calls to various player/console functions.