On 9/17/08, André Warnier <[EMAIL PROTECTED]> wrote: > Justin Pasher wrote: > > amiribarksdale wrote: > > > What is the "standard" way to determine whether a user is indeed logged > in to > > > a site and online right then? I have a web app where users log in and > get a > > > cookie. Part of it is the sessin cookie which expires at the close of > the > > > session, and part of it is a longer lasting authentication cookie. Am I > > > supposed to use the session cookie for this? Does it have to be stored > in > > > the db so it can be timestamped? > > > Amiri > > > > Since HTTP is a stateless protocol, it requires a little creativity to > track "online" users. One way is to have a table in a database that keeps > track of a person based upon their username/IP address and the last time > they loaded a page. For example > > > > * Client visits a page > > * Add/Update a row in the table with the client's username/IP address and > set the timestamp to the current time > > * To retrieve a list of "online" users, pull all rows in the database with > a timestamp within the last X minutes (for example, 10 minutes). > > > > You could then periodically delete any rows from the table that are older > than X minutes or hours. This would help keep the size down. The username > for a client would be based upon a cookie or session information stored > within your page.
A more efficient table would contain all visitors with the timestamp of the last visit rather than adding a row for each visit. You must already have a table of all visitors so this only requires adding a "LastVisited" field/column. The data could also be queried for visitors that have not visited in the last 6 months. > Another way of saying this, is that HTTP as a protocol, and the HTTP server > itself, have no such concept as a "logged-in user". Each request from the > browser to the server, as far as they are concerned, is independent from the > next one, even if it comes from the same workstation or IP address. > So the concepts of "logged-in user" or "connected workstation" are at the > application level, and that is also where you have to handle it. > > If both the server and the browser use the "KeepAlive" feature, then to > some extent there is one TCP-IP session kept open between them for a certain > duration or a certain number of requests-responses, but that has only a > vague relationship with the a concept of "on-line users" : such a session > may remain connected for a while after a single browser request, even if the > browser just requested the homepage once without ever "logging in" to any > application afterward. > The same thing with a "disconnect" or "logout" from an application : if the > browser just moves to another page on another server, or is just closed, or > the workstation is powered off, the server would never know about it. Some > web applications implement a timeout, and internally do some kind of > "logout" of the session if they have not seen any new interaction for a > while. But this happens at the back-end application level, not at the HTTP > server level. As André wrote, tracking online visitors is handled at the application level. I once wrote a Web chat application. The discussion page refreshed every minute -- updating the conversation and informing the application that the visitor was still active. This was 1996 -- frames separated the discussion page and the input page. Other pages on the website had an alert symbol when a message was sent to that person. The alert graphic was refreshed every minute (using JavaScript) -- telling the visitor when a message was received, but also informing the application that the visitor was still online. Today, the application could use AJAX to update the discussion area and track online visitors without refreshing the page. solprovider
