Authenticate players

[46bit]

As of https://github.com/sirpent-team/sirpent-rust/commit/684f32fa923cf2399822453edc912a903c604562, Player.secret is now Command::Hello.secret:

pub enum Command {
    […]
    // The client should decide whether it is compatible with this protocol and server setup.
    // If the client wishes to continue it must send a HELLO message.
    #[serde(rename = "HELLO")]
    Hello {
        player: Player,
        #[serde(skip_serializing_if = "Option::is_none")]
        secret: Option<String>,
    },
    […]
}

Players can provide a secret string, that (once set) must be provided with each connection of a player of that name.

• With no secret set, any player with that name is considered valid.
• With a secret set, any player with that name which omits or has an incorrect secret will be rejected.

This approach has major caveats.

• If a player isn't using a secret, someone could connect with that player name and specify a secret. Subsequently the genuine player could not use that player name - which for an AI program means it not even playing until the human notices the issue.
• A disclosed secret can never be changed. With people sharing AI code it seems inevitable someone will disclose one.

As such I feel like this nice-and-simple authentication model may have more downsides than previously recognised by myself.

[Taneb]

The way I was imagining it is we don't decide which player is which by name, but by name/secret pair.

So we could have SimpleAI/hunter2 and SimpleAI/password, for example.

Thoughts?

[qlkzy]

Suggestions:

"The genuine player could not use that player name": given shared code, wanting to play multiple copies of an AI against each other, etc., I'd imagine that name collisions need to be handled more broadly. I'd suggest a mechanism whereby the server can override names. So, if SimpleAI is already connected, another player trying to connect as SimpleAI gets SimpleAI (1) or something. Or maybe embed the thesaurus entry for "impostor", and use that before falling back to numbers. In the case of names which can be authenticated, you'd automatically be overridden unless you provided a secret.

"A disclosed secret can never be changed": Exactly how many of these are you expecting to run? There will probably be a fairly small set of players, of which even fewer will encounter this issue. Why not just fix it manually if it happens?

[46bit]

@qlkzy's suggestions have a lot of merit. Here's my plan: do something like what he suggests, and if anyone wants to set a secret value they can get one set out-of-band.

[46bit]

Player names are right-padded with _ until unique.

• [x] Either remove secret for now or do a very basic manually-set implementation.