Complete.Org: Mailing Lists: Archives: freeciv-dev: July 2002:
[Freeciv-Dev] Re: client/server authentication (PR#1767)
Home

[Freeciv-Dev] Re: client/server authentication (PR#1767)

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Mike Kaufman <kaufman@xxxxxxxxxxxxxxxxxxxxxx>
Cc: freeciv-dev@xxxxxxxxxxx, bugs@xxxxxxxxxxxxxxxxxxx
Subject: [Freeciv-Dev] Re: client/server authentication (PR#1767)
From: Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>
Date: Wed, 24 Jul 2002 17:03:41 +0200

On Wed, Jul 17, 2002 at 09:18:37PM -0700, Mike Kaufman wrote:
> here is the preliminary patch that implements authentication.
> this allows, among other things, a trusted(?) method to keep track of
> rankings on public servers.
> 
> to use:
> 
> patch (-p1) & compile. (use autogen.sh) start up server. start up client. 
> (GTK1.2 is the only one that supports it right now) 
> your freeciv root directory should be writable. If you don't want it to
> be, change the database DBFILE define in server/database.c
> 
> login as somebody besides "guest", and you should be prompted to
> imput and confirm a password. play as usual.
> 
> auth-aware clients should handle old servers. and old clients should
> connects as guests to auth-aware servers.
> 
> user response should be the same (you shouldn't have to use any extra
> commands to do anything that you used to do) One thing that you _don't_
> have to do is to input a particular username to play a savegame. (guys,
> that means no more 'civ -t trident -n chris' :) caveat: the defaults are
> a bit tricky if connecting to a savegame with two or more human players.
> 
> The nomenclature of connections has been changed. Entities are:
> 
> A "user":
>       a human being associated with a connection.
> A "connection" (established or not-yet-established):
>       any client that merely connects to the server. i.e. anything 
>       that gets added to the game.all_connections struct. A connection 
>       that has been verified (a guest or authenticated user) is 
>       "established" (and is added to game.est_connections).
> An "associated connection": 
>       a connection that has been associated with a player. This player
>       may not really exist yet (we're in pregame) The "associated"
>       designation signifies that the connection will control a player
>       when the game starts.
> A "player": 
>       something associated with or will be associated with a nation.
> 
> Also a few definitions:
> 
> "joining a server": logging into a server.
> "joining a game": actually taking control of or observing a player while
>       a game is in progress.
> 
> N.B.: this means that you can have connections logged into the server
> but not playing a game that is in progress. A user need not disconnect
> to drop out of a game, he may merely dissociate himself from the player.
> Also a user can already be connected, waiting, and then take over a
> player that disconnects.
> 
> I've created a new server option: game.autoassociate
> When set (which it is by default) any connections (up to game.max_players) 
> not associated with players will be then the game starts.
> 
> I've also created a bevy of new commands:
> observe: observe a player or connections associate with a player
> associate: associate a connection with a player (this may end up being
>   redundant)
> dissociate: dissociate a connection from a player. If that action drops
>   the user from a game-in-progress, ai autotoggle applies N.B.: this does
>   not disconnect the user. 
> take: take over a player that is without a controller or an AI. If
>   multiconnect is allowed, then do so if the player is already controlled.
>   this is cmdlevel info (you can only do this to yourself)
> join: 'take' but cmdlevel cntl. (you can force others to take control of
>   players) should/will be merged into 'take'.
> report: reports players, game status, turn, year. This is for people 
>   connecting to a server and would like to know what's going on.
> allowobserve: unimplemented as of yet. will allow none, all, or certain
>   connections to observe.
> allowmulti: unimplemented as of yet. will allow none, all, or certain
>   connections to connect as multiple controllers.
> 
> BUGS:
> o mult -> obs yields different active unit
> o doesn't go back to freeciv "world" sprite on disassociate 
> from activegame
> o observers send all sorts of packets. server accepts them
> o there's a lot of user input, which means a lot of error handling.
>   I'm sure I've missed some cases. Please try and break it.
> 
> 
> TODO:
> eliminate join (or maybe rename take->join and elim take :)
> allowobserve, allowmulti
> currently passwords are sent over the socket unencrypted. RSA will
> probably be used.
> configure options to disable/enable authentication (probably should
> default to off)
> configure option to set the database file location

Per? Any comments from you?

Reading the code:
 - AUTH_VERIFY_BAD packets should empty packets
 - AUTH_VERIFY_NEW is useless since the client GUI can check for
 correct double input
 - a lot of minor objections:
  - "guest" should not be hardcoded
  - create_database_entry should be user_db_create and so on
  - use fopen instead of open
  - double in comment of notify_player_ex
  - you should update the comments for game.*_connections
  - ...

What is the distinction between username and login?

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  One nuclear bomb can ruin your whole day.


[Prev in Thread] Current Thread [Next in Thread]