A: Basically, you are correct. Traditional servers (NetWare or Windows NT, for example) authenticate users based on the workstation-to-server communication's using "stateful" protocols. This means that a user establishes a connection to the server, which is maintained for the duration of the user's session. At any time, the server will know who is logged on and from where. HTTP servers were designed for the rapid and efficient delivery of hypertext documents and are stateless. An HTTP connection has four distinct stages:

1. The client contacts the server at the Internet address specified in the URL.

2. The client requests service and delivers information to the server about the browser's capabilities.

3. The server sends the state of the transaction and if successful, the data requested. If the server is unsuccessful, a failure code is sent.

4. The connection is closed and the server does not maintain any memory of the transaction that just took place.

Because the server does not maintain a connection for the duration of a session, it does not know if there are multiple browsers using the same name and password. The effect is as the Webmaster fears: An office of 50 or more people co uld be using the same user name and password to access the authenticated Web server simultaneously.

Cookies help in this situation. A cookie, in HTTP terms, is a type of license with its own, unique ID number. Coo kies let you force a user to log in again when he uses the same user name and password from a different workstation. Cookies work as follows:

When a user logs in for the first time, the server will issue a cookie that it will associate with this user to the workstation browser. For subsequent access to the Web server, the browser will present this cookie number, which will be checked against a cookie database. This cookie is sent every time a request of any type is made from the browser to the server.

If a login request from another workstation using the same user name and password comes along, this workstation browser will not have a cookie to present. In turn, the server will issue a new cookie number and log on the valid user name and password from the new location.

Now, the user at the original workstation makes another request with the cookie number originally received. The server will see that a new cookie number already has been issued and it will return an unauthorized header, prompting the user for a user name/password pair.

This method does not guarantee that users will not share user names and passwords, but it will annoy users to the extent that they are likely to get their own user names and passwords.