Re: seeing who is using the site..

rf schreef:
"Erwin Moller" <Since_humans_read_this_I_am_spammed_too_much@xxxxxxxxxxxxxxxx> wrote in message news:493facbe$0$183$e4fe514c@xxxxxxxxxxxxxxxxx
rf schreef:
"Erwin Moller" <Since_humans_read_this_I_am_spammed_too_much@xxxxxxxxxxxxxxxx> wrote in message news:493f9fe0$0$184$e4fe514c@xxxxxxxxxxxxxxxxx
Erwin Moller schreef:
The Natural Philosopher schreef:
Interesting problem. Who is 'online' to the site? and what pages are they accessing..

Ok, could just do a nasty bit of regexp on the logs..but what about every page extracting callers IP address, its own identity,(all my pages are php) and possibly what bits of the database are being accessed....

any ideas on a nice way to present this in a 'sysadmin' page?


Hi Philosopher,

The 'who-is-online' is a little hard on normal setups.
I approached it in the past like this, but that was on a site that demanded people to log on first:
That was poorly and confusing formulated.
What I wanted to say: If you demand them to log in, you know WHO they are, as opposed to unknown visitors that happen to start a session with your site.
If they do not authenticate themself with username/password, you can of course happily start a session anyway.
But you will never, ever, know when they "leave".
True.
That is why session timeout, eg after half an hour of no activity.
If you store the session in a db, they will get deleted after that timeout has expired.

Hint: I sometimes have several copies of my several browsers open. Sometimes for days. Perhaps weeks. A browser keeps a session cookie untill *all* instances of that browser is closed. I may revisit the subject site next week, with the same session cookie.
????
I don't see your the point of your hint, rf.

I use a timeout of half an hour on most of my sites (which is default I think).
After that your browser holding a PHPSESSID (in cookie or url or form) is invalid and the session file on the server will get deleted sooner or later.
SO you can keep your browser open with its PHPSESSID cookie, but the PHPSESSID is invalid when you return to the server.

Look at the subject line, "who is using the site".

You can tell when I start "using" it. You can never tell when I stop using it'.

Yes, we established that.


By your timeout you will determine that I have stopped "using" your site sometime between one half an hour in the future and next week. Perhaps I access one of your pages now, go get some coffee, get distracted and come back tomorrow to actually read the page. When am I "using" your site? Now, or tomorrow?

Restated: "If you use a session with a timeout on it, you won't be able to track visitors that lose their session because of that timeout."

To which I completely agree of course.

But I still have trouble understanding your point.
You wrote:
----------------------------------
Hint: I sometimes have several copies of my several browsers open. Sometimes
for days. Perhaps weeks. A browser keeps a session cookie untill *all*
instances of that browser is closed. I may revisit the subject site next
week, with the same session cookie.
----------------------------------

The last line gave me the impression that you don't understand how sessions work.

Our philosopher already said he was not after a full analysis, which is impossible to start with considering AOL (changing IPs for the same visitor) and people behind the same proxy (same IP for different people).
With such requirements, sessions are an easy way to track what your visitors do on your site, hence my suggestion to use them.

But maybe I just have a slow day I keep missing your point. ;-)

Regards,
Erwin Moller

--
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult."
-- C.A.R. Hoare
.

Relevant Pages

  • Re: infinite session timeout
    ... will remain in memory. ... closes their browser, then logs in again, you know will have two sessions on ... You should keep the timeout. ... It will be somewhat transparent for your users when their session does ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: ASP sessionstate
    ... ASP doesn't know or care what browser it ... ticket number given when the first item is added to the cart. ... How can a Response.Write write to the server screen? ... :> delete the cart file and set the session ...
    (microsoft.public.inetserver.asp.general)
  • "Compaq Web Agent" management session can be re-used without the need to perform authentic
    ... destructive actions (as server reboot). ... Compaq Web Agent Service 6.0.0.0 using Compaq HTTP Server 5.1.0 on ... servers via a secured HTTP session from a browser client, ... via a legitimate authenticated SSL session - if he closes the session by ...
    (Bugtraq)
  • Re: Attempt to de-mystify AJAX
    ... >>maintaining a session via URL is not a problem. ... >> around cookies and JS, but it seems to be tough. ... >> as needed back to the server. ... but as I mentioned before - a non-dynamic request by the browser can ...
    (comp.databases.pick)
  • Re: Problem with a session
    ... Your first posting was a bit vague, but now I understand your problem. ... the POSTDATA and sets againg the session variable to true and anyone ... This IS a real problem, and you cannot 100% solve it. ... try to tell the browser NOT to chache it. ...
    (comp.lang.php)