In This SiteIn This Section
|
Take Your Web Site to New LevelsUsing a Session Variable to Secure Your WebsiteIf your needs are not too grand, you can use a little bit of custom coding to protect your pages using a Session Variable. This technique involves a login page that creates a session variable called "uid" that stores the UserID from your registration table. Each page in the secure section of the website will have code that will check to see if Session("uid") exists and if it does not, the user will be redirected to the login page. For pages that need to access the database using the Database Results Wizard (DRW), we'll add some code that will take the session variable and add it to the query string at the end of the url. This will make it available to the DRW just as if you had passed the page using methods that you learned in our tutorial Passing Parameters.Limitations of this techniqueUsing a session based login will only work if your user has cookies enabled on their computer. Session Objects are very similar to cookies and use the same method of storing small amounts of data on your computer. Cookies differ in that they save a file on your hard disk where session objects keep the value in memory. Each member that logs into your site receives their own session object in the web server's memory. The more concurrent users you have, the larger the drain on the web server's resources. A large site with hundreds of concurrent users can slow the server down to a crawl. You can also set the timeout for your session variable depending upon your needs. This will free the resources being used by the session object. Microsoft's Internet Information Server (IIS) v5.0 sets the default timeout to 10 minutes. This is suitable for most needs but you may need to alter the settings in certain situations. This is done by using the code Session.Timeout = 5. This will set the timeout to 5 minutes. First, let's create the Registration DatabaseThis technique relies on the use of a database to hold the registration information. It does not need to be complex. It can contain as little as one table that will contain login information. Call the table Registration and place the fields you would like to track. If you are allowing users to register themselves, you can add a registration page that will collect the information and post to the database. Be sure to include as a minimum the following fields:
You can also add a field to your registration database to specify access level (i.e. Admin=1, Contributor=2, Browser=3 and so on). Create the Welcome PageOnce your users login, they will be directed to the first page in your protected section of the website. Here, we'll create the session object so that subsequent pages will be able to remember your UserID and provide secure access. On your welcome page, select Insert-Database-Results. Choose your registration database as the connection and your registration form as the Record Source. Include the following fields in your DRW, Account_Username, Account_Password, UserID and FirstName. In Step 3, select More Options and Criteria. Set the DRW to require Account_Username=Account_Username and Account_Password=Account_Password. This will make sure that your records are limited to only the registration record that matches the username and password entered into the registration form. If you want to limit access to users of a specific access level then set a third criteria such as AccessLevel=1. This will return records only if they have the correct level of access (set in the Registration Table). Also in the More Options section type the following into the Message To Display of No Records Are Returned:
This message will provide directions to users that have not yet logged in. In Step 4 select List - one record per item and deselect the label option. In Step 5, display all the records together and deselect the search option. Your DRW will now resemble the following:
This will display the four fields for the currently logged in user. I recommend changing this to something a little more personal such as:
You can delete the field values that you don't wish to display. Ok, now comes the FrontPage Magic. Click on the field name <<FirstName>> and then switch to HTML view. You'll see a large section of highlighted code. You need to insert a small code snippet immediately to the right of this highlighted code. Type the following code:
This will create a Session Object called uid that will be equal to the value of the UserID field in your database. It is this session object that will allow us to maintain a record of the current user as they move through the database. Save the file as welcome.asp. You are now ready to create your login page. Create the login pageOn a blank page, add a form for your login page. Place two fields, Account_Username and Account_Password onto the form. Set the form properties as Send To Other and set welcome.asp as the action. This will post the login information to your welcome page. Secure pages using your UserIDIt is a simple matter to protect pages to only those users with acceptable UserIDs. Since only a valid login will create the session variable, then all we need to do is place a little bit of code at the top of our protected pages to check to see if the session variable exists. If it does not, then redirect them to the login page. Here is the code:
The underscore character _ indicates where I've continued a single line of code onto the following line. If you wish, you can delete the underscore and place the code onto a single line. This code does three things. The first line checks to see if the "uid" session exists. If it doesn't, the user will be redirected to the login page. The second line looks to see if the "uid" field is available and if not, reloads the page and adds the uid as a part of the query string. This will make it available for use in the database results wizard. The third If statement prevents users from hacking the page. Once a user has seen the their UserID added to the hyperlink query they might try to hack the database by manually changing the uid value at the end of the query string. For instance, if they change their browser address from:: http://lFrontPageMagic.com/security/login/test.asp?uid=1 to: http://lFrontPageMagic.com/security/login/test.asp?uid=3 the statement will compare the value of the session object to the value in the query string. If they don't match, the user will be redirected to the login page. This offers a moderate level of hacker control. Limit access to specific users onlyIf you want to ensure that only a limited number of users have access to the page, you need to change the code only slightly.
The above code will redirect any users whose UserID is not equal to 1 or 2. This way, only your selected users will have access to the page. Protect Your DataYour data is also protected. If you want a user to see only the data that they have a right to see, you need to set your query to something like the following:
Or in your DRW set the Criteria to UserID=[uid]. Your criteria screen should look like the following:
This login technique is fine for protecting a small website with a limited number of users. For more ambitious situations, and those that must track more than a single UserID, you are better served using a cookie based login system. These tutorials are part of an upcoming training course called "FrontPage Magic - How To Create A Database Driven Website For Non-Programmers". Stay tuned for more details on this exciting new product. Send your tips to .
|
|