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

["Mike Kaufman" <kaufman@xxxxxxxxxxxxxxxxxxxxxx>]

On Wed, May 07, 2003 at 06:32:57AM -0700, Raimar Falke wrote:
> 
> What if the user enters the password in the connect dialog? IMHO it
> belongs there.

You're confusing me. We do this?!? Please compile the client and test this
so we can be on the same wavelength.
 
> > yes we do if the server code checks the password.
> > alternatively we might do pconn->server->user->password, but that's kinda
> > ugly and probably not worth it.
> 
> struct user already contains a password field. Another one for
> connection doesn't seem to be needed.

well, this is dependent on what we do below.
 
> > this is not double negation, but would you feel better if they were
> > NEW_USERS_NOT_ALLOWED and GUESTS_NOT_ALLOWED?
> 
> IMHO "undef NEW_USERS_DISALLOWED" is double negation because it is the
> same as "define NEW_USERS_ALLOWED". It should be NEW_USERS_ALLOWED and
> GUESTS_ALLOWED.

The issue here is that these features are disabled by default. So you should 
have to _define_ them to enable them rather than _undef_ them.
 
> > > You may also want to count the chars which aren't in a..z.
> > 
> > this function is starting to get complicated. Without encryption, I don't
> > see the point.
> 
> These are unrelated. Encryption is against an attacker which attacks
> in a technical way (sniff network, ptrace to the server binary, get
> access to the DB, ...). A non-trivial password is against
> non-technical password guessing. Be it dictionary based or brute
> force. Even with encryption you can guess the passwords. So you want
> non-trivial passwords.

Ok, I'll see what I can do.

> > > > -#define MAX_NUM_CONNECTIONS (MAX_NUM_PLAYERS+MAX_NUM_BARBARIANS)
> > > > +#define MAX_NUM_CONNECTIONS (2 * (MAX_NUM_PLAYERS + 
> > > > MAX_NUM_BARBARIANS))
> > > 
> > > Reason?
> > 
> > People should be able to log in (to observe or multiconnect or whatever)
> > even if all the players have been taken.
> 
> But isn't the same true for the current code with observers?! Except
> the fact that it isn't used.

Yes, it's true. Please don't tell me you want a separate patch for this.
 
> Server and userdb implementation both need user.h and user_db.h. IMHO
> both should be in server/. The user_db.c should be renamed to
> user_db_file.c and be put in server/userdb. For more complex
> implementation we can also add subdirs under server/userdb.

no. you didn't read or remember previous posts. more complex
implementations will do './autogen.sh --enable-auth=/path/to/libmyuserdb.a'
which will replace the native user libuserdb.a. There's no point whatsoever
in including glue for a mysql database (for example) that 0.0001% of our 
users are going to want.

I can see user.h in server/ but for chrissakes, we've got a userdb/
directory, user_db.h should be in it.
 
> > > This isn't atomic. In the time window between these two opens another
> > > may got the lock.
> > 
> > what do you suggest? Me and issues like these don't mix well.
> 
> Sadly there is no easy answer.

ok, I'll see what I can do. 

> > that's right. now let me tell you why we must have a callback for
> > user_db_load and user_db_save. It is simply because in the industrial
> > strength version of this, libuserdb.a is going to fork a process which does
> > lookup into a real database. We cannot have the server hang while this is
> > happening. For various reasons, the lookup might take a while to return.
> > Should a running game freeze while this is happening? In my opinion, no it
> > shouldn't. Hence the callback. Yes there's going to need to be some more
> > apparatus to stop "waiting" for a lookup to return (some check in
> > sniff_packets probably), but damned if I'm going to entirely rewrite the
> > connecthand code in the meantime.
> 
> What is so bad about waiting till the db returns the data? Do you have
> data how long a SQL-DB lookup take?
> 
> If we do what you suggest we would have to disable somehow all players
> which have an outstanding DB query from all actions. Also we would
> have listen to these extra fds in the main-loop.

well, it's certainly not this complex, this since connections which have an
outstanding query can't do anything anyway (although they can send more
authentication requests, which I hadn't thought of, so I'll need to do
something about this).
 
> I'm for waiting. It is easier to program. If there however are systems
> which need 5s to retrieve the data and people want to use these as
> user-db I will change my mind.

After I wrote this last night I thought about it for a while. I was on
crack. I just did a bit of googling, and I see that databases ought to be
faster (at least for the size of databases we're talking about --- I don't
see our pubserver database going much beyond 20000 entries do you? ;) than
the times we're worried about. There's also no reason to fork processes, we
can put our db API right in the lib. Or if we do fork, we can put our
timers in the lib and return after a suitable time.

-mike