[Freeciv-Dev] Re: New authentification code

[Daniel Burrows <Daniel_Burrows@xxxxxxxxx>]

On Sun, Feb 27, 2000 at 08:11:03PM +0100, Reinier Post was heard to say:
> 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?

  Yes, I thought of that.  There are a couple of reasons I didn't do it:
first, I wanted a way to get directly at the list of authentication
capabilities, and didn't want to use something like prefixing each one with
AUTH_; second, the list of available authentication capabilities isn't
static -- it depends on which ones are enabled in the server, which can be
modified by the server operator.  (at least, that's the intent; I'm not sure
it works just yet :) )  The capability string is static and chosen at
compile-time.

> >   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?

  Well, there has to be some limit due to the limited packet size (unless I
want to break stuff up on one end and reassemble it on the other, which is
more complexity than I really want to have (some auth protocols might need this,
though, in which case I guess I'll have to bite the bullet))
  All limits are arbitrary, some are just more arbitrary than others..

> >     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.

  Ok.  I actually do it now both before and after authentication, just to be
sure.  (because authentication does not take place instantly, someone could
theoretically connect while another player is still identifying him/herself
to the server. I don't want someone who hasn't logged in completely to
lock other players out of using that username, as that would make it easy
to deny access to someone simply by starting to log in as them and never
completing the authentication stage)

  Daniel

-- 
The New Testament offers the basis for modern computer coding theory,
in the form of an affirmation of the binary number system.

        But let your communication be Yea, yea; nay, nay:
        for whatsoever is more than these cometh of evil.
                -- Matthew 5:37