$node->webform['confirmation'] available in 'redirect box'
mediamash - January 5, 2009 - 09:59
| Project: | Webform |
| Version: | 5.x-2.x-dev |
| Component: | Code |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Jump to:
Description
are the $node->webform['confirmation'] variables available inside the confirmation php box?
I'm trying to display an attachment of a referenced node like this
<?php
// drupaldestination contains the node id of the attachment i want to display
$what_node = $form_values['submitted_tree']['drupaldestination'];
// $node->webform['confirmation'] = 'internal:node/'. $what_node;
// We load the node and the attached files by the nid (here nid = 26)
$files = upload_load(node_load($what_node));
// and use the themeing function of the upload module to print the attachment table
print theme_upload_attachments($files);
?>
#1
if this is done in the Additional Processing Field it displays the attachment, but on an empty page (which is not the result we want)
#2
Within the "Confirmation" box, there are no variables available. You can check the SID (submission ID) from $_GET['sid'] or the node ID from arg(1).
#3
The problem with using GET variables like $_GET['sid'] is that a curious user can very easily view the results from other people's webforms by changing the ?sid=xxxx in the URL. Best practise for websites is to use POST variables.
#4
Well, POST variables aren't any more secure than GET. They're a little bit more work to fake, but not that much more. Regardless of where data comes from, you actually need to verify it if you want to be sure that it's what you expected it to be.
I looked through the code on this a bit (trying to learn more about this module) and it did not appear to me that the webform module itself is using $_GET['sid'] in any kind of inappropriate way, at least not directly... however, it does seem to be the case that a custom theme function or PHP code could cause problems if it blindly used information passed down from $_GET['sid'] to load and display data... is that correct? If so, this could probably be fixed by adding additional access checking in webform's hook_menu. (That's off-topic for the current issue, but I could open up a separate issue if that makes sense to fix.)
#5
I agree with you that it is possible to fake a POST variable, but GET variables are an open invitation for the curious user. To fake a POST, someone would have to be familiar with the workings of webform in order to know the name of the variable.
My workaround solution is to check that the current ip is the same as for the original submission. Do you think that is good enough? Here is my code:
// if someone else is trying to snoop on the submission from a different IP, give them a 404if ($submission->remote_addr != ip_address()) {
drupal_not_found();
module_invoke_all('exit');
exit;
}
I have pasted the full checking code here: http://drupal.org/node/236515#comment-1201515
#6
Which vars are safely passed to the confirmation page? I would like to add this info to the handbook.
#7
No variables are available on the confirmation page, assuming you're using a PHP input format on the confirmation message text area. Since this code is run through the normal Drupal filtering system, it is handled through drupal_eval(), which sandboxes the code and doesn't allow provide access to any predefined variables at all (other than globals like $_GET). By this point the page has already been redirected, so the $_POST variable is also empty.
#8