How do I create a log file that tells me who visited my page?
nowi...@sciborg.uwaterloo.ca
--
Jack Nowinski
E-Mail: nowi...@sciborg.uwaterloo.ca
Patrick Lee
> How do I create a log file that tells me who visited my page?
You cannot. There is absolutely no fool proof way to tell WHO has read
your pages -- w/o using authentication. The most you can get is WHERE
an access came from but that gives you zero information because there
can be anywhere between one and thousands of users on the other end.
--
Patrick Lee Stuyvesant H.S. Alumni Assoc.
Internet: pat...@panix.com Internet: pat...@panix.com
Web: http://www.panix.com/~patlee Web: http://www.panix.com/~stuy
Ingo T. Storm
>How do I create a log file that tells me who visited my page?
Doesn't your http daemon do that for you? This is of course a log that lists every
single access in one line. You should then use a tool like MUSAGE to summarize the
accesses. You can have a look at the results on <URL:http://shasta.ct.ix.de:8080/usage/husage.htm">
There's also a link to the origin of MUSAGE on that page.
Cheers,
Ingo
-----------------------------------------------------------
Ingo T. Storm eMail i...@ct.ix.de
Redaktion c't CIS 72662,3142
Verlag Heinz Heise
Helstorfer Str. 7 voice +49 (511) 5232-318
D-30625 Hannover, GERMANY fax +49 (511) 5352-417
-----------------------------------------------------------
This sentence no verb.
Matt Watson
:nowi...@sciborg.uwaterloo.ca () wrote:
:
:> How do I create a log file that tells me who visited my page?
:You cannot. There is absolutely no fool proof way to tell WHO has
:your pages -- w/o using authentication. The most you can get is
WHERE
:an access came from but that gives you zero information because
there
:can be anywhere between one and thousands of users on the other end.
Ok, then how does one set-up a way to see WHERE the visits came from?
Patrick Lee
> pat...@panix.com (Patrick Lee) wrote:
> :
> : You cannot. There is absolutely no fool proof way to tell WHO has read
> : your pages -- w/o using authentication. The most you can get is WHERE
> : an access came from but that gives you zero information because there
> : can be anywhere between one and thousands of users on the other end.
>
> Ok, then how does one set-up a way to see WHERE the visits came from?
It's set in the server configuration, which is server dependent. Ask
your sysadmin for the access log file or if you are the sysadmin, RTFM!
Rasmus Lerdorf
>How do I create a log file that tells me who visited my page?
The PHP Tools can do this for you. Have a look at http://www.io.org/~rasmus
for an example.
--
Rasmus Lerdorf
ras...@io.org
Patrick Lee
> % You cannot. There is absolutely no fool proof way to tell WHO has read
> % your pages -- w/o using authentication.
>
> Actually, there is, provided the client machine is running identd. Check out
> RFC 1413, and then look at the bottom of my homepage (the lewd part). Of
> course, you can toss this out the window if you're not running identd.
How do you know you can TRUST identd? And how many systems out there do
you think is running identd? A few percentage, perhaps. identd is
useless for people coming from behind firewalls, PCs, Macs, Compuserve,
AOL, Prodigy, etc. These people probably account for the bulk of the
web users right now.
Rasmus Lerdorf
>This is a much more economical way (for you and for the network) than
>trying to turn every page into a script, just so that you can append
>some CGI environment stuff to a file of your own.
The above is misleading. It insinuates that a cgi program takes up
more network bandwidth than a straight HTML page. This is not the
case. If the page looks the same in both cases, the amount of
network traffic is actually exactly the same. The only reason one
might say that it is more "economical" to not generate HTML pages
from CGI scripts is that a CGI will take a bit more CPU on the server
machine than if the page didn't need to run a cgi.
--
Rasmus Lerdorf
ras...@io.org
Alan J Flavell
Matt Watson <wat...@jeflin.tju.edu> writes:
>Ok, then how does one set-up a way to see WHERE the visits came from?
webmaster, RTFM (or if all else fails, consult the appropriate
c.i.www.servers... group).
This is a much more economical way (for you and for the network) than
trying to turn every page into a script, just so that you can append
some CGI environment stuff to a file of your own.
could be hundreds or thousands of accesses that you never see.
And the previous discussion was right - mostly you don't get told
_who_ did the access, and even if you are told, the information is
very unreliable.
Wei-Yuen Tan
%> How do I create a log file that tells me who visited my page?
%You cannot. There is absolutely no fool proof way to tell WHO has read
%your pages -- w/o using authentication.
Actually, there is, provided the client machine is running identd. Check out
RFC 1413, and then look at the bottom of my homepage (the lewd part). Of
course, you can toss this out the window if you're not running identd.
--
** Wei-Yuen Tan monk...@pobox.com http://pobox.com/~monkeyboy **
#!/usr/local/bin/perl -s-- export-a-crypto-system sig, RSA in 3 lines PERL:
($k,$n)=@ARGV;$v=$w=1+length$n&~1;$v-=$d*2;$w-=$e*2;$m=unpack(H.$w,$m),$_ = `echo "16dio1[lm*ln%]sz\U$k $m $n\Esnsm[d2%Sa2/d0<xsbd*ln%La1=z2]dsxxip "|dc`,s/\W//g,print pack(H.$v,0 x($v-length).$_)while read(STDIN,$m,$w/2)
Alan J Flavell
a5g...@rick.cs.ubc.ca (Wei-Yuen Tan) writes:
>% There is absolutely no fool proof way to tell WHO has read
>%your pages -- w/o using authentication.
>
>Actually, there is, provided the client machine is running identd.
that some confused reader might believe you. The correct answer has
already been given several times on this thread _and_ on several
related threads that are running currently.
I can easily set up IDENTD to say that I am Mickey Mouse. All of
the other thousand users who visit that kiosk station will also
report that they are Mickey Mouse. And the same goes for the other
five kiosk stations in that cluster, if I choose to make it so, What
the quote says is perfectly correct. There is ABSOLUTELY NO FOOL PROOF
WAY. This has been correctly stated several times.
Alan J Flavell
>>trying to turn every page into a script, just so that you can append
>>some CGI environment stuff to a file of your own.
>
>more network bandwidth than a straight HTML page.
cannot be cached, so I do not believe I was wrong, or even "misleading",
in drawing attention to the network implications of turning every
plain web page into a script. One might not have resented your
reply quite so much, if you had asked for clarification of what was
meant, rather then boldly asserting that it wasn't so.
> If the page looks the same in both cases, the amount of
>network traffic is actually exactly the same.
distant host rather than from the local cache server, the implications
for the network are significant - especially on congested international
links.
> The only reason one
>might say that it is more "economical" to not generate HTML pages
>from CGI scripts is that a CGI will take a bit more CPU on the server
isn't the only reason, as I have explained.
Sandra Steingart
Statbot may meet your needs.
http://www.xmission.com/~dtubbs/club/cs.html
--
Sandy Steingart sand...@umd5.umd.edu
http://mail.bcpl.lib.md.us/~sandyste/cholent.html
Bill Graham
my own back end security system and am looking for a way for the user to load their user-id and
password in Netscape variables so that this information will be sent as part of theheader every
time the user interacts with the Server. Could you please describe how this can be done.
Thanks in advance for any assistance.
Bill Graham
Martian
++FLA...@cernvm.cern.ch (Alan J Flavell) writes:
++>This is a much more economical way (for you and for the network) than
++>trying to turn every page into a script, just so that you can append
++>some CGI environment stuff to a file of your own.
++The above is misleading. It insinuates that a cgi program takes up
++more network bandwidth than a straight HTML page. This is not the
++case. If the page looks the same in both cases, the amount of
++network traffic is actually exactly the same. The only reason one
++might say that it is more "economical" to not generate HTML pages
++from CGI scripts is that a CGI will take a bit more CPU on the server
++machine than if the page didn't need to run a cgi.
That is not quite true. An HTML page can be cached. The output of
a CGI-program is always `fresh', and hence cannot be cached.
Abigail