Securing Form Sections

[neophyte]

Hello All -

I'm working on a project that has various "secure" multi-page form sections that need to be filled out from beginning to end.

The issue is, what to do if someone (or a bot) trys to enter into a 4-page form section on page 2, or 3 (or whatever)?

Naturally, if this is detected, I'll redirect the user back to page 1... but how to detect if the previous sections have been filled out?

I could use $_SESSION data for each page of each form section, but the way the application was initially written, this is proving to be a real pain.

So, I've come up with the idea of a using a $_GET variable (based upon time() + 3600 seconds). Each secure page within a section would have this variable. If the variable is not present, or if the current time > than the variable, the person would be re-directed.

I'm kinda grasping at straws as to how to address this... all "best practices" advice on how to handle this type of challenge is truly appreciated.

[omoutop]

why don't you just check the posted values?
if isset(post)
{
// check posted data
}
else
{
//back to prev page
}

[neophyte]

Hi Omoutop - Thanks for your reply.

That would certainly work if a user was trying to access the 2nd page of a form section, but that wouldn't work if they came into the form section on page 3 or 4 or whatever.

Additionally - on this project - there's a requirement to also "secure" confirmation pages which won't have post vars to check.

That's why I'm trying to go for some "generic" solution that could be applied on the fly to individual or entire sets of pages.

[rocknbil]

There really is no way other than the "hard" ways, but there are a couple of them - which are relevant to the answer.

The first is oldest of old school - at each step, generate a hidden field for each input value of previous steps. The big advantage to this (that no one seems to care about any more) is that this will work independent of cookies or Javascript. The down side is, navigate away from the page, it's all lost.

The second as you are doing is to establish session variables and carry them. This is inherently cookie dependent.

The third, and the one I'd use, is to store the data at each step in a temporary (or permanent) location such as a database and key it to login data. The advantages are multiple: it will allow the user to come back at a later time and complete it; it gives you data you can review for incomplete submissions; it frees up your programming (i.e., instead of checking for a bunch of session variables you just check against the database;) it makes it more portable.

That would certainly work if a user was trying to access the 2nd page of a form section, but that wouldn't work if they came into the form section on page 3 or 4 or whatever.

But it will. Using the database model, you can read the temporary storage fields and group them by "step number". If someone hits page 3 and the required data for 1 and 2 aren't filled out,

$goback=null;

foreach ($field_in_this_step as $required) {
if (! isset($_SESSION[$required]) or empty($_SESSION[$required])) { // or $row, or whatever
$goback=1;
break;
}

if ($goback) {
//go to step whatever
}

So in any case, you'd use one of the three methods above and figure out how and where you're going to store data so you can check against previous steps - this could be a global array at the top of the program or a more solid solution as below.

I wouldn't redirect though, it's an easy solution but makes for sloppy GUI's - that is, a true redirect back to page 1 leaves all field values unpopulated. To counteract that you'll have to add all kinds of extra programming to pull values from the database, or session variables, or . . . it's just better if you engineer it so it just outputs a different state from the same program.

[neophyte]

Rockinbil -

Thanks very very much for your detailed answer and suggestions.

I understand the value of using the database model as explained but I'm a little hesitant to start re-writing database fields for this legacy project I've been handed - I'll give the client a heads up on your suggestion and see where the cards fall.

If I do re-write part of the database to implement this strategy, would you suggest that I use a temporary table to hold the form data? Then, if the entire form set is completed, migrate that row to the "real" table?

[rocknbil]

Well, I wouldn't waste effort on a temporary table, it would be less work to use one table (or multiple, if you decide each "step" requires a different table.) In the table you have a field, call it "form_complete" or whatever that defaults to 0. When the form is finally completed, you can set it to 1. Better yet, you'd have the number increment for each step completed, so complete might be 4.

This kind of stuff is gold when it comes to figuring out where your process is breaking down or deep usability. You can query the tables for "step != 1" for abandoned submissions.

[neophyte]

Hi Rocknbil -

Thanks very much for your guidance on this!