The browser back button is not working well with our web page - and a control we purchased for doing uploads (which uses ajax and silverlight).
How do you all deal with this? We want to not allow the BACK button...
Printable View
The browser back button is not working well with our web page - and a control we purchased for doing uploads (which uses ajax and silverlight).
How do you all deal with this? We want to not allow the BACK button...
The short answer is you don't.
The long answer is that you should never have to ask the question "How do I disable the back button?" because simply, you can't. Instead, you work your application around the problem you have. The most common reason to want this is data being resubmitted and code being re-executed.
So obviously, different ways to deal with it.
1) Disable caching on the vulnerable page so that it's always reloaded from server.
2) If it's a data resubmission problem, introduce an intermediary page which then again does a redirect to the target page. So, example
upload.aspx -> pleasewait.aspx -> complete.aspx
Pressing back on complete.aspx will only take them to pleasewait which pushes them again to complete.aspx.
Hey,
Silverlight navigation has got known issues with the back button. Simply put, it doesn't work out of the box.
Telerik have implemented one solution, but that would require a license with them.
Gary
I am going to tell the client this.
We had a web consultant coding this page for 3 weeks and he did some research into why BACK was causing issues. Apparently you can use the SCRIPT MANAGER to handle saving session state for hitting the back button (we stay on the same page and each post back changes session variables controlling the STAGE of entry the user has reached).
We are using a ajax/silverlight upload control. Seems the silverlight part of the upload is what allows you to upload multiple files on the same "file dialog" popup.
And seems silverlight and the script manager don't work well with BACK.
Seems there is some other script history downloads he found - but his last way was yesterday. He's on a permanent job assignment starting Monday...
The intermediate page would make sense then. I think it'd be easier than having to hack the existing JS?
If you have a session that indicates what step the user is on can't this be used to test if the user repeated the step (clicked back) and therefore reset the page for the step required? Is it a known bug your dealing with as Gary aluded to?
What I usually do is Response.Redirect("samepage.aspx") as the last line of executing code to clear the headers. But unfortunately this requires an extra round-trip to the server.
e.g. if button is clicked, then I do:
Code:Protected Sub Button1_Click(ByVal sender As Object, ByVal e As System.EventArgs) Handles Button1.Click
' do whatever processing you need to do. like insert record into database etc.
' then finally redirect to same page.
Response.Redirect(Me.AppRelativeVirtualPath)
End Sub
Could you please explain this a bit more?Quote:
Originally Posted by Pradeep1210
Also - doesn't the PAGE_LOAD event fire anyway - so you basically get it right now and after the REDIRECT.
How do you tell the difference in the PAGE_LOAD which way you came in??
Yes that's what I meant by an extra roundtrip to server. The page is loaded twice. First time the actual postback from client. Second time the call from Response.Redirect. Second time it will process it like a fresh (new) page request. i.e. first time IsPostback is true, second time it would be false.Quote:
Originally Posted by szlamany
Response.Redirect causes the browser to request the same page. But is it a fresh request. So if you press Back, Forward or Refresh, it won't cause it to popup that ugly dialog from the browser asking you to submit the data again.
So I also find this technique good when you don't want client to be able to submit same data again (after cliking refresh button etc.)