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

["Mike Kaufman" <kaufman@xxxxxxxxxxxxxxxxxxxxxx>]

On Thu, May 08, 2003 at 03:31:28AM -0700, Raimar Falke wrote:
> 
> I get gtk errors and a core dump with "./civ -a"
> 
> No problems without "-a".

ok.

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

> > 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.
> 
> I disagree for the reasons outlined above. Reading the code should be easy.

alright, I'll let you win on this one.
 
> > 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.

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

> > 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. Besides, with the locking issues, we're going to have
at least one more file in that directory.

> So there will be a nicer interface in the freeciv code in the next
> patch?!

yes.

-mike