Complete.Org: Mailing Lists: Archives: freeciv-dev: November 2002:
[Freeciv-Dev] Re: connect dialog update
Home

[Freeciv-Dev] Re: connect dialog update

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>
Cc: Mike Kaufman <kaufman@xxxxxxxxxxxxxxxxxxxxxx>, Freeciv-Dev <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: connect dialog update
From: Daniel L Speyer <dspeyer@xxxxxxxxxxx>
Date: Mon, 11 Nov 2002 12:58:31 -0500 (EST)

On Mon, 11 Nov 2002, Raimar Falke wrote:

> On Mon, Nov 11, 2002 at 12:21:46PM -0500, Daniel L Speyer wrote:
> > On Sun, 10 Nov 2002, Raimar Falke wrote:
> > 
> > > On Sun, Nov 10, 2002 at 02:09:12PM -0600, Mike Kaufman wrote:
> > > > here the update on what's happening:
> > > > 
> > > > Nutshell: the connect dialog is being postponed indefinitely.
> > > > 
> > > > Longer explanation: I have become convinced for several reasons that the
> > > > current implementation is not the ideal one. A better implementation is 
> > > > one
> > > > that I originally started with: that being one in which the server is
> > > > controlled via network packets rather than sockets and server 
> > > > commandline.
> > > > This has many advantages:
> > > > 1. you can resurrect a spawned server if you disconnect the client from 
> > > > it. 
> > > > 2. It is a much cleaner interface.
> > > > 3. the current implementation depends on some functions that may not be 
> > > > fully
> > > >    portable across platforms.
> > > > 4. It is semi-difficult to tell if commands have succeeded or not.
> > > > 
> > > > it also has some disadvantages:
> > > > 1. It is insecure. You must make sure that whoever has access to hack 
> > > > level
> > > >    is trusted.
> > > 
> > > > 2. Solving 1. requires either encryption or access to the same 
> > > > filesystem or
> > > >    probably both.
> > > 
> > > Simple solution mention before: pass a cookie to the server via the
> > > command line of the server. A connection which also now has this
> > > cookie get hack level access.
> > > 
> > 
> > Minor modification: pass the cookie through a pipe -- commandline args are
> > visible to anyone on the same host.
> 
> Pipe just calls for problems on windows. Create a file with the
> cookie, chmod it that no other can read it and give the server the
> filename.
> 

<cheap shot>Windows doesn't have chmod either.</cheap>

More seriously, though, this patch allows for that.  Just prepend
"setpassword " to the cookie file and pass it in with -r.  This is
probably gui-specific code anyway, so doing files on windows and pipes
everywhere else is fine.

Making the server (which is almost purely cross-platform) fully general is
the most elegant and future-proof way of doing this.  It can take the
password by file, pipe or network.  It will run on Linux, Windows, Eros,
Linux-on-CD, or some futuristic "network is computer" sort of system.

--Daniel Speyer
If you *don't* consider sharing information to be morally equivalent to 
kidnapping and murder on the high seas, you probably shouldn't use the
phrase "software piracy."

>       Raimar
> 
> -- 
>  email: rf13@xxxxxxxxxxxxxxxxx
>  "The very concept of PNP is a lovely dream that simply does not translate to
>   reality. The confusion of manually doing stuff is nothing compared to the
>   confusion of computers trying to do stuff and getting it wrong, which they
>   gleefully do with great enthusiasm." 
>     -- Jinx Tigr in the SDM
> 
> 



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