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

["Mike Kaufman" <kaufman@xxxxxxxxxxxxxxxxxxxxxx>]

On Tue, Mar 25, 2003 at 02:13:04AM -0800, Per I. Mathisen wrote:
> 
> On Mon, 24 Mar 2003, Mike Kaufman wrote:
> > > Nice. But I think "take" is a better name for the command than "takeover".
> > > Also "Take a player's place in the game" is better.
> >
> > you've got readline. I always use 'take' as the command anyhow.
> 
> Which is why it is bad to have "takeover". If everyone talks about "take",
> new players will wonder where that options is, and what "takeover" is...

fine, 'take' is ok.
 
> > Hmm, well this provides maximum description. Say I start a game with 2
> > humans and 2 AI and I want people to join the game and take over for the
> > AI... When a someone logs on, they see "Server AI" being played by AI.
> > ("Unassigned" will work here as well) If they become that player (actually
> > I'm going to disagree with you, I like 'take' better). then the username
> > switches to that connection's login name. If someone leaves the game for
> > whatever reason, the AI will take over, but the connection's username will
> > remain. If that player logs back on, and there is a player with his login
> > name, he will be automatically attached and join the game. So you want
> > "Unassigned?"
> 
> It is better.

ok.
 
> I think that a player with a username should be reserved for this user,
> for example by having a password that only the server and that user's
> client knows. Then there should be a way for the cmdlevel ctrl user to
> make a player unassigned.

I don't understand. you want to have a ctrl user be able to pick a login
name out of the database and assign it to an AI player? That's
unacceptable. A user should never have access to the database on that kind
of level for one. A command that prevents players from automatically taking
would suffice with much less fuss.
 
> I don't remember how you tried to solve this in your previous auth patch.
> 
> > > Finally, the 'list' command should show all connected users, even if not
> > > related to any player.
> >
> > try 'list connections'. remember that my original auth patch had all sorts
> > of bells and whistles like this. My current approach is a barebones auth
> > with snazziness coming later. I plan on switching the default so 'list'
> > shows connections rather than players.
> 
> I didn't try that. I think the default 'list' should list both players and
> connections, and that should be done in this patch, since the result
> without this will be much confusion.

I agree, though I do not think it should be done in this patch. This state
of affairs will be in flux (I swear). I want a barebones implementation
before adding whistles and this is one of those. This is also easy to do
as a standalone patch.
 
> > this is where people and I are going to disagree I think. I am against
> > having observation where you get to see the whole map (the dead hack).
> > Observing should mean observing one player only at a time (and that player
> > will control 'obsconnect' (as well as 'multiconnect') for himself.
> 
> Global observation is much used on pubserver, AFAICT. It is a very nice
> feature, both for players and for debugging. Please provide arguments why
> this feature should not be present.
 
1. there's huge potential for abuse.
2. there's huge potential for abuse.
3. there's huge potential for abuse.

nothing has to be decided about this now as current behavior is maintained,
but there needs to be safeguards put into place. I'll think about how best
to implement these. It'll probably be a modified allowconnect checked in
command_take() in stdinhand.c

-mike