I purchased Shaun Inman’s Mint web statistics tracking package last week, and I’m really enjoying it. It’s just so pretty I want to show it to everyone! However, Mint version 1.1 doesn’t allow multiple users to access the statistics page unless you run it in demo mode. But then, everyone can see your stats. The alternative is to fork over your precious registration email and password to whoever you want to see…ugh, not an option.
UPDATE Actually this isn’t true,…the first time you install, it is actually prompting you to create a new user/password, and you can make any username/password you like by changing your preferences…it is NOT a login authentication key. I was confused. If you’re still interested, read on…
Anyway, I think I figured out how to make the
.htaccess work with Mint so I can provide webserver-based user authentication without messing up Mint’s stat capturing…I’m still testing and am writing things down so I don’t forget.
Boring technical notes follow! You’ve been warned!
The Basic Idea
It centers around the use of the
.htaccess file, which you stuff into the Mint directory.
- Run Mint in demo mode, but provide webserver based authentication so you have to type in a username/password. By controlling this with
.htaccess, you can manage the usernames/password/groups yourself.
.htaccesscontrols prevent the script from loading if you don’t type in the password for every page on the site. Which basically kills stat tracking while annoying your site visitors. I found this out the hard way…nice guy Joe Rawlinson clued me in so I could fix it, as I wasn’t seeing it because I’m local. Thanks Joe!
Speaking of local, it would also be nice to not have to authorize from my own office network, for maximum stats-checking pleasure. The
.htaccessfile should be able to accomodate this too.
1. Set up your password and group files
I followed [these instructions][htaccess] to create my user password and group file. You’ll be referring to these files in Step 2. You should probably make sure you know how to use
.htaccess files for this kind of thing first, if you are unfamiliar with the process.
I (belatedly) made a copy of my Mint folder for testing. A test page (outside of my blog) includes the
<script> tag pointing to the
mint.js.php file in it. This way I could test that it was working before messing with my real setup. This kind of behavior is still kind of loose and dangerous since I don’t really know how Mint works, but hey…live a little!
2. Create the
.htaccess file in the mint directory
.htaccess file has the following in it. Pay attention to the comments to see what you need to change.
# .htaccess file for mint directory # beware! understand how this works before you try it! # edit indicated areas below... # # if your mint url was: # http://blah.com/mint # ...it is now: # http://blah.com/mint/index.php # change AuthUserFile and AuthGroupFile to point to your files AuthUserFile /path/to/non_html/directory/ht_users AuthGroupFile path/to/non_html/directory/ht_groups AuthType Basic AuthName "Mint Demo Authorization" <files index.php> <limit GET POST> order deny,allow deny from all # OPTIONAL! # Change IP address in the 'allow' line to your # static IP address, then uncomment the line. # This will allow the matching IP to login without # invoking the user/password dialog. # allow from 220.127.116.11 # in my AuthGroupFile, I have a group called mint require group mint satisfy any </limit> </files>
All this tells the webserver to require a user in the “mint” group (which is defined in my
ht_groups file) to enter a password whenever the
index.php file is requested. Since this is the only file protected, the other files in the Mint directory are allowed to be freely accessed. This includes the critical
mint.js.php file, which is included on all your tracked pages.
3. Enable Demo Mode in Mint The directions were posted in this thread on haveamint.com.
Changes to Mint Operation
You must now specify the index.php when visiting the Mint URL! For example, if you were going to:
…you now have to use:
There is probably some way of using
mod_rewrite to fix this, but
mod_rewrite gives me the willies.
I’m also not sure just how secure this is, since only the
index.php file is protected. It at least prevents casual access to the stats page.
Just to feel better, I also added the following to the end, to prevent the
configuration.php from being retrieved…
<filesMatch "configuration.php[~]*"> <limit GET> deny from all </limit> </filesMatch>
The Aftermath, Thus Far
So far, it seems to be working, but I am not a web server configuration genius. Hopefully this won’t blow up in some subtle-but-interesting way…