Robert, When I was designing the security for a perl/cgi system I spent a lot of time on the cookie issue. I don't have any problem myself with servers putting cookies on my machine. The subject happened to come up with one of the guys that works on the LAN at a customer of ours. He is violently against cookies. He is a technical person and works on computers but has this extreme aversion to "people tracking what he is doing". I think it's more of a baseless fear of the unknown myself.
Anyway, upon further investigation into this, some of the docs I read indicated cookies aren't all that reliable and will get lost if there are too many of them or the data gets too large. Apparently, the spec allows the browser to toss the data if it wants. So, I ended up using hidden variables. It is a bit of a chore, but I have never encountered an objection from a user or a session getting dropped because the data got lost. It certainly avoids the potential controversy that may come up over cookies. Chuck -----Original Message----- From: Robert Landrum [mailto:[EMAIL PROTECTED] Sent: Friday, April 04, 2003 11:53 AM To: [EMAIL PROTECTED] Subject: Re: stopping concurrent logins On Fri, Apr 04, 2003 at 03:34:25PM +0200, Frank Maas wrote: > You can set a session (see Apache::Session and related modules) that > can use the uri as session-container as well (eg > http://www.example.com/9o79876a98d7fa98d7/path/to/doc). The session > part (9o79876a98d7fa98d7) can be stored in a database. > > Success. Technically, that doesn't solve the problem either. Since the session information is in the URL, there is nothing to stop the user from IM that URL to their friend, who then has total access, without a cookie, just by using the current users session. I must not fully understand the taboo against using cookies. It's rare that an online application, e-commerce related or otherwise, works without cookies. If you're doing anything more than browsing static data, you'll quickly become fustrated at the lack of support for non-cookie-enabled browers. Anytime web based authentication is used, people are going to need cookies. Maintaining state and security within a stateless medium is almost impossible without cookies, in my experience. I've heard of, but never seen, authentication using java or flash that maintains a persistent connection in the background using sockets to the web server. This basically "registers" the user's IP address with the system, and all users with that IP are considered authenticated. I'm sure more complicated solutions exist. Sorry I don't have a solution to your problem. But perhaps the problem is the requirement to not use cookies... :) Good luck, Rob > > --Frank -- Robert Landrum Systems Programmer
