Form Builder - display captured data on redirect page?

9 posts by 3 authors in: Forums > CMS Builder: Plugins & Add-ons
Last Post: November 12   (RSS)

By Toledoh - July 21 - edited: July 21

Hi All.

I'm currently using Form Generator to have a fairly basic web-form.  When submitted without error, the page redirects to a thank-you page.

// on success
redirectBrowserToURL("https://domain.com.au/thanks/");
exit;
}

Is there a simple way to display the data that they entered in the form, on that confirmation page?

ie. can we use the $_REQUEST['first_name'] and display "Thank you [name] for submitting"

Cheers,
Tim (toledoh.com.au)

By equinox - July 24

This would be helpful...and cool! I was literally JUST going through this myself. Interactive Tools: Please post any detailed reply or mod changes to this.

Cheers,

“There are only two ways to live your life. One is as though nothing is a miracle." ~ Albert Einstein

By daniel - July 24

Hi Tim,

I don't believe there's an in-built way to achieve that, but I do have a relatively simple idea for how to go about it.

The primary obstacle is for the Thank You page to "know" about the data you want to use, which by default it won't. So the easiest route would be to pass the data you need straight through with the URL so that it can be accessed with the $_GET variable. For example:

// on success
$redirectUrl = "https://domain.com.au/thanks/";

$redirectUrl .= "?first_name=" . urlencode($_REQUEST['first_name']);
$redirectUrl .= "&last_name=" . urlencode($_REQUEST['last_name']);

redirectBrowserToURL($redirectUrl);
exit;
}

Then on the Thank You page, you could use something like this:

Thank you <?php echo htmlencode(@$_GET['first_name']); ?> <?php echo htmlencode(@$_GET['last_name']); ?> for submitting.

Let me know if you have any questions!

Thanks,

Daniel
Technical Lead
interactivetools.com

By Toledoh - July 26

Excellent - thanks Daniel!

Cheers,
Tim (toledoh.com.au)

By equinox - November 12

Daniel, does using GET in this manner (to pass personal data via the url) open up a security hole (as opposed to some way using POST)?

Cheers,

“There are only two ways to live your life. One is as though nothing is a miracle." ~ Albert Einstein

By daniel - November 12

Hi equinox,

In general, to a dedicated attacker, the difference between GET and POST is negligible. So, when escaping/validating incoming data, it should be assumed that any attack possible with one method will be possible with the other.

If the concern is about exposing personal information, both methods will be equally encrypted by HTTPS during transfer (assuming HTTPS is being used). The one potential difference is that a URL with GET parameters can be saved in a user's browser history, so I would avoid using it for data that is specifically sensitive or private.

Let me know if you have any other questions!

Thanks,

Daniel
Technical Lead
interactivetools.com

By equinox - November 12

The one potential difference is that a URL with GET parameters can be saved in a user's browser history, so I would avoid using it for data that is specifically sensitive or private.

THAT is what I was referring to. While I am no expert (for sure), it's been my understanding that using GET makes substitutions via the url (especially after the "?") fairly easy and should be avoided if possible. 

Cheers,

“There are only two ways to live your life. One is as though nothing is a miracle." ~ Albert Einstein

By daniel - November 12

Hi Equinox,

THAT is what I was referring to. While I am no expert (for sure), it's been my understanding that using GET makes substitutions via the url (especially after the "?") fairly easy and should be avoided if possible. 

Yes, it's true that it's easier to modify the contents of GET variables, and if there are no other considerations, I would recommend using POST instead of GET (for a number of reasons). I was mostly just trying to stress that this doesn't make data sent by POST implicitly more secure or trustworthy. The way I think of it is this: "GET could be changed by both curious and malicious users. POST will only be changed by malicious users." In either case, we assume the possibility that the values could be changed and validate/escape the data accordingly.

Case-by-case use of GET can be useful as it's much simpler to implement in certain situations (such as this one), but overall I agree POST should be the default approach.

Thanks!

Daniel
Technical Lead
interactivetools.com