We have a Drupal 7 webform that redirects to a url upon successful submission.
What we need to do is redirect the user if they land on the same webform again and have already submitted.
Do we need a module for this, or do it programmatically?
Thanks in advance.
I looked through the webform module and didn't find any setting that will redirect the user if the user has already submitted a form, so I think you need to do it programmatically.
Note: It might be possible without a custom module by using the rules module. I haven't tried this.
To do it programmatically you could do something like below. It implements the hook_node_view() and checks if the user has already submitted anything by using the webform api function webform_get_submission_count(). (edit: the custom module in this example is called example_webform)
<?php
/**
* Implements hook_node_view().
*/
function example_webform_node_view($node, $view_mode, $langcode) {
global $user;
module_load_include('inc', 'webform', 'includes/webform.submissions');
$submission_count = webform_get_submission_count($node->nid, $user->uid);
if (!empty($submission_count) && $submission_count > 0) {
$redirect = $node->webform['redirect_url'];
drupal_goto($redirect);
}
}
As it is now it will reuse the page that is used when the form is submitted, so if you choose to do this remember to make the success page reflect this. (E.g. it would be strange for the success page to say "your post has been saved" if the user lands on it for the second time.) Or you could replace the $redirect with another page than the one from the webform setting.
Also note that the webform will still add the message "You have already submitted this form. View your previous submissions." if this is enabled.
So here is the solution that we ended up going with.
I saved the webform and made it available as a block
I created a page to hold the webform
I configured the block to appear above the page content
In the page content I put in some javascript to detect if the form element was present - if not forward to the correct url
So the webform redirects correctly upon submission(set in the webform settings), and it then redirects if the user lands back on that page and has completed the webform.
Ok, here is the requirement.
I want to build a system look like this:
- Header: have a PleaseLoginPanel and SuccessfulLoginPanel
- Content Page just contains content & communicate with header via EventBuss
- HeaderPresenter is the parent presenter & ContentPresenter is nested inside the Header presenter.
Let say when user opens this url "mydomain#content" they will see a page that has header contaning PleaseLoginPanel on top & a content part (beneath the header) contaning some textarea and button for user to input data and submit to DB .
To be able to access the widget in content page the user need to login, after logged in, the PleaseLoginPanel will be invisible and the SuccessfulLoginPanel will be visible. User now can play with widgets in content part.
Let say Session & Cookies will last 1 hour, after the session cookies expired the user can not submit the content data.
Let say user spent a lot of efforts to prepare data & about to submit but the session expired so he can't submit. At that time, in the header the SuccessfulLoginPanel still stay there. So the user can lose all his content he prepared before. You may say, he can open a new page & login & copy the data from the old page (the page that has session expired & does not have PleaseLoginPanel), but that still cost him a lot of effort to copy over.
So I want that, when the Cookes has just expired it will fire an Event to the Header & ask the header to show the PleaseLoginPanel
How can we do that in GWT or GWTP?
Found a solution that is to use timer
Timer showLoginPanelTimer = new Timer() {
public void run() {
getView().getLoginPanel().setVisible(true);
getView().getSuccessfulLoginPanel().setVisible(false);
getView().getEmailBox().setText("");
getView().getPasswordBox().setText("");
Utility.removeUserInfoCookies();
}
};
showLoginPanelTimer.schedule(Utility.COOKIE_TIMEOUT);
I have a form that the user submits and returns a result, but it takes a couple of seconds to return the result. I know I can use grails formRemote http://grails.org/doc/latest/ref/Tags/formRemote.html to execute the call asynchronously and update a div on the page, but what I want to do is show another page entirely (with some wait graphics and other information).
Is there an easy way to do this in grails?
You can send data to server asynchroniously (ajax, formRemote), showing 'wait graphics' util you get a response. And redirect to result page right after getting response (and you should have to store state somewhere, and probably have unique url for result page)
Page one contains an HTML form. Page two - the code that handles the submitted data.
The form in page one gets submitted. The browser gets redirected to page two. Page two handles the submitted data.
At this point, if page two gets refreshed, a "Confirm Form Resubmission" alert pops up.
Can this be prevented?
There are 2 approaches people used to take here:
Method 1: Use AJAX + Redirect
This way you post your form in the background using JQuery or something similar to Page2, while the user still sees page1 displayed. Upon successful posting, you redirect the browser to Page2.
Method 2: Post + Redirect to self
This is a common technique on forums. Form on Page1 posts the data to Page2, Page2 processes the data and does what needs to be done, and then it does a HTTP redirect on itself. This way the last "action" the browser remembers is a simple GET on page2, so the form is not being resubmitted upon F5.
You need to use PRG - Post/Redirect/Get pattern and you have just implemented the P of PRG. You need to Redirect. (Now days you do not need redirection at all. See this)
PRG is a web development design pattern that prevents some duplicate form submissions which means, Submit form (Post Request 1) -> Redirect -> Get (Request 2)
Under the hood
Redirect status code - HTTP 1.0 with HTTP 302 or HTTP 1.1 with HTTP 303
An HTTP response with redirect status code will additionally provide a URL in the location header field. The user agent (e.g. a web browser) is invited by a response with this code to make a second, otherwise identical, request to the new URL specified in the location field.
The redirect status code is to ensure that in this situation, the web user's browser can safely refresh the server response without causing the initial HTTP POST request to be resubmitted.
Double Submit Problem
Post/Redirect/Get Solution
Source
Directly, you can't, and that's a good thing. The browser's alert is there for a reason. This thread should answer your question:
Prevent Back button from showing POST confirmation alert
Two key workarounds suggested were the PRG pattern, and an AJAX submit followed by a scripting relocation.
Note that if your method allows for a GET and not a POST submission method, then that would both solve the problem and better fit with convention. Those solutions are provided on the assumption you want/need to POST data.
The only way to be 100% sure the same form never gets submitted twice is to embed a unique identifier in each one you issue and track which ones have been submitted at the server. The pitfall there is that if the user backs up to the page where the form was and enters new data, the same form won't work.
There are two parts to the answer:
Ensure duplicate posts don't mess with your data on the server side. To do this, embed a unique identifier in the post so that you can reject subsequent requests server side. This pattern is called Idempotent Receiver in messaging terms.
Ensure the user isn't bothered by the possibility of duplicate submits by both
redirecting to a GET after the POST (POST redirect GET pattern)
disabling the button using javascript
Nothing you do under 2. will totally prevent duplicate submits. People can click very fast and hackers can post anyway. You always need 1. if you want to be absolutely sure there are no duplicates.
You can use replaceState method of JQuery:
<script>
$(document).ready(function(){
window.history.replaceState('','',window.location.href)
});
</script>
This is the most elegant way to prevent data again after submission due to post back.
Hope this helps.
If you refresh a page with POST data, the browser will confirm your resubmission. If you use GET data, the message will not be displayed. You could also have the second page, after saving the submission, redirect to a third page with no data.
Well I found nobody mentioned this trick.
Without redirection, you can still prevent the form confirmation when refresh.
By default, form code is like this:
<form method="post" action="test.php">
now, change it to
<form method="post" action="test.php?nonsense=1">
You will see the magic.
I guess its because browsers won't trigger the confirmation alert popup if it gets a GET method (query string) in the url.
The PRG pattern can only prevent the resubmission caused by page refreshing. This is not a 100% safe measure.
Usually, I will take actions below to prevent resubmission:
Client Side - Use javascript to prevent duplicate clicks on a button which will trigger form submission. You can just disable the button after the first click.
Server Side - I will calculate a hash on the submitted parameters and save that hash in session or database, so when the duplicated submission was received we can detect the duplication then proper response to the client. However, you can manage to generate a hash at the client side.
In most of the occasions, these measures can help to prevent resubmission.
I really like #Angelin's answer. But if you're dealing with some legacy code where this is not practical, this technique might work for you.
At the top of the file
// Protect against resubmits
if (empty($_POST)) {
$_POST['last_pos_sub'] = time();
} else {
if (isset($_POST['last_pos_sub'])){
if ($_POST['last_pos_sub'] == $_SESSION['curr_pos_sub']) {
redirect back to the file so POST data is not preserved
}
$_SESSION['curr_pos_sub'] = $_POST['last_pos_sub'];
}
}
Then at the end of the form, stick in last_pos_sub as follows:
<input type="hidden" name="last_pos_sub" value=<?php echo $_POST['last_pos_sub']; ?>>
Try tris:
function prevent_multi_submit($excl = "validator") {
$string = "";
foreach ($_POST as $key => $val) {
// this test is to exclude a single variable, f.e. a captcha value
if ($key != $excl) {
$string .= $key . $val;
}
}
if (isset($_SESSION['last'])) {
if ($_SESSION['last'] === md5($string)) {
return false;
} else {
$_SESSION['last'] = md5($string);
return true;
}
} else {
$_SESSION['last'] = md5($string);
return true;
}
}
How to use / example:
if (isset($_POST)) {
if ($_POST['field'] != "") { // place here the form validation and other controls
if (prevent_multi_submit()) { // use the function before you call the database or etc
mysql_query("INSERT INTO table..."); // or send a mail like...
mail($mailto, $sub, $body); // etc
} else {
echo "The form is already processed";
}
} else {
// your error about invalid fields
}
}
Font: https://www.tutdepot.com/prevent-multiple-form-submission/
use js to prevent add data:
if ( window.history.replaceState ) {
window.history.replaceState( null, null, window.location.href );
}
I want to know the difference between :
$this->forward("module", "action");
And
$this->redirect("module/action");
My first guess is that one implies a new request while the other one not, but I'm not sure.
In some cases, the action execution ends by requesting a new action execution. For instance, an action handling a form submission in a POST request usually redirects to another action after updating the database. Another example is an action alias: the index action is often a way to display a list, and actually forwards to a list action.
The action class provides two methods to execute another action:
If the action forwards the call to another action:
$this->forward('otherModule', 'index');
If the action results in a web redirection:
$this->redirect('otherModule/index');
$this->redirect('http://www.google.com/');
The choice between a redirect or a forward is sometimes tricky. To choose the best solution, keep in mind that a forward is internal to the application and transparent to the user. As far as the user is concerned, the displayed URL is the same as the one requested. In contrast, a redirect is a message to the user's browser, involving a new request from it and a change in the final resulting URL.
If the action is called from a submitted form with method="post", you should always do a redirect. The main advantage is that if the user refreshes the resulting page, the form will not be submitted again; in addition, the back button works as expected by displaying the form and not an alert asking the user if he wants to resubmit a POST request.