Form Builder - display captured data on redirect page?

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.

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,

Excellent - thanks Daniel!

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)?

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,

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. 

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!

Thanks, Daniel!