preventing partial entries duplicate

[turpentyne]

I've run into a little bit of a logistical nightmare on some registration pages I've taken over work on.  On these pages, parents register their kids for classes. The pages have been coded as such:

page one: the user enters name and personal info, and selects one or two classes to register for, on submit, they go to page two.

page two: their info is entered into the mysql database's registration table on a unique id  The user verifies the total, enters a discount and submits

page three: credit card info is added to registration table, and sent to authorize.net.

page four: payment processed, and they enter the data for their kids into the attendees table

page five: confirmation and done.

 

My issue is that, at first I saw people entering page one data, going to page two, then for some reason, hitting the back button. They could then enter the data again. I'd have two entries in the registration table for the same person. I was going to put some sort of unique key on the name and an email, but then I saw scenario two...

 

Another person enters data and registers one kid.. then for whatever personal reason goes back and registers a second kid in a completely separate transaction.

 

So I can't put that key on there, but is there a way to prevent them from going back and reentering twice. I don't want to have to blow up the code to do it at the end of everything. and that would take implementing sessions, wouldn't it? I'm not so versed at that. Any thoughts?

 

 

[Muddy_Funster]

how much freedom do you have over the backend of the system?  and why in the name of {insert chosen deiety here} would you ever hold creditcard details? that's a massive ball ache from a conforming to legal standards of safe practice point of view.

 

one dirty way would be to run a check versus [date / time]++[kids name]+[iP Address] in the registration table and change the insert to an update if a record is found to have been generated by that email address on that day, or within the last 5-10 minutes for a child with that name from that IP Address (or any combination there of).

[Nodral]

Or use a bit of Javascript to disable the back button.

[Muddy_Funster]

Or use a bit of Javascript to disable the back button.

 

Great idea....and for the people like me who surf 90%+ of the time with JS dissabled? IMO Javascript shouldn't be used for key functionality, just making things look nice and sleek now and again.

 

[Psycho]

So I can't put that key on there, but is there a way to prevent them from going back and reentering twice. I don't want to have to blow up the code to do it at the end of everything. and that would take implementing sessions, wouldn't it? I'm not so versed at that. Any thoughts?

 

Sessions are very easy to use. In fact, the only way to prevent a user from creating a duplicate record is to track the id of the record they have already created. Which would require session or cookie data. A session would probably make sense, unless you want to allow them to start the registration process, exit, and come back later to finish. But, really you should not create the record until you have all the necessary info.

 

Javascript isn't really a solution and will cause its own problems.

[turpentyne]

So, bear with me while I type this out to think it through for a minute, and get corrections/suggestions/whoah nellies and so on... Sorry if it's a jumbled mess. just trying to wrap my head around something new...

 

 

On page one, I leave my posted form as is, but add in a hidden field that is a generated unique id like this?

 

<?php
  
$unique_id = uniqid (rand (),true);
  ?>
<input type="hidden" name="unique_id"  id="unique_id" value="<?php echo $unique_id; ?>"  >
<input type="submit" value="Submit"  class="buttontype"/>
</form>

 

I would then take the insert query that's on registration page 2 and move it to page 4 where they enter the kids name...generating session variables something like...

 

$fname = $_POST['fname']; 
$lname = $_POST['lname']; 
$address = $_POST['address']; 
$phone = $_POST['phone']; 
$email = $_POST['email']; 
$wid = $_POST['wid']; 
$unique_id = $_POST['unique_id']; 
$datetime = date('Y-m-d H:i:s');

$_SESSION['fname']=$fname;
$_SESSION['lname']=$lname;
$_SESSION['address']=$address;
$_SESSION['phone']=$phone;
$_SESSION['email']=$email;
$_SESSION['wid']=$wid;
$_SESSION['datetime']=$datetime;
$_SESSION['unique_id']=$unique_id;

 

On page two there is also a subtotal/add a discount/total owed  form? Can I just add these as more variables to the session?

On page three, where I'm... I start the page with sessions, but do I need to do anything else? Redeclare the session variables, or are they taken care of?  Not sure how this part works, really. And when they hit the back button, does(or, how does) that uniqid cover me for a resubmit, or refreshing page one, entering the data and trying again?

 

<?php session_start(); ?> 
// I assume I add this at top, then give them the subtotal/add a discount code form?

<form id="yet_another_form"></form>

 

Page three is still passing the payment variables to the authorize.net code on page 4... I think it'd be nice to have that taken care of on page 3, to Muddy_Funster's point ... but one problem at a time, I suppose. so on page four, I'm assuming I break out the session variables into regular variables again??

 

session_start();
if (isset($_SESSION['fname']))
{
$fname = $_SESSION['fname'];
}

if (isset($_SESSION['lname']))
{
$lname = $_SESSION['lname'];

} / * and so on */

// then the query insert finally happens, written same as originally?

$query_insertItem = "INSERT INTO tbl_registration (reg_fname, reg_lname, reg_address, reg_address2, reg_city, reg_state, reg_zip, reg_phone, reg_fax, reg_email, reg_how, reg_how_detail, reg_dc, photo_release, reg_timestamped) VALUES ('$fname', '$lname', '$address', '$address2', '$city', '$state', '$zip', '$phone', '$fax', '$email', '$hear', '$how', '$res', '$released', '$datetime')";
$dberror = "";