[Freeciv-Dev] Re: New authentification code

[Daniel Burrows <Daniel_Burrows@xxxxxxxxx>]

(btw -- whatever mailer you're using isn't properly setting the 

On Sun, Feb 27, 2000 at 01:33:57AM -0500, ½²«íµØ was heard to say:
> Simplicity, modularity, and avoid possible system dependant conflicts.

  I'll tackle these one at a time:

 -> Simplicity: I assert that my approach is /simpler/ than a proxy server.

  Consider the two possibilities:

  (a) User connects to Freeciv server.  User sends authentication data to
    Freeciv server.  Freeciv server accepts user and replies, saying that
    he or she may join the game.

  (b) User connects to proxy server.  User sends authentication data to proxy
    server.  Proxy server compares data, connects to Freeciv server, and
    requests that it be allowed to join as the player, sending an acceptance
    packet back to the user in the process.  Freeciv server accepts user and
    replies to the proxy server.  The proxy server catches this output and
    replies to the user.
      Having all data pass through an external server adds significantly to
    the complexity of the process of transferring such data and introduces more
    problems with authentication: how do we know it's the auth proxy that's
    connecting, and not a random person from the Internet?  Will we have to add
    code to civserver to filter based on IP address?  How do we know someone
    isn't spoofing packets to make them look like they come from the proxy?
    It's much easier and simpler to be sure about what's going on in
    authenticaton if civserver handles it itself. (and to tell the truth, I
    haven't heard of any daemon (except maybe telnetd, but even that has
    internal authentication code these days..I think..) which has authentication
    and relies on a proxy to do it; if you could point one out to me I'd be
    quite interested)
      There are ways to solve all of these concerns, but they all increase..
    complexity!  Many of them even require touching the civserver code!

 -> Modularity: I'll grant that a proxy server would be more modular than my
    approach.  I'm not exactly adding these routines inline into
    handle_packet_join_game_request, though; the low-level stuff (except for
    packet definitions, which naturally go in packets.[ch]) for the auth
    routines is all contained in a single file.

 -> System-dependencies: the only thing I can possibly see being a problem is
    byte order.  If you're worried about this, I suggest we stop using TCP/IP,
    as that can also be affected in bad ways by incorrect byte order.
     If you mean something else, please say what you mean.

> The worst would be novice trying to figure out why can't he play a
> solo game caused by authentification problem.

  (a) If you're worried about byte ordering, please remember that
  connections to localhost will always work regardless of endianness.
  So this is irrelevant (although it would be a bad thing to get into a
  situtation where byte order matters, which is why I won't do that)

  (b) My code defaults to the historic Freeciv behavior; that is, no
  authentication at all.  So this shouldn't be any more of a problem than
  before.  (what if the novice changes username or tries to reconnect from
  another host?  The default choice to provide as an ID to the server will
  be wrong)

  (c) If proxies are required, this is more likely to fail.  If not, having
  the proxy do authentication is meaningless anyway, as players will be able
  to connect directly to the server and bypass it.

  Daniel

  PS - the POP server here is having some serious problems and seems to be down
      atm (it was scheduled to go down at noon today, but maybe they took it
      down a little early..) so I may not be able to see further comments on
      this for a while.

-- 
Whoever fights monsters should see to it that in the process he does not
become a monster.  And when you look into an abyss, the abyss also looks
into you.
                -- Friedrich Nietzsche