Complete.Org: Mailing Lists: Archives: freeciv-dev: May 2003:
[Freeciv-Dev] Re: client/server authentication (PR#1767)
Home

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

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: undisclosed-recipients:;
Subject: [Freeciv-Dev] Re: client/server authentication (PR#1767)
From: "Mike Kaufman" <kaufman@xxxxxxxxxxxxxxxxxxxxxx>
Date: Thu, 8 May 2003 11:39:49 -0700
Reply-to: rt@xxxxxxxxxxxxxx

On Thu, May 08, 2003 at 11:23:39AM -0700, Raimar Falke wrote:
> > no it won't. As I said before, very few will actually want an authenticating
> > server. Those who do will compile it via --enable-auth.
> 
> I would like to see the default authentication included at configure
> time as the default. On of the reasons is code coverage. We should
> include the code in the normal compilation to find errors and to
> include it on changes we do. Just think of the code in the clients
> which don't get compiled regularly.
> 
> If the authentication is enabled or disabled by default is another
> story.

no. The server-side code will be compiled often on pubserver. The default
database code won't, but then it'll be relatively separate from the main
code anyway. Unless the registry api changes, There won't be much danger.
This is not a good enough reason to add object code to the executable. This
is analogous to compiling all the clients all the time if you can, but only 
linking the one you want. no thank you.
 
> > I absolutely disagree. This will not happen. This is a challenge, response
> > system. There are a variety of reasons why a server will or will not want a
> > password. The very issue that one can register a user directly from the
> > connect dialog is enough to not want to do this.
> 
> These are technical reasons. Take a step back and think what a user
> may want. The user is used to enter both username and password. At
> least I think so.

you don't use ssh much? or login? Sure windows users may have to adjust a
bit, but so what. I've thought a great deal about this thank you very much.
And these are not simply technical issues.

> But I agree that implementing this is a technical problem. One
> solution would be that the client sends the join_request after the
> user pressed RETURN on the username.

eh? we do this already. try_to_connect() sends send_packet_login_request().

-mike



[Prev in Thread] Current Thread [Next in Thread]