Alan M. Bleiwiess

Subscribe to Alan M. Bleiwiess: eMailAlertsEmail Alerts
Get Alan M. Bleiwiess: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Article

Varieties of Welcome

Two ways of welcoming visitors to your site

1. LIMITING your visitors

Alan Bleiwiess wants to keep visitors away
from entry screens he provides for his clients.
He details the scripts he uses to accomplish this.

2. TRACKING your visitors

Nick Borders works with a publisher who wants to
track where visitors come from. He shows you how
you too can collect this information.


1. Limiting your visitors.

By Alan Bleiweiss

Below is the code I use religiously for maintaining security on my clients' sites. All of these sites have at least one or two content or data update pages that clients can use to maintain their site. In many cases, this is a full-blown web-based maintenance system. Password protection is essential. However, I use the code below to carry security to a much higher level.

Of course, I enhance the heck out of it with lots of other checks and balances. For the purpose of this tip, though, I've stripped all the pretty stuff out of it, and added commenting as needed.

It consists of a login screen, the actual index page, and a header file that is CFINCLUDEd on the top of all other pages except the login and index page.

To implement the code, though, in addition to a userid and password field, each person has a third field I call userunique, which I create when they are first entered. I use an algorithm to create a unique 12 or 15 number unique ID, but of course any unique ID works.

Another layer I add is that I also create a field called STATUS, where new users get PENDING, authorized users get APPROVED and deactivated users get DENIED.

The user never knows about the userunique and status fields, thus preventing them from hacking around. This also insures that someone who bookmarks a page or tries to get around the userunique issue, is further blocked when I set the user to DENIED or PENDING, as I check that info ONLY in the query and NEVER pass this field in a form or URL.

I never use cookies. With this code I don't need them.

<!--- LOGIN PAGE --->
<FORM ACTION="loginresultspage.cfm" METHOD="post">
<INPUT TYPE="text" NAME="USERID">
<INPUT TYPE="password" NAME="password">
<INPUT TYPE="submit" VALUE="GIVE ME ACCESS">
</FORM>
<!--- END LOGIN PAGE --->


<!--- LOGIN RESULTS PAGE PROCESS - THIS IS ALSO THE INDEX PAGE 
   OF THE SECURE AREA --->

<!--- If user comes from login page, run this query --->
<CFIF #PARAMETEREXISTS(Form.UserID)# IS "YES">

<!--- QUERY TO SEE IF USERID AND PASSWORD MATCH--->
<!--- AS ADDITIONAL SECURITY, CHECK TO BE SURE THAT USER HAS BEEN 
   APPROVED--->
   <CFQUERY NAME="CheckID" DATASOURCE="UserBase">
   SELECT UserId,Password,UserUnique,Status
   FROM Control
   Where UserId = '#Form.UserID#'
   And Password = '#Form.Password#'
   And Status = 'Approved'
   </CFQUERY>

<!--- If User Comes from inside the secure site, run this query--->
<CFELSEIF #PARAMETEREXISTS(URL.PID) IS "yes">

   <CFQUERY NAME="CheckID" DATASOURCE="UserBase">
   SELECT UserUnique,Status
   FROM Control
   WHERE UserUnique = '#URL.PID#'
   AND Status = 'Approved'
   </CFQUERY>

<!--- If user doesn't come from another page on the site OR the 
   login page, show this--->
<CFELSE>
<CENTER>
<B>
YOU ARE NOT AUTHORIZED TO ACCESS THIS AREA
</B>
</CENTER>
<CFABORT>
</CFIF>


<!---If the Temp URL ID is not a match OR their status has been 
   changed, deny access --->
   <CFIF Clearance.Recordcount is 0>
   YOU ARE NOT AUTHORIZED ACCESS TO THIS PAGE
   <CFABORT>
   </CFIF>

<!--- IF USERID AND PASSWORD AND STATUS ARE NOT ALL CORRECT, 
   DENY ACCESS, STOP PAGE PROCESS --->

   <CFIF CheckID.Recordcount is 0>
   YOU ARE NOT AUTHORIZED ACCESS AT THIS TIME
   <CFABORT>
   </CFIF>


<!--- If the person is coming from anywhere on the site EXCEPT the 
   login page, set content of the temporary URL ID by taking the info 
   from the URL itself --->

   <CFIF #Parameterexists(URL.PID)# IS "YES">
   <CFOUTPUT>
   <A HREF="page2.cfm?PID=#URL.PID#">PAGE 2</A>
   </CFOUTPUT>

<!--- If the person is coming from the login page, set the content
   of the temporary URL ID by taking the info from the database 
   itself--->
   <CFELSE>

   <CFOUTPUT>
   <A HREF="page2.cfm?PID=#UserUnique#">PAGE 2</A>
   </CFOUTPUT>
   </CFIF>

<!--- END LOGIN RESULTS/INDEX PAGE --->



<!--- USE THE FOLLOWING CODE ON THE HEADER OF ALL OTHER PAGES IN 
   THE SECURE AREA --->
<!--- THE SIMPLEST WAY TO DO THIS IS TO CREATE ONE HEADER FILE, 
   AND USE THE CFINCLUDE TAG TO PLACE IT AT THE TOP OF EACH PAGE 
   EXCEPT THE LOGIN AND THE INDEX PAGES --->

    <--- Page 2 Header Process --->
<!--- QUERY the database to be sure that the person going to this 
   page is authorized by matching the URL TEMP ID (PID) with the 
   datafield called USERUNIQUE --->

<!--- As additional security, even if someone figures out to bookmark 
   or write down the PID, also check in the same query to be sure the 
   person still has rights to the area, by checking the status field
   in their data record--if six months after they are online, you 
   change their status, in the database itself, to PENDING, or DENIED,
   they won't be able to get further than here. --->

   <CFQUERY NAME="Clearance" DATASOURCE="UserBase">
   SELECT UserUnique,Status
   FROM Control
   WHERE UserUnique = '#URL.PID#'
   AND Status = 'Approved'
   </CFQUERY>

<!---If the Temp URL ID is not a match OR their status has been 
   changed, deny access --->
   <CFIF Clearance.Recordcount is 0>
   YOU ARE NOT AUTHORIZED ACCESS TO THIS PAGE
   <CFABORT>
   </CFIF>

<!--- IF THEY ARE AUTHORIZED, GIVE THEM ACCESS TO THIS --->
   WELCOME!

     BLAH BLAH BLAH 
<!--- ALL LINKS IN THIS SECTION NEED TO TAKE THE TEMP ID AND KEEP 
   PASSING IT ALONG--->

   <CFOUTPUT>
   <A HREF="index.cfm?PID=#URL.PID#">RETURN TO INDEX</A>
   </CFOUTPUT>


<!--- END HEADER FILE --->

Author Bio
Alan M Bleiwiess
has been involved in Web project management since 1994 and Cold Fusion programming since 1996. He can be reached at
alanb@stpweb.com


2. Tracking your visitors

By Nick Borders

Cookie Monster Takes on Your Banner Ads
Have you wanted to learn more about your users or subscribers, but didn't know how? I work at a publishing company and we are a marketing machine. Our management loves to have accurate and detailed information to present at development meetings. I have developed a method of tracking users to find out where they have come from and if they're subscribers. This is an easy way to find out which banner ads or links from other sites work best and bring the most success. With this information you can take steps to make your Web site more successful.

Cookies, Yum, Yum, Yum!
To track your users you must use some sort of client variable. That could be a number, a phrase or any type of information that you can store for later use. To do this, a "cookie" will work just fine. I'm sure you have heard of cookies--and I don't mean the kind you eat. In case you have forgotten what a cookie is, it's basically a variable that resides on the user's computer. So what do I do with these cookies, and how do they and Cold Fusion allow me to impress my boss?

My application will use a cookie variable that says where the user has come from. If the user subscribes or purchases anything you will be able to track that information.

Where, Oh Where, Do My Subscribers Come From?
When you get a company to display your banner ad, have that banner linked to a copy of your landing page that is only used for that banner ad. Doing this will allow you to track where the user came from, what time they arrived, and other useful information.

I always like simplicity so the only thing I want to know for now is where the user has came from after they have clicked on my banner ad.

EXAMPLE: I have arranged to have my banner displayed at www.schoolrock.com. I have created an exact copy of my landing page and called it school_rock.cfm. At the top of the file I added the Cold Fusion code that adds the cookie to the user's computer. It looks like this . . .

<CFCOOKIE NAME="came_from" VALUE="SchoolRock.com">

This is the simple cookie that I can use later. The way this code is written, the cookie will expire and delete itself when the user shuts down his or her browser. If you want to have the cookie stored longer you can add the code

<CFCOOKIE NAME="came_from" VALUE="SchoolRock.com" EXPIRES=100>

The "EXPIRES=100" tells the browser to delete this cookie after 100 days.

OK, now I have the cookie, what do I do with it?

Know Your Subscribers
When users from www.schoolrock.com decide they are so impressed with your Web site that they want to subscribe, or buy whatever you are selling, they will usually go to a page with a form, that inputs into your Web site's database. When they do, you can have the form look for the cookie variable "came_from" and add that information to the information they added themselves, like their name, address, email address, etc. The form's code looks like this:

<CFIF ISDEFINED("cookie.came_from")>
	
<INPUT TYPE="HIDDEN"  
  NAME="location_coming_from"    
      VALUE="#cookie.came_from#">

<CFELSE>

<INPUT TYPE="HIDDEN"  
      NAME="location_coming_from"
	  VALUE="Not From Banner">

</CFIF>
This code is passed on to your input template. It adds the correct data to the SQL statement to be added to your database along with the user's other data.

These simple statements will allow you to track your users and where they came from. I used this method to find out which advertising host was working better than others and increased our on-line sales. Remember that this simple way of tracking your users can be used along with your log files and tracking software. If you have copies of your landing page that can be accessed only through each of your banners, you can track the number of hits coming from each banner. Knowing this, and also using the scripts explained above, you can get a clearer understanding of your users and where they're coming from.

More Stories By Alan M. Bleiwiess

Alan M Bleiwiess has been involved in Web project management since 1994 and Cold Fusion programming since 1996. He can be reached at alanb@stpweb.com

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.