Complete.Org: Mailing Lists: Archives: freeciv-dev: February 2000:
[Freeciv-Dev] Re: New authentification code
Home

[Freeciv-Dev] Re: New authentification code

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: New authentification code
From: Reinier Post <rp@xxxxxxxxxx>
Date: Sun, 27 Feb 2000 20:11:03 +0100

Authentication!

On Sat, Feb 26, 2000 at 10:06:56PM -0500, Daniel Burrows wrote:

>   When the client first connects, it sends a join_game packet as usual and
> receives a join_game reply.  However, the reply (if the client has the
> +AUTHENTICATION capability) has a meaningless value of you_can_join; instead,
> a list of (string names of) available authentication methods is included at 
> the
> end of the message.  (I could create a new packet type which leaves out the
> you_can_join, and maybe message, fields, just for +AUTHENTICATION clients;
> is this worth it?)

It seems logical to have a one to one mapping between purposes and
packages, which would mean two packages, I think.  But why not include
the individual authentication capabilities into the capabilities string?

>   This is where things get interesting.  There is a new packet type,
> struct packet_auth_message, which contains two bits of information:
>  (a) A name of an authentication mechanism
>  (b) Up to 512 (could be increased if needed) bytes of arbitrary information
>     in network byte order.  (this is a variable-length field, since it might
>     be desirable to send anything from 0 to 512 bytes of data)

If it is variable length, why are you speaking of a 512 byte limit?
Do malloc()s hurt that much?

[...]

>     Should I check for collisions with the names of existing players before
>    or after the authentication phase?

In the connection dialog, players are identified by name, so a name clash
is always an error.  This won't change if a /rename command is ever added
to allow players to change their own name.  So it seems better to do this
check before anthorization.

-- 
Reinier Post



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