If your cookie isn't set, this is a new user. If you need to know which user exactly then you can ask for a name (and put that name into the cookie). No need to ask for a password. If you just need to differentiate between users (without needing to know a name) then the value of the cookie is just a random number you store somewhere.

If it is set you check the cookie and know now which "thread" is doing the asking.

That won't prevent users from easily impersonating each other

No, but he didn't say that he needed that. Not everything needs to be locked with key and authentication. Think intranet wiki, work group data, user preferences

If authentication is important, there might be other ways: A login/startup script could put a personalized cookie (i.e. a random number) into the cookie file of the browser and tell the server which user has which cookie number. This is a hack since you have to know which browser is used and if that browser changes its cookie file syntax, your app will malfunction and could even stop the browser from running.

But if the browser is not the normal browser but a separate instance started and solely used by the application this would be acceptable.

It is not too clear to me what you mean, but - you can, in your web server config or script, differentiate between requests coming in through the loopback or external interfaces. If you need a username as parameter, you have no way without authentication, since http requests are by default anonymous. Only after requesting authentication (e.g. sending back a 401 status code and an Authentication line, the client will send a username embodied in the next GET or POST request.

You could use Kerberos to handle that transparently.

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

Well, all my requests come through the loopback interface, so I've already eliminated external requests.

I know http requests are anonymous; but since both the server and the client live on the same system, I thought maybe I can somehow determine from which local user the request came. I understand there is not much hope, though.

You might be able to do that by plugging some firewall that knows how to deal with "packet owners", denying all connections to your local web server if the outgoing packet does not come from "The user".

Here's a Linux example, assuming that user's ID is 1234 and the web server runs only on local interface (lo), on TCP port 80:

 # iptables -A OUTPUT -p tcp -m owner --dport 80 -o lo+ ! --uid-owner 
+1234 -j DROP
[download]

There might be some server-specific or browser-specific solution. For example, I think that for IIS if you disable anonymous access and enable integrated authentication, then IE will just send the user's credentials along, without ever prompting for a username/password. I think there's also a mod_auth_something for apache that can be configured to work the same way, checking Active Directory for its data.

You might be able to find a simpler solution based on the fact that the server and client are the same machine. For example, if you are running all of this on a single-user desktop windows machine, your cgi app could (I think) find out the currently logged in user through WMI. You're probably better off going with a more standard method though. Writing a home-grown authentication method is just asking for trouble. Even if nobody cares to hack into your app, they might still exploit a bug or oversight in your scheme to gain access to other parts of the system. When your users whine about having to type in a simple id & password (just once if you use cookies), tell them it's for their own data security. They should get over it quickly.

To me this seems like a good example of when not to use a Web based solution.

It probably does yes.

If it makes sense to represent the user interface as an interactive document it does not necessarily mean: web based solution. As far as I know most GUI’s around have widgets for representing documents as well. Take for example products like oXygen and XMLSpy: Fat clients in which the interface can be presented as an interactive document. I am sure there are many more examples.

My advice would be to rethink your solution. It would save you a lot trouble.

Well, yeah, they got widgets. I'll just need to add tab browsing, history, bookmarks and a dozen other things — and I'll be fine.

Gtk2::MozEmbed
wxHtmlWindow
Tk::HTML
Prima::TextView

Yes, why not.

Make up a random number on first request and set a cookie. Then require that the number is valid on each subsequent request.

Keep the random number per server or per session, depending on whether you want to have one user per server or many.

/J

Then how are you having a problem? Let each server pick a different port, because they can't share the same one.