Manual - CHAPTER Six

Online Manual Index

AXS 2.02

We do not provide support directly for this product as the script provider maintains their own support pages. You may visit http://www.xav.com/scripts/axs/

Again, please do not send any questions regarding AXS script to support@2unet.com or the support-desk

AXS tracks visits to your web page and processes those records into meaningful graphs and database listings. The scripts tell you where your visitors are coming from, charts their flow through your site, and tells you which links they follow when leaving. In addition, it records their server name, IP address, type of web browser, and time of visit.

Axs is a great tool but please use with Caution! This is our beta for using AXS 2.02. It is our recommendation that you use AXS only when necessary. We do not encourage you to use AXS on all of your pages since your log files will be working over time and get fill up quickly. Too many activity may load our system. If any account brings the system down, we will deactivate AXS on your account and will not reactivate it again.

Visit your AXS main page

http://yourdomain.com/cgi-bin/ax-admin.cgi

At prompt, type your login and password. Please feel free to play arround after that!

Configuring Your Web Page

The preferred tracking method is with server side includes. To use this method, place the following SSI call in all of your HTML pages. If the logging script is in a directory other than cgi-bin, substitute directory names for the following examples:

For this to work, your web server must support this type of command. Most do. This command tells the web server to execute ax.cgi before sending the document to the visitor. If they view the source code from their browser, they will just see a blank space where the SSI call used to be.

Sometimes you have to rename your .html documents to .shtml or .stm in order for server side includes to function. Other times you have to place a custom .htaccess file in your home directory with a special AddType directive. Other times you have to harrass your provider into enabling SSI.

If your server doesn't allow SSI, or you have trouble getting it to work, then we use the transparent redirect method. On every document, place the following image tag:
<IMG SRC="/cgi-bin/ax.cgi?whatever.gif">
where "whatever" is any string of letters or numbers. This produces a tiny one pixel by one pixel transparent gif. It won't really show up and it will let you log everyone without SSI. The image redirects won't let you see where people are coming from, though, and they only work if the visitor has his graphics cranked up.

The Microsoft Internet Explorer web browser has a nasty habit of placing script-generated images into the visitor's cache. When this happens, the first visit is logged, but when MSIE gets to another page with the embedded image tag, it prefers to pull the image out of its own cache instead of off your web server. Because of this, the ax.cgi script won't be executed again, and the visit to the second (or third or fourth) documents won't be recorded.

You can trick MSIE into downloading a new image each time by making the query string random. On your main document you'll have SRC="ax.cgi?one.gif" and on another document you could have SRC="ax.cgi?xxx22.gif". MSIE will treats these as separate images and will initiate a clean download.

Whichever method is used to log visitors to internal pages, all links to off-site web pages should be re-written as redirects:
<A HREF="/cgi-bin/ax.cgi?http://www.yahoo.com/">Yahoo!</A>
The above link takes the visitor to ax.cgi without them noticing anything, and then the logging script redirects the visitor to the intended web page. This allows you to track which links are used as people leave your site.

If you have documents on your page which aren't HTML and therefore don't contain the SSI call, you should link to those as a redirect too:
<A HREF="/cgi-bin/ax.cgi?http://xav.com/readme.txt">Read ME</A>
In theory you can also link to embedded objects (sounds, images, class files, and so on) as redirects:
<IMG SRC="/cgi-bin/ax.cgi?http://www.xav.com/pict.gif">
Do not get carried away. It is best to avoid writing to the access log more than once each time a page is hit. If each page download writes to the log twice, then there is a high chance that the data will get corrupted and the whole log will be lost.

Similarly, if you have a frames page, include the SSI call or image redirect on only one of the documents.

If this sounds confusing, don't worry - as long as you are consistent, you shouldn't get into any trouble. Use SSI on every HTML document you have, and redirect on every non-HTML or offsite link.
Security Issues
As this script shows, it is possible to log the URL that a visitor is at before he arrives at your page. The AX-ADMIN script creates a list of such URL's for you. The list is hyperlinked, so as you scan which web pages are referencing yours, and you may click on the links from your admin screen and jump right to the site in question. The list of referring URL's is convenient, valuable information, but it is also a privacy issue. Some people don't want you to know which URL they were at before, or the URL might contain sensitive information and so it's location is a secret.

The web address of your admin module might be considered one such URL with sensitive information, whose location should remain secret. But if you follow one of the links that this script creates, your previous URL (the URL of your admin module) can then be recorded by a webmaster at another site, who can then backtrack it and view your access log at will. It's kinda a case of HTTP_REFERER coming full circle.

Therefore, it is in some cases advisable not to follow the links from the admin page. Look but don't click. You can always copy the URL and then safely enter it in the address window. Of course, there is little danger in back-tracking search engine hits to see where you fall in the heirarchy, or in back-tracking links to your friends' sites. This danger is one of the reasons we added the script-based password protection - be sure to use it. As a general precaution you may wish to also place AX-ADMIN within a directory that has htaccess protection. This will require that those using the directory give a valid username and password - anyone backtracking to your admin module will be greeted with a login screen instead of your access stats.

To set up .htaccess protection, create the following text file named .htaccess and place it in the same directory as your ax-admin.cgi script (you might want to create a separate sub-directory specifically for this purpose):
AuthType Basic
AuthName Access Log Manager
AuthGroupFile /dev/null
AuthUserFile /home/adam/.htpasswd

<LIMIT GET POST PUT>
require user adam
</LIMIT>
where /home/adam is your personal login directory, and adam is replaced with the username that you would like to use. The file we just created will tell the Apache webserver (and variants thereof) to authenticate (ask for username and password) before a visitor can use the directory in which it resides. It says that the visitor must have username adam, and that his password must agree with the one in the .htpasswd file. So our next step is to create this password file.

At the unix prompt, type:
htpasswd -c /home/adam/.htpasswd adam
where /home/adam is your personal login directory, and adam is replaced with the username that you would like to use. Your server will ask you for twice for a password. If you want to change it later, you can run the same command later without the "-c" attribute.

We may have to make the .htaccess file readable and executable by the webserver:
chomd 555 .htaccess
Setting up .htaccess authentication is sometimes difficult, and not all unix machines support both the .htaccess protection and the htpasswd program. Windows NT doesn't support it at all. If your provider does not support these things, try a different one. ;)

We hope that this section does not make your overly paranoid - we just want to let you know what some of the dangers are, and to give some suggestions on how to decrease the risk. Some people might wish to let everyone view the access log (that's what we do around here).
Creative Applications
Note that this script can work for documents on your web page and elsewhere on the net. You can post an image to USENET as:
<IMG SRC="http://www.yourdomain.com/cgi-bin/ax.cgi?http://www.yourdomain.com/pict.gif">
and then view the statistics on people who view the picture from their browser-based newsreaders. The people being logged will never see your site, they may never know what happened, but you'll have their access stats.

This script could also be set up on a CGI-enhanced provider and used to log accesses on a different, non-CGI-enhanced web page (though only the redirect method will work in these offsite cases, and the full URL to the redirect script will have to be written out as in the above example).

If you go to a guestbook on your friend's page and enter your URL as:
http://www.yourdomain.com/cgi-bin/ax.cgi?http://www.yourdomain.com
you will be able to log each time that link is followed. The same works for mailto links:
http://www.yourdomain.com/cgi-bin/ax.cgi?mailto:me@yourdomain.com
and just about any other URL-based expression. You can always add a redirect to a URL, and you can chain your redirects as many times as you'd like (though, again, this may cause data corruption if you set up your redirect calls back-to-back).
Customize the script and delete the log file

Because you'll typically generate the same graphs repeatedly, AXS allows you to specify default settings. Enter your most common settings. Later, AX-ADMIN will select those values automatically.

The access log will grow by about a kilobyte for every six hits, eventually becoming too large for processing. We recommend deleting the log every so often. Before doing so, you'll want to generate your favorite graphs and save them to your system as HTML files, as a record of how your site traffic evolves over time.

Setting your time zone

From the script ax.cgi example below. Look at the section that is highlighted in red and change the variable as the script suggest. Re-upload the script

Telnet in, at prompt type cd www/cgi-bin

At prompt type chmod 755 ax.pl

Please note that the server time zone is Eastern standard time.

#!/usr/local/bin/perl

# AXS Script Set, Logging Module, Version 2.02I Beta
# Copyright 1997, 1998 by Fluid Dynamics. Please adhere to
# the copyright notice and conditions of use which are described
# in the attached help file and hosted at the URL below.
#
# For latest version and help files, visit:
# http://www.xav.com/scripts/axs/
# __________________________________________________________________

# The location of your log file relative to this script. This is path
# and file name, not a web address. Leave this as is for a default
# install.
$LogFile = 'log.txt';

# Set this to 0 to forbid debugging, 1 to allow it. Leave this as is if
# you're installing for the first time.
$AllowDebug = 0;

# The following are examples of Perl debugger errors that come up when
# this script is transferred in binary format. If you get an error
# that looks like this (or a web error regarding "Internal Server Error"),
# then binary/ascii conflicts are probably the problem. Delete the script, and
# re-upload it in ascii format. Then give executable permissions
# (chmod 755 ax.pl) again, and you should be fine. This comes up on
# Unix web servers, not Windows NT ones.
#
# [mu]/usr/www/users/xav/beta> perl -w ax.pl
# EOF in string at ax.pl line 166.
#
# [mu]/usr/www/users/xav/beta> perl5 -w ax.pl
# Illegal character \015 (carriage return) at ax.pl line 2.
# (Maybe you didn't strip carriage returns after a network transfer?)

# __________________________________________________________________
#
# The following shouldn't need to be changed:

$domain = 'http://'.$ENV{'SERVER_NAME'};
# If your webserver doesn't support SERVER_NAME, then set this variable
# as the top-level URL to your server without a trailing slash, e.g.:
# $domain = 'http://www.yourdomain.com';

$header = "Content-type: text/html\n\n";
# This should be deleted if the content-type header is being echoed out
# to your SSI output, otherwise leave as is.

$Version = '2.02I Beta';

$TimeOffsetInHours = 0;

# The above variable allows you to correct for a different time zone if
# your ISP is somewhere else. This is an integer of +/- a certain number
# of hours. i.e., ISP is in Pennsylvania and owner is in Seattle:
# $TimeOffsetInHours = -3;
# ISP in Australia, owner in London:
# $TimeOffsetInHours = +12;
#
# __________________________________________________________________

Troubleshooting

The script that we installed in your site are the latest beta version adapted on Oct 08,1998. For more documentation and script update, please visit http://www.xav.com/scripts/axs/

2uNet

© 1997-2000 Silver Palace International LLC

Virtual Servers, Businesses, Asia, America, Website Hosting, International Business, Web Services, FrontPage98, USA, US, Italy, Virtual Hosting, Japan, Australia,Domain Services,Web Space, Singapore, England, Virtual Hosting Services.