How do I restrict access to parts of my Web site to only certain users?

Restricting access to parts of your Web site by adding a login form and maintaining a session for logged-in users using Lasso and FileMaker/MySQL.

7-12-2009 by Tami Williams

Why

Here are some examples of why you might want to add a login form to your Web site to restrict access:

How

  1. Create your FileMaker database (and fill it with user login info)
  2. Build a login routine using Lasso and FileMaker Pro
  3. Create a session
  4. Check the privileges of visitors to your Web site before allowing access to the restricted parts

Demo Files

NOTE: All the code in login.lasso could be placed directly in restricted.lasso. Any Lasso code in an included format file is executed as if were placed in the current format file at the location of the [Include] tag.

How it all works

A. The FileMaker database ("Demo.fp7") has a minimum of 3 fields to manage user login information: username, password, and access. Fields for the user's first and last name are also included. Username and password are what the user enters in the login form. Access holds either a "yes" or "no" and is used to determine if the user can access the restricted pages after logging in.

DemoDb

You could also have a "level" field in your database which could be used to describe different types of user access levels - so "administrator" users could see administration-only pages, while "browsers" could only see read-only pages and "editors" could see pages that allow them add, edit and delete.

All kinds of user info could be added to your database through an online registration system.

B. The "restricted.lasso" page includes the "login.lasso" file.

<html>
<head>
	<title>Lasso Restricted Page</title>
</head>
<body>

[include:'session.inc']
[if: (var:'loginSuccess')]
	<h1>Hello [var:'realname']!
	
You have successfully logged in. This is the restricted page.</h1>
[Else]
[redirect_url:'login.lasso']
[/if]

</body>
</html>

C. In the "login.lasso" file Lasso tells your web browser:

  1. If the logout link was just clicked, end the current Lasso session and start a new one
  2. Create the Lasso session and add the session variables
  3. If already logged in, show a logout link, then skip #4 and just show the text from the "restricted.lasso" page
  4. If not already logged in
    1. Determine the correct actions to take/error message to display based on the parameters submitted via the form
      • - If the login form was not filled in correctly, store an error message
      • - If the login form was filled in correctly, search the database
      • - If the database search returned an incorrect result, store an error message
    2. Show the login form
    3. Show the error message (if one exists)

What to watch out for

You might not want to store the passwords in cleartext in your database.

Here's why: a hacker could somehow obtain a list of all the usernames and passwords in your database. Maybe the computer that your database is on was stolen or the database was accidentally exposed to the public on the web.

It might seem relatively unimportant. But most users tend to re-use the same passwords - so the password they're using to access restricted portions of your Web site might also be the password they use for their online banking or PayPal. So, you could inadvertently help a hacker rob your users.

    What you can do is:
  1. Never store passwords in your database in cleartext.
  2. Add a long, unique random string (a "salt") to each password you store.
  3. Store each password as an encrypted string (a "hash").
  4. Store each salt and hash (not the password) in your database.

Example:
Lasso's [Encrypt_BlowFish] tag is [Encrypt_BlowFish: -Seed='yourSalt', 'Encrypt Value']

Encrypting a value with BlowFish can result in several different end-values, even though all will decrypt back to the same original value.

The exact same -Seed must be used when decrypting the text using [Decrypt_BlowFish]. If the seed is forgotten there is no way to retrieve the original value of the encrypted text.

Note: In my experience you'll have problems if you allow users to use non-alphanumeric characters in their passwords. So either prevent users from using non-alphanumeric characters or first pass it through the [Encode_Hex] tag.

The values in the FileMaker database could look like this:
ID: 123456
NameFirst: tami
NameLast: williams
UserName: tami
Password: 476fea6d93bf9254
Salt: demoLogindlg123
Access: Yes

Once the login form is submitted the steps would be:
1. Search the database for the login username.
2. For each of the records found with a matching username, use the Decrypt_BlowFish tag with the found "Salt" as the -Seed value on the the "Password" stored in the database (convert the result to a string because the Decrypt_BlowFish creates a bytes datatype) and compare the result to the cleartext password submitted in the login form. If they match, then the same password was used to create the hash, and the password is correct. If they are different, then the password is incorrect.