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

["Raimar Falke" <rf13@xxxxxxxxxxxxxxxxx>]

On Thu, May 08, 2003 at 08:53:19AM -0700, Mike Kaufman wrote:
> On Thu, May 08, 2003 at 03:31:28AM -0700, Raimar Falke wrote:
> > For "-a" and also some other cases the user should _be able_ to save
> > his password in his freecivrc and the client should read it from this
> > location. The client shouldn't save it there. At least not without
> > asking the user.
> > 
> > The extra step where you type your password should be removed.
> 
> As chris mentioned, I would be willing to go for a --password option, which
> if it is used, will skip the password input step and send that password to
> the server. 

Command line options are bad since they can be viewed by the other
users of the system. ps shows this.

> > The server should sent a message text what the policy is. Something
> > like "Welcome foobar. Please enter your new password. It has to be at
> > least 4 characters and must contain at least 2 digits."
> 
> hmm, perhaps we should send the complete policy if is_good_password() fails
> instead.

Yes this sounds good.

> > > Yes, it's true. Please don't tell me you want a separate patch for this.
> > 
> > No. But _maybe_ you can do seperate commits:
> >  $ cvs commit server/setnet.h -m "increase ... because players want to ..."
> >  $ cvs commit # the rest
>  
> jeez, ok, I put this in a future patch.

I'm not sure if this is ok with the policy but I would say just commit
this one-liner now. Since we have seen this is also fault in the
current system.

> > > > 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.
> > 
> > About what glue are we talking here?
> 
> user_db_load -> parse username into sql query -> sql_get_query -> 
> parse sql response into user struct -> return from user_db_load

> etc. There's no point to have to test for sql libraries in freeciv code.
> This should be external. We'll put in on the ftp site somewhere if someone
> wants it.

Yes. The user-db only has to implement the C-interface. How this is
done doesn't matter.

> > > I can see user.h in server/ but for chrissakes, we've got a userdb/
> > > directory, user_db.h should be in it.
> > 
> > This may be an indication that the userdb/ directory isn't needed.
> 
> no. This needs to be an separate library, and building two different
> libraries in one directory doesn't seem great design to me.

> > As a side note: I think we should seperate between the user_db
> > interface (user.h and user_db.h) and the implementation
> > (user_db.c). So user_db.c should be renamed so that it contains a
> > "file", "reg" or "simple".
> 
> why? This seems to me one of the more pointless renames. You need a better
> rationale that this. 

A have the idea that in the default installation there would be a
server/libfile_userdb.a. If now someone want to build another userdb
for mysql this would end up in server/libmysql_userdb.a. At configure
time it is decided what library should be built. For freeciv it
doesn't matter if the mysql code files are in server/, server/userdb/
or server/userdb/mysql/.

> Besides, with the locking issues, we're going to have at least one
> more file in that directory.

You plan to import lockfile.c?

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  This customer comes into the computer store. "I'm looking for a mystery
  Adventure Game with lots of graphics. You know, something realy
  challenging". "Well," replied the clerk, "have you tried Windows 98 ?"