How can I set an ASP.Net web page to expire so that if the user clicks the submit button, he/she will get a page expired error if the browser's back button is pushed to try to go back and press submit again?
Use HttpResponse.Cache to control the cacheability of the page. This gives you control over options such the expiration of the page from the cache and the Cache-Control HTTP headers.
First off, use the Post-Redirect-Get pattern when the user submits the form. This will prevent them from being able to use the back button easily. To do this, all you really need to do is issue a Response.Redirect() call after you finish processing the form, even if it's to the same URL.
Secondly, you could consider using a unique id field in the form that is tied to the submission process, so that if the submission is completed, the same id cannot be used again. The suitability of this would depend on what you're doing though.
From what I understand, there are two parts to your question:
1 - Stopping the browser back button - it does not work & me-thinks that we should never stop the user from pressing back. So, perhaps you could use META tag to expire the content so that the user see a "content expired" page & has to reload to get the latest content
2 - Stop multiple POST - by definition, POST is not indempotent ie. multiple POST operations should be possible.
A possible mechanism is to disable the POST/SUBMIT button after the first post has completed. So, the user will not be able to do it the second time.
HTH.
Related
I have a web form with a detail and a list view on it, the user fills the data in the fields of the detail view and then presses the "save" button, and everything is ok for the moment.
However, if they press F5 after this operation a new record is going to be inserted in the DB, because the postback is repeated.
Does anybody knows how this could be avoided?
This will be the same for any webpage that uses a POST request for its operations.
You could stop this by using Response.Redirect("yourpage.aspx") after your save button event. This will send them to a fresh version of your page without post data in it.
Another way of doing it would be for your form to include some sort of autheticity token, such as a generated GUID. You could do some checking before processing the save request that a request using that GUID has not been issued before.
I have a webforms site that has 2 menus.
On a page you click a button, has some c# events fired by a webservice (ajax) then redirects you to another page with history.go(-1). The only problem is that in the webservice I create a sesion that makes the menus switch, the default one hides and the other one shows. The menu switch in done in the Page_Load of the Master page.
My problem is that with history.go(-1) you get to the previous page, but the old menu is present instead of the new one. How can I fix it?
the problem is that the browser is not actually loading the previous page it is using the cached page. is there a reason you can not have both menus hidden and then decide what one to show client side? this way you can let the JS .ready take care of what menu to show and then you should get the desired results when using the history.go(-1).
This artical speakes to setting cookie from the server then checking in on the client.
you could use something like this and then check the cookie to determine if the page was loaded from cache and then force a postback.
location.reload()
My fix was to add in a session the previos link, and when I need a redirect w/ cache I redirect to another aspx page, that redirects depengind on the url params where I need it to go... it was the simpler method I could thing of...
I have an ASP.NET form that the user can make lots of changes to, each time they make a change the page PostsBack and the details are updated.
If the user hits the browser back button they go back through all the previous versions of the page.
Is it possible to stop each PostBack being treated by the browser as a new page?
So the would make any changes they like and if they hit the back button it brings them to the previous form and not the same form but a different version?
I know I could use AJAX to update values but I'm not an advanced coder so trying to keep things simple as I haven't used AJAX before.
Ajax is your only solution.
There is no way to remove a page from the browser history. Javascript is explicitly denied the capability.
Now, you could, potentially, stop them from using the back button at all. Although this might result in unhappy users and I'm not 100% certain it works in all browsers.
function body_onload(){
window.history.forward(1);
}
You could use a trick to do it.
On postback you can set a session bit to true saying they submitted that form. On your postback check to see if that value is set. If it is they are trying to do it again and you can just abort it. It wouldn't prevent the postback per se but you could control the logic and prevent it from DOING anything.
I personally would explore ajax as Jquery provides some nice ways to do it and it'd be a learning experience but I suppose this would work as you are asking. On a per session basis. If you only want 1 submission ever use a database to store the activity.
You could use UpdatePanel: http://msdn.microsoft.com/en-us/library/bb386454.aspx
On my two-page web application, users progressively enter info and make selections on page one. When done, they click a 'Generate' button that navigates to page two. Users print that page and hit the browser's Back arrow to return to page one with selections intact.
After a few generated pages (2 or 3), clicking Back just disables the icon without going back. They have to manually revisit page one, reentering their info and selections.
I found that the down arrow to the right of to the Back / Forward arrows (IE8) that shows the immediate history generally includes all 'previous' pages. But when the back button is about to disable on click, the history only shows the current site.
What events, scripts, headers, etc. clear the history for the current site? It occurs in IE7 and IE8 on WinXP and Win7. In FireFox, the button did not disable, but it did not do anything either. Users report it as a recent and I have been making changes to the application, but it only affects the HTML on page two (not scripts, though). It's probably a code issue if it's recent, but I'm not sure what to look for when double checking my recent changes.
Which version of IE?
Internally, IE maintains a limited amount of data in the travellog (aka back/forward stack). ASP.NET pages with huge postback forms often blow this limit, wiping the history stack.
In IE6 and IE7, if there is a form input field with a value longer than 523,659 characters, when you navigate away from the page, IE may clear the current session's travellog (similar to history), disabling the back and forward buttons.
I believe the overall Travellog size limit was upped somewhat in IE8, but it's not more than a few megabytes.
As a general rule, if you want your users to navigate back and forth between pages, I would give them links on the page that do the job (without using javascript:back()) instead of using the browser's navigation.
What's happening, most likely, is that the postbacks of a single page are sometimes considered pages, sometimes not. If a user action loads a page that has the same URI and query string, most browsers consider that "the same page" even though EVERYTHING may have changed. This is usually due to heavy use of MultiViews with the information about the current view kept in ViewState or Session; navigating within that page doesn't change the URI being navigated to, so the browser doesn't log each new load as unique.
If you really need proper back-and-forth functionality, you will need to make sure that every link will result in the browser being told to navigate to a different URI than the current page. You can do this by adding a query string element that will be present in every link to a different page or view, that will auto-increment with each click the user takes. This gives the browser a different URI every time. You only use the existing QueryString element to create the new one on your links' URIs. This can get cumbersome, and the easier solution is simply to provide in-page navigation and tell your users not to hit "Back" any more.
I have a page with a few fields and a runtime-generated image on it. The contents of this page are inside an UpdatePanel. There is a button to take the user to a secondary page, which has a button that calls javascript:history.go(-1) when clicked.
The problem is, the first page does a full request instead of a postback or just using the state it was in before navigating away from it. That is, the fields are all reset to their default values, thereby confusing the user. I'd like their values to be retained regardless of navigation. I do not want to create a new history state for every field change.
Any ideas?
The only other option would be to track the field state in a client side cookie using JavaScript (which has limitations). It would be best to have an AJAX call that was executed prior to navigation to your secondary page that would allow the server to save the state of the page so that when your reverse navigation occurred you could properly render that state to the browser.
I think I'll try the AJAX idea when I have a little more time to work on it. I'll probably just send back the viewstate field :P Thanks for the input.