I have a very strict requirement to use POST to pass in request parameters to my application upon entry. Once entering the application (page1), entering form information and continuing to the next page (page2) via a commandButton, the expectation is that the data will be posted and later read from a session scoped manage bean. All works well except when using browser back on page2 to navigate back to page1.
I have tried adding a redirect tag on the navigation rule that navigates from page1 to page2 to no avail. I have also tried this implementation of the Post-Get-Redirect pattern (http://balusc.blogspot.com/2007/03/post-redirect-get-pattern.html). Am I missing something obvious here?
Abel, the scope of page1 is request.
The solution we came up with which is no means ideal is to disable browser caching on the previous page. What this means is that whenever you refresh the page using the browser refresh button or click the browser back button, the browser will indicate that the page is expired and prompt a warning asking whether you want to re-submit the request.
We do have a work around which is to provide navigation buttons within the webpage but the idea was to support browser back. This would be easy using GET parameters, but POST provides additional complexity which we have decided to mitigate by by providing our in-house navigation buttons.
Related
The question is probably easily misunderstood, so I'll go into more detail:
I am trying to automate a task in a certain (very outdated) browser-based idle game that is written in PHP in order to polish my portfolio with a little more variated projects.
I used DevTools to reverse most of the requests and wrote a small C# Request wrapper to test them. I can get most of the actions I want to work, using the respective ajax get requests and the correct cookies/headers - not really part of the problem.
Example:
Attacking an enemy:
https://somebrowsergame.com/game/ajax.php?mod=location&submod=attack&location=3&stage=2&premium=0&sh=****mysessionhash****
Making a GET request to this URI with the correct headers and cookies, I can perform the in-game action programmatically and successfully from my C# console application and see that the fight has taken place when visiting the site in the browser.
The problem:
When monitoring all requests after clicking the "attack" button, via DevTools, even with preserve logs enabled, I don't see any redirects or way of determining how my browser gets told where to navigate to.
Findings
I found out that the button calls a javascript function attack() in its onClick event and tried debugging the javascript in DevTools in order to find out where somethign happens (such as setting document.href or smth), but when Debugging I ran into a seemingly infinite loop of setInterval handler and setTimeout handler in the call stack.
I also cleared the Network tab after the onClick event (and after the ajax request which I could find during Debugging) but the only request/response I got was the document GET request for the final page, no request telling my browser which site to navigate to.
Monitoring requests
The request made to initiate the action (via button click on website or ajax GET request as outlined above)
The document response / site navigated to
What I want to know is how my browser got told which site to navigate too, as the request URI for the document request (getting the html of the target page) has a parameter generated on the server side (logId)
I have also used "All" request types in DevTools, as well as negative filters when monitoring requests but never was I able to see how my browser knows which page to navigate to. I tried with source breakpoints at "beforeunload", tried inspecting the javascript source connected to the onclick event of the button (which didnt give me anything, as the js is minified and barely readable - i am not even sure if the navigation is done via window.target.href) and googled this question in all possible wordings which lead me nowhere
I am not too versed in web development, but I am sure my browser has to be told where to navigate to in some fashion after clicking that button?
I have a contact addition form that can be navigated to from multiple screens in our application.
Once the form is submitted, I then take the user to a screen to view the contact that was added.
When the user then makes use of the back button it should take them back to the screen that they originated from.
This might be the Android back button or one that calls the RouterExtensions back function.
I have made use of the navigate extra replaceUrl when navigating away from the form to the view page.
I have also tried using the skipLocationChange extra when navigating to the form but this creates more issues.
I have created a simple playground page flow that creates not quite the same issue but does throw an error that I don't know what to do with either:
https://play.nativescript.org/?template=play-ng&id=BfVcGZ&v=2
In our app, by making use of the replaceUrl extra, the back button does take the user to the correct page.
However, there is a brief moment where they see the form again. This isn't an ideal user experience.
In the linked Playground I do get an error:
Cannot reattach ActivatedRouteSnapshot created from a different route.
This seems to tell me that replaceUrl is indeed removing the page from the route table.
However, the page isn't destroyed yet and so the app is trying to show a page that it shouldn't.
replaceUrl is not yet supported by Page Router Outlet, there is an open feature request, you might want to register your vote on the feature and follow up there for further updates.
I'm working on a web application developed classic asp. It has logout button on the top menu which basically does the following actions
Session.Abandon()
Redirect to Index.asp, where users can login again.
After logging off users return to index.asp. But if users click back button the browser, they go to previous page. I don't want this to happen. I want a message saying that they are already logged off.I have implemented following steps
1.Add Response.Expires=-1 and Response.CacheControl="no-cache" at the top of each page.
2.On each page i'm checking session object to see it is not empty. If empty i'm creating a message saying that they are already logged off and need to log in again.
Now when users click back button after logging off, instead off showing logged out message, i get "Web page expired" message on IE8. I see the same behavior when users click back button on some page while logged in.
Any ideas how i can implement this better.
Thanks.
You can't stop users pressing back. A common scenario to work around this is that POSTs target a server page that displays no output but redirects to a new location instead (where the results can be seen).
There are additional non caching declarations that sometimes help:
Response.Expires = 0
Response.AddHeader "pragma","no-cache"
Response.AddHeader "cache-control","private"
Response.CacheControl = "no-cache"
I did read some time ago (hence inability to find link) that setting an expires to -1 can cause some browser to ignore it rather than have it expire immediately.
Even adding these extra cache controls won't stop some browsers from caching some things some of the time. FF quite often ignores a forced cache reload by the user, so you are in the browser makes hands to a certain extent.
Regarding your "Web page expired" message, this is (as mentioned) the result of the browser trying to stop you from resubmitting POST data (and potentially duplicating what you last did). The best way to get around this, and solve a number of other common UI issues on forms is to POST back to the same page, then if/when the action is completed, using a response.redirect to the same page, maybe with a URL encoded message to say "all done successfully". This allows your users to refresh and helps with the back button issue as most browsers now don't store properly redirected pages in their history.
I am implementing a web application using ASP .Net and C#. One of the pages has a requirement that it always needs to be fetched from the server, rather than from the local browser cache. I have been able to achieve this.
We have a back button in the application, which simply invokes javascript:history.back() method. The problem is that when the back button is clicked to navigate to the page which is always to be reloaded from the server, the browser displays a "Web page expired message".
The intent here is to force the browser to reload the page rather than display the web page expired message.
Any help would be highly appreciated. Thanks a ton in advance.
You will probably need to change the implementation to make the browser load the URL explicitly:
window.location.href = 'http://....';
instead of invoking the back button, since the intention of the back button is to get the last page from the cache.
(If browsers would not act that way, they would re-send your form data multiple times when using the back button during a registration process or similar.)
You mean you want to control browser behaviour, which is not possible. I doubt you can solve it that way. You could set the expiration time to a small value (1 minute perhaps?) so that the page is still valid if one navigates back quickly.
Greetings,
Here's the problem I'm having. I have a page which redirects directly to another page the first time it is visited. If the user clicks 'back', though, the page behaves differently and instead displays content (tracking session IDs to make sure this is the second time the page has been loaded). To do this, I tell the user's browser to disable caching for the relevant page.
This works well in IE7, but Firefox 3 won't let me click 'back' to a page that resulted in a redirect. I assume it does this to prevent the typical back-->redirect again loop that frustrates so many users. Any ideas for how I may override this behavior?
Alexey
EDIT: The page which we redirect to is an external site over which we have no control. Server-side redirects won't work because this wouldn't generate a 'back' button for in the browser.
To quote:
Some people in the thread are talking about server-side redirect, and redirect headers (same thing)... keep in mind that we need client-side redirection which can be done in two ways:
a) A META header - Not recommended, and has some problems
b) Javascript, which can be done in at least three ways ("location", "location.href" and "location.replace()")
The server side redirect won't and shouldn't activate the back button, and can't display the typical "You'll be redirected now" page... so it's no good (it's what we're doing at the moment, actually.. where you're immediately redirected to the "lucky" page).
I think the Mozilla team takes a step into the right direction by breaking this particularly annoying pattern. Finding a way around it somehow defies the purpose, doesn't it?
Instead of redirecting on first encounter, you could simply make your page render differently when a user hits it the first time. Should be easy enough on the server side, since you already have the code that is able to make that distinction.
You can get around this by creating an iframe and saving the state of the page in a form field in the iframe before doing the redirect. All browsers save the form fields of an iframe.
This page has a really good description of how to get it working. This is the same technique google maps uses when you click on map search results.
I'm strongly in favor for the Firefox behaviour.
The most basic way to redirect is to let the server send HTTP status code 302 + Location header back to the client. This way the client (typically a browser) will not place the request URI into its history, but just resend the same request to the advocated URI.
Now it seems that Firefox started to apply the bevaviour also for server responses that try redirections e.g. by Javascript's onload event.
If you want the browser not to display a page, I think the best solution is if the server does not send the page in the first place.
Its possibly in aide to eliminate repeated actions.
A lot of ways people do things is
page 1 -> [Action] -> page 2 -> redirect to page 2 without the action parameters.
Now if you were permitted to click the back button in this situation and visit the page without the redirect, the action would be blindly re-performed.
Instead, firefox presumes the server sent a redirect header for a good reason.
Although it is noted, that you can however have content delivered after the redirect header, sending a redirect header ( at least in php ) doesn't terminate execution, so in theory, if you were to ingnore the redirect request you would get the page doing weird stuff.
( I circumvent this by the fact all our redirects are done via the same function call, where i call an explicit terminate directly after the redirect, because people when coding assume this is how it behaves )
In the URL window of firefox type about:config
Change this setting in firefox
browser.sessionstore.postdata
Change from a 0 to 1