Move backward through history skipping the same page with different query string
The above is similar to my question, but I'll be more specific as mine concerns POSTs:
Scenario:
User is on Product Listing page. (Shorts.aspx)
User picks a product and navigates to product detail page (Best-Cargo-Shorts.aspx)
User clicks add to cart which performs postback (POST) of form to same page. (Best-Cargo-Shorts.aspx) -- this now shows Details page again, but with an Added TO Cart message at the top.
Current Behavior:
After the Add TO Cart form post; when the user clicks the Back button they navigate back to the "pre-post" version of the same page.
Desire:
When a user clicks the BACK button, I'd like it to go to Shorts.aspx, NOT Best-Cargo-Shorts.aspx, effectively Skipping the "pre-POST" page, or more accurately NOT STORING the 2nd POSTed page (Best-Cargo-Shorts.aspx).
Furthermore, I always want to avoid that "Page Content Expired" message. I just never want the POSTed version of the page in history. In this way, the following could also be true.
Shorts.aspx > Best-Cargo-Shorts.aspx > Best-Cargo-Shorts.aspx [POST] > Cart.aspx
If on cart and BACK button is pressed, I want the browser to navigate to Best-Cargo-Shorts.aspx (without the POST).
Is this possible with C#? Furthermore, is there a non-javascript solution?
Thanks.
One common way of handling this is the Post-Redirect-Get pattern.
In essence, the target of a POST request always responds with a 303 See Other (if HTTP 1.1) or 302 Moved Temporarily (if HTTP 1.0) status code redirecting the request as a GET, and usually eliminating the expired POST page from history. Potential downsides include the form parameters possibly remaining attached to the GET as a query string, and I've no clue how well it would (or wouldn't) integrate with ASP.Net Forms, MVC, or other web frameworks.
Generally, you should be using the post-redirect-get pattern, i.e. after the user adds the item to the card using POST, redirect him to Best-Cargo-Shorts.aspx with 302.
Now to your question, I would use Ajax for the post. I cannot think of a cross-browser way to achieve the desired behaviour using only server side code.
Related
I am using the Post Get Redirect method to submit a form using asp.net webforms. It's a very simple setup:
Step 1) Post form on Page1.aspx
Step 2) Process form and redirect using Response.Redirect to Page2.aspx
Step 3) Page2.aspx redirects using Response.Redirect to Page3.aspx
If you are on Page3.aspx and hit the back button, I think it should take you back to Page2.aspx and redirect you right back to Page3.aspx. This would lessen the chance of you getting back to Page1.aspx and submitting the data again.
Instead, I am being taken straight back to Page1.aspx when I hit the back button. I have also tried using a 303 Redirect, but that did not work either.
What could be going on here?
The behavior you are seeing is the right thing to do.
Various browsers, to better support how some sites (like google) operate don't keep a page that redirects immediately in the back history.
Consider this:
You search google.com
You click on a link
This link actually takes you back to google.coms servers before immediately forwarding you to the actual page.
You decide that wasn't the right link and click the back button.
At this point, most browsers will take you back to the page identified on step 2. This is the normally desired and expected behavior of millions of netizens.
To go back to step 3 only to be forwarded on to step 4 would, well, piss some people off. As certain versions of IE recently did until the behavior was patched.
Point is, the behavior you are seeing is exactly how the rest of the web works. You should look into some other mechanism to change this, if you really really want to.
update
#NinjaBomb: Somehow I missed your follow up question, so the following is probably not much use.
The answer is that instead of doing the redirect in c# code you embed some javascript in Page2 that does the redirect when the page load is complete. The browser then "stores" the reference to page 2. When they click the back button from 3 it will go back to 2 then redirect on to 3.
Of course, the user could simply hit the back button twice...interrupting 2's redirect and letting them go to 1. The only other way I can think of is to have page 1, on load, test some session or cookie value to see if they've already been sent on. If so, then page 1 should do a redirect instead of showing itself.
I have a set of interlinked dynamic web pages.
When the user clicks from one page to another, I don't want any caching to happen - the request must go to the server, which will return an up-to-date page.
But when user clicks Back, I do want the cache to be used - some of the pages can take some time to generate, which is fine when you're clicking through to them, but not when you're clicking Back.
Is this possible?
(Please don't suggest re-engineering everything as a single page making AJAX queries!)
(Note: this question is the opposite of the ever-popular "How do I prevent caching when the user clicks Back?" question.)
A common trick for avoiding the browser cache when dealing with dynamic pages is to add a parameter to the link url that is unique (using the time, to the millisecond is common).
When the user hits the 'back' button, they will go back to the last rendered version, and should get it from the cache.
I want to redirect the user to another page to fill out a captcha but i would like to keep the post data, and if the captcha pass to send it 'back' and complete the previous page action.
When/if the user succeeds i like to add an captchaPass=true and would like access the post data and continue processing. Right now i am using redirects but ATM i am not required to use it.
Is it possible to carry the post data? keep in mind i may the user access multiple pages so separating data and not having a mixup is necessary.
One idea is to get and save all posted data [1] on the captcha page, and then recreate a middle white page with this form data and automatically make a new post to the previous page.
Can this work with out any issues with hash checks and security ?
Is there a better idea with out this white redirect page ?
[1] One other issue here, how to send this posted data with the redirect ? and not change the url - or make it too big to accept it. Keep in mine that a server transfer may not good idea because is complicate the thinks on captach post back.
Update 1
The basic idea here is how some one capture the full post back of a page, show a different one page and then send the post back data to the original first one.
The reason is to stop a bad user, or an attacker bot program that try to bring down the pages/server by making many post back from different pages in short time. All that happens with out javascript, and most attackers use custom made programs that just make post of data to all page together try to bring down the system.
For example, if a page have a search box, is very easy for most of the the site to bring them down by start making hundred of random search with wildcard (called and Dos Attacks using SQL wildcards) and make the sql server and the computer spend his time and cpu to search and search thinks. So to prevent an attack like this you need to recognize multiple post backs from the same computer, and then the next step is to redirect him to a captcha page to block him out in case that is a computer program.
Other example, many page have email submit, very easy you can submit hundred times the email of his and full his mail box in no time with hundred of emails, or on a store to place all items on the cart again and again and full the database with stuff like that.
So ajax and javascript is not working in this case, and we need a way to redirect him after the post back to a page that can check if is a real user or an attacker and stop him - but if is a real user must return back to his normal action.
Update 2
This all must be done in a general way, eg on BasePage, or on Global.asax or somewhere that is independed from the content of any page. Because we try to prevent a DoS attack, or multiple submit anywhere on any random place of any random page.
Yes I know how you can place a captcha on the contact page, but this is not what this question was first asked for - this questions asked how can carry post data to one different page, keep them there and then resend them back to the original one.
The obvious solution is to read all post back, and save them on the form, and then read them back and make on fly a form only with that data and make the post back. Here I am asking if there are any other better than this solution.
Other Applications
There is also the case that a user is inside a page that request authentication, but the authentication ticket has expired, and the user make post back. In this case we need to keep somewhere all the posted back data, to proceed with the login page, and resend them back to the first page that request the authentication.
Sure, just write the form data out to the captcha page in hidden elements with the additional captcha fields added to the form. Have your submit action post the whole thing back to the original. Using ASP.NET it's probably easier to have the captcha written to the same page with the form fields hidden, but you can do cross-page postbacks as I've described above.
Cross Page Posting might help you.
Why not implement the CAPTCHA with AJAX? Load the captcha object and form with Javascript in a div perhaps displayed lightbox style, accept the user input and post it to your server for validation, hence continue with the users post request or keep them there until they get it right (or cancel).
A more specific situation example:
Give the form submittal button an onClientClick value of some Javascript function. This function decides if this particular form needs a CAPTCHA. If it does it loads an interface for taking the CAPTCHA (which you'd need to do with some server-side code) and inserts the CAPTCHA's input element to the form that the user clicked to submit.
Once the user has entered the CAPTCHA input and clicks some button whose click event is bound to return to your first JS function, the Javascript intercepts this action and posts the full form, all the data from the original form and the CAPTCHA for validation. Your server script can now process all this at once!
This is the best solution I can think of that works similar to how you've asked, but I can't imagine why you want to perform the CAPTCHA on a different page.
Server.Transfer with MultiViews, Panels like control is fine with you? In this way, no need to bother about the Data Maintenance and Postbacks. You can do the validations in javascript.
You can keep both functionality in the same page to avoid moving data from one page to another page/Bring the data back to original page. You can utilize Session for this intermediate operation. Set it back to associated controls across Postback. You can create a class, Instantiate it and Initialize the control values in this class object. Save class object in Session. On Postback, You can reassign the values to the associated controls. This will definitely keep the things simple and without much complexity.
Doubts ?
I have an have an ASP.Net page which contains a button. This Page contains a ServerSide Paypal button.
When pushed my server does various clever things on the back end and then rewrites the response as a form and some javascript which posts this form to paypal..
This all works great.
However, if the user then elects to click back, they will arrive at my generated self-posting form and that will forward them again to Paypal.
I thought if I could find a way to have my generated form page not exist in the history, then this will solve my problem. but I have no idea how to correct this.
How can I remove my page from the history or just have it never appear?
Update: Thanks to all... Those are some great answers. Upvoted all good ones but went with splattne on account of clever use of hidden field rather than cookies for basis of decision.
window.location.replace(URL);
window.location:
replace(url)
Replace the current document with the
one at the provided URL. The
difference from the assign() method is
that after using replace() the current
page will not be saved in session
history, meaning the user won't be
able to use the Back button to
navigate to it.
I'm not sure if that can be done. But here is an idea how you could prevent that resubmit of the form.
You could insert a hidden input in your form which at the beginning would be empty. On submit you'll write a value in that field and make sure you check on every submit attempt if this field is empty.
If it is not empty on submit you know that the form was previously sent and you could warn the user.
As a web application, you'll never have full control of the user's browser. Even if there was a way to instruct the browser to not store the page in history, which I doubt, you can't be sure it'll work. For example, a clever user could tweak an open-source browser to store every page in history, no matter what.
I think you should try to approach the problem from another angle. You could, for example, detect that it's the same form which is being forwarded and not send it to paypal the second time. The important thing is to do it server-side.
Perhaps you could set a cookie before submitting the form.
When the page is loaded, check for the existence of that cookie (meaning the form was already submitted). If found, instead of automatically submitting the form, automatically go back (window.history.back()) again.
I'm not sure if you can do this easily with PayPal integration, but the
"Post / Redirect / Get" pattern can be used to address this problem
A useful Hint for some might be this...
window.history.go(-2);
particularly in the advent of a load failure warning popup.
You could simply programme your page not to submit, or to do something / navigate somewhere else, if window.referer is the Paypal page you are trying to avoid invoking a second time.
protected void Page_Load(object sender, EventArgs e)
{
Page.RegisterClientScriptBlock("", "<script>if(history.length>0)history.go(+1);</script>");
}
I have an asp.net application that runs exclusively on IE7 (internal web site).
When a user needs to enter data, I pop up a child window with a form. When the form closes, it calls javascript:window.opener.location.reload(true) so that the new data will display on the main page.
The problem is that the browser complains that it must repost the page. Is there any way to turn this feature off?
No, but there is a solution. Its generally considered good design to use a 302 redirect immediately after someone posts data to a page. This prevents that popup from ever occuring. Allow me to elaborate.
1) The user fills in a form and submits data via POST.
2) The backend receives the data and acts upon it.
3) Instead of returning the content to the user, the backend issues a 302 redirect as soon as its done processing the page (possibly redirecting the user back to the exact same url, if need be)
4) The page that the user will see is the page you told their browser to redirect to. They will load up the redirected page with a standard GET request. If they try to refresh the page, it will not repost the data. Problem solved.
This is a problem with the usual "postback" way of ASP.NET. If you need to reload a page without this warning, this page must come from a GET, not a POST. You could do a Response.Redirect("...") yourself. But this will destroy the use of viewstate.
asp.net mvc fixes this issue, not an ie7 only problem but a security feature of most browsers. No fix that I know of except you could just update the content in the main form with js rather than reloading the whole page
It's because the page in window.opener comes from a POST Request
Maybe you can use
javascript:window.opener.location = window.opener.location; to do just a GET request if the data can be fetched without a POST.
I do not believe that there is a way to do that. Instead, why not direct the parent window to a page without a reload.
javascript:window.opener.location='your url'
AFAIK, not via your scripts.
You might try:
window.opener.location = '#';
It should circumvent the browser reposting. And, you can adjust the hash name as needed.
If you move from page1 to page2, and want to disable the browser from going back to page 1,then add the following at the top of page1.
<script>
if(window.history.forward(1) != null)
window.history.forward(1);
</script>