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>
Related
Is there a trusted way to disable the direct access to an special web page? I mean I want to open it only by clicking on a Button for example. I know I can access to the webpage by using this code but It can not prevent accessing to the web page directly (Pasting the url or typing it):
Response.Redirect("~/Code.aspx")
Thanks
This is a long shot because I don't have the time to test this now (I can see some downvotes coming already!), but...
In the "Code.aspx" page, check for Session["allowed"]. If the value is not there, end the response.
Next, make another page (from where Code.aspx can be accessed). In this page, set Session["allowed"] and then do a Server.Transfer() to Code.aspx, which will then run OK.
Finally, at the end of processing Code.aspx., remember to clear the Session["allowed"] variable again.
Hope this makes even vague sense :)
You may be able to write a piece of code on page load that checks the contents of HttpContext.Current.Request.ServerVariables("HTTP_REFERER") - if it's blank, a user has navigated to the page directly and you can handle it that way.
On the source page create a token into a hiddenfield. To your button add PostBackUrl property and let it point to your destination page.
On the destination page you can validate that the request was made from your allowed source page. And you dont need to use session and all its drawback.
Check this Link for detailed information about how to use the mentioned property.
I have a requirement to call a save method, that persists a model/object in the session, when the user leaves the page.
The page has various links that do not raise a postback but just perform a redirect. Are there any ASP.Net page life cycle methods I can hook into to perform the save without requiring a postback?
One solution could be to perform an asynchronous POST request (without waiting for a response) when the window is being unloaded:
An example using jQuery:
$(window).unload(function() {
$.post(location.href, $(document.forms[0]).serialize());
});
Although you will probably need to use a slightly different method for Chrome (found on jQuery forums):
It looks like the only way to get the
Ajax request to go through in Chrome
is to use the non-standard event
onbeforeunload. Chrome evidently
doesn't wait long enough to send the
Ajax request using onunload. It does
however wait for alerts...
Well that depends.
If you need to save values when the person leaves the page, then thats kinda hard.
What you can do, is to wrap all your links in some jquery, that says like:
Issue a Ajax Call, to AjaxSave.aspx, then it is completed, then window.location to the links href attribute.
BUT, that will only work if the person clicks on your links, not if the person just closes the browser or something.
You can also take the route to just save the stuff offen, so every time the person issues a post back, you just put the stuff in session. But that will mean that values changed from the last postback to the navigating away from the page is lost - don't know if that is an issue.
The last thing is to do like StackOverflow is doing. If you are editing stuff, it will show a warning when you leave the page, and then you have to click okay, to navigate away from the site.
Consider the scenario:
I visited a page of a website built using ASP.NET. The page is a simple aspx page containing ASP.NET server controls.
I clicked on a link which takes me to some other page on the same website.
I clicked the BACK button of the browser.
QUESTION: What happens in terms of page life cycle? Does all the events occur or the browser just displays the cached version of the page without making any requests?
I think the best answer is: It depends on the browser, especially after a post/postback.
Older browsers used to pop up a confirmation dialog to the effect of "the page contains POST data which will be resubmitted", and you could either proceed (resubmit) or cancel out. Since everything that happens in ASP.NET WebForms is part of the FORM element (ViewState, events, etc.), this would cause the entire lifecycle to be repeated.
Of course, this caused no end of trouble with duplicate submissions, so many sites had to come up with workarounds for the dupe problem, and today most browsers just fetch the page from cache instead.
...That is unless you override the cache-control headers and force the browser not to store the page in cache. Obviously, in that case, it can't be retrieved from cache, so it will usually end up being resubmitted. But, again, it depends on the browser - for example, some browsers won't allow the resubmission over SSL, so if that's the protocol in use then the user will just see a message saying that the page has expired / can't be shown.
Come to think of it, probably an even better answer is: As a site designer, you really can't depend on any specific behaviour from the user's browser when the Back button is clicked. If a duplicate submission could have negative side-effects (such as charging a credit card twice), then you need to take adequate measures to prevent that from happening. It's good practice anyway as it's entirely possible for a user to simply double-click the "submit" button by accident.
we have even tried
Response.ExpiresAbsolute = DateTime.Parse("1/1/1980");
Response.AddHeader("cache-control", "no-store, must-revalidate, private");
Response.AddHeader("Pragma", "no-cache");
to resolve this kind of problem
The page would be displayed from Cache.
usually all the events should occur, but if you have an uber browser than it could happen to display a cached page
you can just put a breakpoint in your Page Load and see if it's going to occur
There are a few similar questions posted here but none that really addresses my needs.
I have a list of items on one page, lets call it masterlist.aspx. If I click on one these list items another page appears, i.e. details.aspx?id=something.
The page that appears has a formview control in edit mode. If the user wants to edit the data they hit an edit linkbutton and, the form is sent into edit mode, they then edit the data and click the save button, saving the data and putting the formview back in view mode.
The issue is if the user uses the browser back button to go back to the masterlist.aspx page the page is not updated, it's pulled out of the browser cache.
I have played around with the HTTP headers cache settings but can't get anything that works on all major browsers. On some browsers I get web page expired warnings. Another option is to somehow trigger a page refresh (or partial page refresh) when the page loads using client side code, but I haven't been able to figure out how to do this.
Is there any other approach or has anyone been successful with the two approaches above, or is there some way of avoiding the issue completely.
I have to do something like this in a catalog where the browse page needs to be loaded from the DB on every load because when you hit a product page it calls out to a 3rd party to get updated info, and then save it if it should be updated. This is so when you hit the back button like you're saying the data is reloaded. What I've done is added this into the page and it seems to work fine in all browsers.
public class ProductBrowser : Page
{
protected override void OnInit(EventArgs e)
{
Response.Cache.SetCacheability(HttpCacheability.NoCache);
Response.Cache.SetNoStore();
Response.Cache.SetExpires(DateTime.MinValue);
base.OnInit(e);
}
}
What about capturing the Back button keypress event, then instead of allowing it do a browser.history.back(), you can do a document.location(...) call.
Alternatively, you could capture the back event and trigger a post-back, which could do a Response.Redirect("yourpage"). This would force the browser to issue a GET statement for the designated page, and make it refresh
With Javascript a complete solution may not be possible, but there is a workaround.
http://www.boutell.com/newfaq/creating/backbutton.html
It uses a timeout function that repeatedly forces the browser to perform a 'Forward' action. Even if someone clicks the Back button, it'll bring back to the actual page, thereby nullifying the Back operation. It may cause a flicker though.
I have played around with the HTTP headers cache settings but can't get anything that works on all major browsers. On some browsers I get web page expired warnings.
How do you get to that masterlist page? If you issue an HTTP GET and prevent clients and proxies to cache it you'd have no issues navigating back to it (and still getting an updated version).
That leaves you with server side caching (with proper invalidation when any of those items change) or no caching at all.
Is it possible to determine - server-side - whether a page has been loaded within an IFrame?
When certain errors happen in my application the user gets redirected to Default.aspx and an error message is shown. The text of that error message gets set in session by exception handling code. The error message gets cleared from session once it has been shown.
However, part of my application has to use an IFrame (it's doing a 3D Secure card payment check, which mandates an IFrame in order to display the card provider's authentication UI). If an error takes place during this process my redirect takes effect within the IFrame. I am using JavaScript to detect this and reload Default.aspx correctly, but this means that I get two Page_Loads in rapid succession, and the error message only gets shown on the first one (and then cleared).
You can do it in client side: How to identify if a webpage is being loaded inside an iframe or directly into the browser window?
The workaround i found is put some identifier into querystring of a url opened inside iframe.
I don't think you can detect in the sense of having some sort of Page.IsInIFrame() kind of functionality, but you could consider having different base classes for those pages that are loaded in an IFrame and those that aren't so that you can know the error is from a request that was for an IFrame page that may help to some extent.
There's no way from the server-side. The only way is via javascript. When you do the redirect, can you pass the error message or code via a querystring?
Won't it work to redirect using Javascript with window.location? Forcing a full page redirect?
This is impossible because client can open iframe with javascript disabled. http://caniuse.com/#feat=iframe-sandbox
simply, check the url of current page..
if it's the same with the IFrame page then redirect to Default.aspx or whatever.
Dim urlpath1 As String = HttpContext.Current.Request.Url.AbsoluteUri
If Right(urlpath1, 13) = "WebForm1.aspx" Then
Response.Redirect("~/")
Else
Response.Write("It's OK!")
End If