I have code in place to disable caching in my MVC application. I'm using the following response headers. They seem to work in all browsers except for Chrome (currently using version 31.0.1650.48). Users are able to submit a form with model values. When they hit the back button I need the page to reload with a blank model. The headers appear to partially work since the request is hitting the action and returning the blank model. However the view isn't updating. The values from the previous post are being retained. I've tried clearing the ModelState but that doesn't work. Any suggestions? Thanks in advance!!
filterContext.HttpContext.Response.Cache.SetExpires(DateTime.UtcNow.AddDays(-1))
filterContext.HttpContext.Response.Cache.SetValidUntilExpires(False)
filterContext.HttpContext.Response.Cache.SetRevalidation(HttpCacheRevalidation.AllCaches)
filterContext.HttpContext.Response.Cache.SetCacheability(HttpCacheability.NoCache)
filterContext.HttpContext.Response.Cache.SetNoStore()
Turning off autocomplete for the form fixed this for me. I appreciate all the input!
<form autocomplete="off"></form>
There is a way to do this in javascript for everything in one go like so...
document.getElementById("YourFormID").reset();
Just add an id to your form and all your inputs will reset on page load. Regardless if its a first time visit or a back button click with the page being cached. The biggest difference from your solution and this is that "the autocomplete attribute is new in HTML5". Which means it is not supported in older browsers, and though it does what you want it also prevents the user from autofilling fields. Meaning that for example on text types inputs users will not see a suggestion of words they may have entered on previous or other pages. You can see an example here.
I've noticed a problem with nested forms and i'm not sure how to solve it. My forms are working fine normally, this isn't really a question about how to get them to work. This question is more of a 'what should I do in this scenario'.
When I use a nested form via fields_for it works great. When I add in the javascript to be able to add and remove fields everything works great. I can add, save, remove, save, no problems. However If you edit an object with a nested form then delete one of the nested objects (via sending the {'_delete' => true} parameter with the object), then you use the back button and save that form again without deleting the same fields you will get an error.
Your browser caches the field that should no longer be there, then Rails tries to find the old object via the 'id' element in the hash and it fails, rightfully so. Is there anyway I can prevent this? Do I need to just manually inspect the hash to make sure the element is still there? Is there some way I can force a browser refresh or something? Thanks for your time.
Yes and no. Your application has very little control over browser behavior. If the browser sends information to your application that no longer has relevance the best you can do server-side is validate against that and present the user with a clean error message (or silently drop the invalid record ids, but that could be very confusing to the user.)
The alternative is to try and get the browser to stop caching the page in question, you may have seen this before in bank or other sensitive applications where you hit your back button and you're presented with a warning "this page has expired". You could use meta tags or http headers to set the expiry date in the past or use pragma: no-cache.
I have a pretty extensive form on one of my rails sites and I was wondering if its possible to dynamically save the form for every onchange input. What I'm trying to prevent is users taking the time to fill the form out and then lose all their changes because of a connectivity issue or something stupid like that...
Any suggestions? Basically, I don't want the form to have to be submitted at all. I just want the form to save like a preference would in an Mac OS X (no apply or save button it just saves).
using rails 3...thanks!
The strain that would put on your server and DB would be several orders of magnitude higher than a more traditional approach. I also agree with Kyle that I would be very confused about the lack of submit button. At the very least, you'll need to notify users each time data is sent to the server and saved successfully, otherwise they'll have no idea why you aren't asking them to save.
Also, think about all the overhead. With every keystroke the user will have to initiate a connection, send their HTTP headers, cookies, the contents of the form, etc.
Have you considered an autosave feature instead? Maybe save the form every 2 minutes if changes have been made, and then put a submit button on the form as well? I think it would save you a great deal of pain, but get you almost the same benefit.
You could attach an ajax event to each input losing focus that would call the Controllers update method.
Most users would be surprised by this behavior though because it isn't the expected behavior of a web site.
If you use AJAX to call update, then here are a few things that might help: jQuery's serialize() function can help gather the form data into a post request without having to call the forms submit action. Using save(:validate => false) will bypass validation if you are saving drafts and want to skip validation until the final save.
I'm new to mvc so I don't know if there is a trick to this or not. When a user runs a search on a site I'm building and I take them to the results page, if I click the back button the search form is empty. Is there some way to keep the form fields populated as they were when going back (without resorting to session)? Thanks.
Strange.
Fields should be there by default. What browser are you using?
If you're using a regular browser, then maybe your doing something weird, like, resetting the fields via JavaScript or something. Perhaps elaborating more on your current implementation would help diagnosing your problem?
A last solution would be saving the fields as a cookie and loading them via JavaScript on the forms page inside onLoad.
I have made a little app for signing up for an event. User input their data and click "sign me in".
Now sometimes people are double in the database, the exact same data that got inserted 2 times very quickly after each other. This can only mean someone clicked the button twice, which caused two posts to happen.
This is common web problem, as credit card apps and forum apps often say: "Clicking once is enough!".
I guess you could solve it by checking for the exact same data to see if the post is unique, but I wonder if there are other methods.
This ofcourse does not count for ASP.NET webforms, because POST doesn't matter as much.
While JavaScript solutions can disable the submit button after it has been clicked, this will have no effect on those people who have JavaScript disabled. You should always make things work correctly without JavaScript before adding it in, otherwise there's no point as users will still be able to bypass the checks by just disabling JavaScript.
If the page where the form appears is dynamically generated, you can add a hidden field which contains some sort of sequence number, a hash, or anything unique. Then you have some server-side validation that will check if a request with that unique value has already come in. When the user submits the form, the unique value is checked against a list of "used" values. If it exists in the list, it's a dupe request and can be discarded. If it doesn't exist, then add it to the list and process as normal. As long as you make sure the value is unique, this guarantees the same form cannot be submitted twice.
Of course, if the page the form is on is not dynamically generated, then you'll need to do it the hard way on the server-side to check that the same information has not already been submitted.
Most of the answers so far have been client-side. On the server-side, you can generate a hidden field with a GUID when you first produce the form, and then record that GUID as a submitted form when the post is received. Check it before doing any more processing.
Whenever a page is requested from the server , generate a unique requestToken , save it in server side,mark status as NOT Processed and pass it along with the current requested page. Now whenever a page submit happens , get the requestToken from the "POST"ed data and check the status and save the data or take alternate action.
Most of the banking applications use this technique to prevent double "POST"ing.So this is a time proven & reliable way of preventing double submissions.
A user-side solution is to disable the submission button via Javascript after the first click.
It has drawbacks, but I see it often used on e-commerce websites.
But, it won't never replace a real server-side validation.
Client side techniques are useful, but you may want to couple it with some server side techniques.
One way to do this is to include a unique token in the form (e.g. a GUID or similar), so that when you come to process the form you can check to see whether the token has already been used, preventing a double submission.
In your case, if you have a table with event visitors, you might include this token as a column.
A client-only solution won't be enough, as stated in many of the answers here. You need to go with a server-side fail-safe.
An often overlooked reason that disabling the submit button doesn't work is, the user can simply refresh the submit target (and click OK on the "are you sure you want to resubmit the POST data?" dialog). Or even, some browsers may implicitly reload the submitted page when you try to save the page to disk (for example, you're trying to save a hard-copy of an order confirmation).
Almost no one has js disabled.
Think about coding your e-commerce website for the 70 year old woman who double clicks every link and button.
All you want to do is add a javascript to prevent her clicking "Order Now" twice.
Yes - check this at the server side too "be defensive" - but don't code for that case. But for the sake of a better UI do it on the client side too.
Here are some scripts that I found:
//
// prevent double-click on submit
//
jQuery('input[type=submit]').click(function(){
if(jQuery.data(this, 'clicked')){
return false;
}
else{
jQuery.data(this, 'clicked', true);
return true;
}
});
and
// Find ALL <form> tags on your page
$('form').submit(function(){
// On submit disable its submit button
$('input[type=submit]', this).attr('disabled', 'disabled');
});
None of the solutions address a load-balance server.
If you have some load balancer, send a UUID (or any type of unique number) to the server to store and read again will not work well if the server is not aware of other servers, because each request could be processed by a different server in a stateless environment. These servers need to read/write to the same place.
If you have multiple servers you will need to have some shared cache (like a Redis) among the servers to read/write the unique value in the same place (what could be an over-engineering solution, but works).
Client side alteration is a common technique:
Disable submit button
Change the screen to a "please wait" screen
If the form was modal, changing the screen back to their usual process (this has the benefit of making things look really slick)
But it's not perfect. It all relies on JS being available and if that's not the case, without back-end duplication detection, you'll get duplicates still.
So my advice is to develop some sort of detection behind the scenes and then improve your form to stop people with JS being able to double-submit.
You can track the number of times the form's been submitted and compare it to the number of unique visits to the page with the form on it in the session.
Beside the many good techniques already mentioned, another simple server-side method, that has the drawback of requiring a session, is to have a session variable that is switched off on the first submit.