Documentation
SUPERCLOAKER:  V1.0 


Preliminary Material for review

System Requirements

  • Server Sides Includes
  • .htaccess full override would be nice but not required
  • Perl 5

Preliminaries

  • Determine the path to PERL 5 on your web server host.  Note that some web hosting companies run both PERL 4 and PERL 5.  Make ABSOLUTELY sure you are not setting this up under PERL 4.  Ask your administrator if you are not sure.
  • Download the tarfile for this program and save it to your desktop. 
  • Unpack the tar archive on your desktop using a program that unpacks UNIX TAR ARCHIVES. If you don't have such a program then download WINZIP FREE from SHAREWARE.COM
  • After you have unpacked the TAR archive you will have a collection of folders and files on your desktop.  Now you have to do some basic editing of each of these files (or at least some of them).  Use a text editor such as wordpad, notepad, BBEdit, simpletext, or teachtext to edit the files.  These are NOT WORD PROCESSOR DOCUMENTS they are just simple TEXT files so don't save them as word processor documents or save them with extensions such as .txt or they will NOT WORK.   Note that there may be a some files inside of folders which are "blank".   This is normal.

Preparing the CGI scripts

Define Path To PERL 5

The first step is to open up each and every file that has a .cgi extention and edit line number one of each script.  Each of the cgi scripts is written in perl 5. For your scripts to run they must know where perl 5 is installed on your web server. The path to perl 5 is defined to a cgi script in the first line of the file. In each of the cgi scripts the first line of code looks something like this:

#!/usr/bin/perl

If the path to perl 5 on your web server is different from /usr/bin/perl you must edit the first line of each cgi script to reflect the correct path. If the path to perl 5 is the same no changes are necessary. If you do not know the path to perl 5 ask the webmaster or system administrator at your server site.  

Configure the .cgi files

supercloak.cgi

As they say, simplicity is the trademark of genius.  This script is very simple and elegant in design but also VERY powerful.   Below are the variables used to configure the script.  Pretty straight forward.  You will need to setup TWO folders.  One for the protected HTML you only want the search engines to see and the normal HTML for the rest of the world.   First let's go over the variables inside the top of supercloak.cgi.  Before getting into that create a directory inside your webspace and chmod it to 777 called cloaked and another called uncloaked.  Create a directory inside your cgi-bin called supercloaker and upload all the cgi and chmod them all to 755.  These 2 folders "cloaked and uncloaked" contain the protected and normal HTML you will be serving.  Thus they are identical in appearance except for that oh so special HTML tags and keywords you use to maximize your search engine positioning that piss you off when some jerk steals your HTML.

  • $cloakedirectory="/home/psybercore/superscripts.com/htdocs/demo/supercloak/cloaked";
  • $uncloakedirectory="/home/psybercore/superscripts.com/htdocs/demo/supercloak/uncloaked";
  • $robotlist = "/home/psybercore/superscripts.com/htdocs/demo/supercloak/robot.list";
  • $cloakeuri="cloaked";
  • $uncloakeuri="uncloaked";
  • $rootdirectory="/home/psybercore/superscripts.com/htdocs";
  • $indexpagename="index.html";

$cloakdirectory is the FULL path to the PROTECTED HTML files.  These are basically just copies of your normal HTML specially tweaked for search engine optimization. 

Similarly, $uncloakedirectory is the FULL path to the UNPROTECTED html files you wish the general public to view

$robotlist is a line by line list of all the major search engine spiders (see the dox for stealth server for a fairly recent list but you can EASILY find more up to date lists all over the net with a little searching,

$cloakeduri is the URI to the cloaked directory.  You can also set this up as a canonical domain.  For example (cloaked.mydomain.com and likewise uncloaked.mydomaincom for the next variable $uncloaked URI.   (see the tutorials if you don't get what a URI is - NO IT IS NOT a URL)

$rootdirectory is the FULL path to your ROOT html directory space.  Screw this up and nothing will work right, actually screw any of them up and nothing will wok right.

$indexpagename is a special variable that you commonly use to name index pages inside directories.  For example (index.html, index.htm, welcome.html, etc).  This is used because if you clone a URL such as http://www.yourdomain.com/index.html it can also be called up as http://www.yourdomain.com/ and that will cause problems unless you set this variable.

Uploading the files

  • /cgi-bin/supercloaker/
    • supercloaker.cgi
  • /supercloaker (commonly these are just uploaded into the root level of your HTML webspace
    • cloaked directory
    • uncloaked directory

OPTIONAL BUT ADVISED

If you are one of the fortunate ones with a REAL WEBHOSTING ACCOUNT that doesn't cripple your ability to do all those supercool .htaccess functions you may also want to upload the included .htaccess file into your root HTML directory where your home page would reside.  The reason for the file is to re-inform your webserver that .html does the same things as .shtml.  Sometimes search engines get upset when you submit .shtml files for the very reason of HTML cloaking.   By using the .htaccess file there is literally no way for them to know since they appear as harmless html files.

Server Sides Includes

Finally you will need to create server sides includes tags inside the pages you want protected.  There is an example file already included for you.  Simply cut and paste the

<!--#EXEC CGI="/cgi-bin/supercloak/supercloak.cgi" -->

SSI tag inside of the pages you want protected and away you go.  Please note that many wannabe ISP's won't have a clue about the .htaccess thing I mentioned earlier or won't care to help you out.  Also I wouldn't worry about protecting every damned page on your site.  Search engines really get pissed off when they detect deliberate subversion, spamdexing and the like.   My advise is to just protect the key gateway entrance pages so you don't get into some battle with the people that should be your best friends (the search engines!)