1. You could make everyone create an account to save any data on a smaller scale and come back later and submit the form
or
2. You can create an alert message when the user no longer wants your page to show.

There are different reasons to do one or the other. If you had a long form for something like a scholarship or a detailed personal profile, that would be the case for the account to save the data in smaller chunks. However, lets say you have a form with many fields that requires some data input and alot of options to parse through. That would be a case for an alert message. But since HTTP is stateless, how would one accomplish this?

The way that this could be accomplished is to insert some Javascript into the page. While some browsers, and users, may have javascript turned off, most nowadays do not. This trick will help out in the majority of the browsers. By using the onBeforeUnload function, it will check to see if the page is being left. So we need to add the script:

<script language="javascript">
var message = "Please do not leave my awesome site";
window.onbeforeunload = function() {
        return message;
}
</script>

However, this will show the message:

on everything that makes the current page go away. This includes closing the browser, refreshing the browser, going to another site by typing in the address, or clicking on a link. Besides, the whole point of this alert is to alert users when they have filled out data on the form and are leaving without submitting, not make them angry as they leave (but that is a post for another time).

So no matter what, even if the form is not filled in, it will display the message. So we need to only show this alert if there is something in the form. To do this, we can just loop through the form elements. Say we have a form with the name of “form1″.

for( var i = 0; i < form.elements.length; i++ ){
        if( form.elements[i].value.length == 0 ){
              // do the alert message here
        }
}

If the form elements are blank, they will get the alert message. If they are not blank, then it will not fire off the alert. Remember this is a very holistic approach here, and may not be suitable for all forms. However, there is one other problem. If they click on Submit, they are going to get the alert message. So we need to check that real quick.

var submit = false;
function submitAssets(){
	submit = true;
}

Now add that function to the submit button:

<input type="submit" name="submit" value="Submit" id="submit" onclick="submitAssets()" />

So now if they click the submit button, it will change the variable to true, and we have to check that variable:

<script language="javascript">
var submit = false;
function submitAssets(){
	submit = true;
}

var message = "Please do not leave my awesome site";
window.onbeforeunload = function() {
    if ( submit ) {
    if ( !submit ) {
        for( var i = 0; i < form.elements.length; i++ ){
            if( form.elements[i].value.length == 0 ){
                    return message;
                }
            }
        }
    }
}
</script>

Now it will check all elements in the form, if anything is left off, then it will fire off the alert message.

A note here. Aft5er many hours of looking into this and trying to see if I can, on the alert box, there are two messages that are wrapped around the custom message:
"Are you sure you want to navigate away from this page?"
"Press OK to continue, or Cancel to stay on current page"

These can not be changed. I may be looking in the wrong places, but if they can be, please let me know. Most instances it will not matter, but if you have a site in Spanish, or French, or any other language, make sure your custom message is translated and will give a good heads up on what the alert is saying.

There it is. An alert message to warn a user before they leave the page that data is not completed. You can extend this by checking for checkboxes not selected, text boxes not selected, etc:

. . .
window.onbeforeunload = function() {
 . . .
        if (form.elements[i].type == "checkbox"){
            . . .
        }

        if (form.elements[i].type == "textarea"){
            . . .
        }

        if (form.elements[i].type == "select-one"){
            . . .
        }
        // and so forth
}

You can put those all in an array, or set a variable in the loop, then after the loop, if they are not filled in, fire off the message. Helpful for those long forms that require almost everything to be filled in, and halfway through the form, you just want to go elsewhere. It may help in some instances. Remember to understand your audience first. If this works for them, then great. If not, do not do it.

So a quick post about security in a site. I will not claim that I know everything about security, but I have always been about the common sense stuff of a site. Some of the things to keep in mind:

1. All data is tainted, and therefore, before you accept any data and put it in the database or file system, SANITIZE it. This is for forms, forums, wikis, etc. use PHP’s own functions at the very least to help clean the data. Never just blindly run the data through your database. You can open loopholes to malicious entries into your tables, or just have tables disappear altogether. By allowing un-sanitized data in, you are opening yourself to a SQL Injection attack. And while people will not bother with most sites, it is entirely possible they can use a SQL injection to use your server as a host or bounce for other mischievous activity.

2. Sessions are great, and use them with caution. What this means, is try not to pass a session id via a query string in the URL. Session hijacking uses this, as it is easy to grab a session ID just from a Google search, a post from a forum, or blog, etc. I just suggest not to do it. Cross-site scripting will also try to sniff the session ID as well. Saving the session ID in a cookie is fine, but regenerate the ID at times, validate the session ID when doing anything for admin functions, check out functions, etc. Just keep in mind what people are able to do on your application, and how that would be a problem if a session was hijacked.

3. SSL vs no SSL. It all depends on your application. If you have anything remotely personal that is required, just pony up the money to get a cert and put it on the server. Many times when I am browsing around, if it asks for my name and address and phone number/email address, I look for that lock/cert. Even though this is all contained in the current phone book, I am not sure what information they will ask for next. And especially if you are going to ask someone for their credit card number. Never leave that in the open.

4. Personal information on the application. If you are building a business site, and need to put business information up, then do it in a way that will not harm people inside the business. Posting email address of regular employees, direct numbers, etc can lead to a hassle and business identity theft. Put the main number/main email address (per department if there is one) and leave it at that. If it is a personal site, never post your personal information/financial info on the site. Not even to brag.

5. Leech protection. There are many ways to protect against other sites pulling in your graphics. Take the example of a college football fan who posted a full article about the Oklahoma Sooners quarterback being involved in drugs and other illegal activity. He mimicked a local Oklahoma newspaper site. He took the CSS, and layout from the web, and linked to their images they hosted on their servers. The result? Many people and even major news sites took this as a true story. The guy got in trouble, had a lawsuit against him from the local paper, an eventually took it down. This happened, and luckily the local paper was able to track this down. Many phishing attempts are done in this way. You get an HTML email from a bank saying you need to complete some information, and they give you a site that looks exactly like the real deal. Safeguard your images, and do not let other sites use those.

6. Have fun and be observant. Web applications can be fun, and can be really dangerous. Think common sense when programming, think common sense when debugging and unit testing. Do not let a small “trite” thing be overlooked, as that may be the one back door that others use to get into the site. You should have a good sys admin setting up the servers, a good network admin manning the routers and firewalls, so it is up to you to remember to be common sense about the actual application.

Some of these are really basic common sense. Most security loopholes are because people forgot the basics. There is only 1, that is right – ONE, sure way to never get hacked, get a virus, have a security hole. That is to never plug your system into the web, and never turn it on. But what fun is that?