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

["Mike Kaufman" <kaufman@xxxxxxxxxxxxxxxxxxxxxx>]

On Thu, Apr 03, 2003 at 12:50:14PM -0800, Per I. Mathisen wrote:
> 
> On Thu, 3 Apr 2003, Mike Kaufman wrote:
> > the
> > situation is: a user [kauf] connects, and then decides he doesn't want to
> > play, so he unattaches himself from the anonymous player he has.
> 
> I guess using /unattach ?

yes.

> > we can overload /take if that's what you want to do, or we can use
> > /create as such, or we can create a new command /attach. I created a little
> > logic table, and /attach wasn't in it. I could do either, but the second is
> > probably the best.
> 
> Now you lost me. I am a little slow. Can you try to explain all this in
> layman's terms?

/take gives control of an already created player to a particular user.
at the info level, a connection can give himself control of a player:
  /take <player>
at the ctrl level, a connection can give other users control of a player:
  /take <someuser> <player>

we could give /take a third use, namely without arguments, or with just a
user, create an anonymous player and attach yourself (at info cmdlevel) or
that user (at ctrl level) to that new player. I find this slightly
confusing since connotationally, you're "taking" a _particular_ player.

or we could just use /create first to create an actual [AI] player and then
use /take normally. That shouldn't disallow people from changing the
temporary name they used in the /create when they get to the races dialog.
 
> > We will need a second command to unattach a connection from a player (I've
> > tentatively called it /untake for symmetry). We could use "/remove username"
> > but I think this is too confusing.
> 
> Isn't this where /unattach comes in?

yep, /unattach == /untake, though /unattach is probably a better name.

> > On another note, we need some way to prevent people from taking over
> > players when not wanted.
> 
> You mean taking over AI players? Leave it as is for now, which is everyone
> can do so. Eventually we need a voting mechanism for elevating access (or
> rework firstlevel) in order to make the system foolproof, allowing normal
> pubserver users to have info cmdlevel. However, going to great lengths to
> make one part foolproof when the entire system is full of holes is no
> point.

no I mean taking over human players (or players that got toggled to AI or
away mode). This was the original intent of authorization. If I need to 
leave a game for some reason or get lagged, I don't want someone pilfering 
my player while I'm trying to reconnect.

-mike