I have been trying for a while to find a method to prevent the the browser from using cached data while the user is logged out. I am trying to force the browser to use the information from the database once the user is logged out instead. This will prevent the back button from exposing information on previously visited pages from being shown. I have used the PHP destroy session. I do not have a clue how to work with REST API.
Well, the REST API doesn't have anything to do with the frontend, but there are ways you can force the frontend page to reload on the back button being pressed.
Here is a similar question.
Essentially, you need to store some local storage data that get's checks on page load and force the page to refresh.
Page One
<script>
if (sessionStorage.getItem("Page2Visited")) {
sessionStorage.removeItem("Page2Visited");
window.location.reload(true); // force refresh page1
}
</script>
Page Two
<script>
sessionStorage.setItem("Page2Visited", "True");
</script>
Now, this isn't full-proof. If a user has javascript turned off or has some other block or something in there, it won't work. Companies do not allow sites to control a users browser. And for very good reason. But something like this can be a partial solution for the majority of users.
Related
I am trying to implement Login/Logout functionality in my website without using inbuilt functionality of Login controls in ASP.NET. In some pages, which require the user to be logged in, I have written this in Page_Load
if (Session["cod"] == null && Session["admin"] == null)
{
Response.Redirect("You need to Login.aspx");
}
if (Session["cod"] != null || Session["admin"] != null)
{
LinkButton1.Text = "Logout";
}
if (Page.IsPostBack == false)
{
log_bind();
grid1_bind();
grid2_bind();
}
But while I was testing this, I noticed that when I press the Back/Forward button on the browser, these pages are viewable without being logged in. How do I prevent this?
This has nothing to do with the login controls, but as others state, the caching of the page.
The trick is to tell the browser that it can't cache the page.
Look at this post, and its solution:
Disable browser cache for entire ASP.NET website
I think that even if you do not use ASP.NET login controls you should still use the Principal/Identity classes and verify if a user is Authenticated or not. That is surely the safest way.
I don't know of any reliable way to do this. Once a page has been viewed, it's on the user's computer. If they hit the back button, they are looking at a cached version anyway so I can't imagine why this would be an issue.
As long as they can't refresh the page to get the latest content, what does it matter if they're able to look at a page they already accessed?
Have you tried wrapping the whole function in
if (!IsPostBack)
{
}
The browser may simply be showing you a cached version of the page, try to attach a debugger to the page load event and check to see if:
It is actually hitting the server when you hit back and forward
The values in the session state, whether they are consistent with a logged out user.
If the values in the session are consistent with a logged in user then you have to check your session clearing logic.
It is however best to use the asp.net controls or the system.web.security.FormsAuthentication class to perform functions like logging in and logging out based on custom logic.
I am developing a page whereby users can login and demo some pieces of functionality. I only want to allow the user to demo this once per day.
A small example:
I have a web page with 3 buttons (relating to 3 different scenarios). On page load, I look up the database and check if the current logged in user has run any one of the 3 scenarios available (via an audit table). Each button is enabled/disabled based on the results. If any buttons are enabled, then they have not run that demo yet. By clicking the relative button, the demo runs a record is written into the Audit Table, and the button is disabled.
This was working ok, however, I realised that when I refresh the page (and confirm I want to re-submit the information) the demo runs again.
How can I stop this from happening? I need to only allow the user to run the demo once!
Thanks.
I would suggest that you change your form submission to use the Post/Redirect/Get pattern to avoid a resubmission if they hit refresh on the demo page.
Also, it seems like you should just be able to change the code at the point where it writes the record into the audit table to check to see if the record already exists, and if so, return a different result. I'd be pretty wary about this approach though. The "refresh" functionality of the browser isn't generally something you should be trying to prevent. What happens if a user hits "refresh" in the middle of their demo?
you can check not only on the page load to enable/disable the buttons, but on the button events, you can verify if that task has already been performed
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.
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>
In our CMS, we have a place in which we enable users to play around with their site hierarchy - move pages around, add and remove pages, etc.
We use drag & drop to implement moving pages around.
Each move has to saved in th DB, and exported to many HTML files. If we do that in every move, it will slow down the users. Therefore we thought that it's preferable to let the users play around as much as they want, saving each change to the DB, but only when they leave the page - to export their changes to the HTML files.
We thought of making the user click a "publish" button when they're ready to commit their changes, but we're afraid users won't remember to do that, because from their stand point once they've moved a page to a new place - the action is done. Another problem with the button is that it's inconsistent with the behavior of the other parts of the site (for example, when a user moves a text inside a page, the changes are saved automatically, as there is only 1 HTML file to update)
So how can we automatically save user changes on leaving the page?
You should warn the user when he leaves the page with javascript.
From http://www.siafoo.net/article/67:
Modern browsers have an event called window.beforeunload that is fired right when any event occurs that would cause the page to unload. This includes clicking on a link, submitting a form, or closing the tab or window.
Visit this page for a sample the works in most browsers:
http://www.webreference.com/dhtml/diner/beforeunload/bunload4.html
I think it's bad practice to save the page without asking the user first, thats not how normal web pages work.
Sample:
<SCRIPT LANGUAGE="JavaScript1.2" TYPE="text/javascript">
<!--
function unloadMess(){
mess = "Wait! You haven't finished."
return mess;
}
function setBunload(on){
window.onbeforeunload = (on) ? unloadMess : null;
}
setBunload(true);
//-->
</SCRIPT>
The easiest way I can think of is to store the page info each time the user moves items around using Ajax (e.g. with an UpdatePanel, onUpdated event, let it fire some script that updates the users page config.
Alternatively - .Net's WebParts implementation does this automatically without intervention by the programmer (unless you want to change the storage engine, it uses a local mdb in by default.
Use a "Publish" checkbox/button and when the user interacts with the page in a way that causes them to navigate away ask them if they want to publish if that box is NOT checked/button not clicked. Be aware that there are actions (closing the browser, accessing their favorites menu, etc.) that you will probably not want or not be able to prompt the user.
I would force them to click a button such as publish. That is a 'training' issue.
Automatically saving changes when they leave could have other ramifications. For example if a user opens up a record and plays around with it and has no intention of changing it, they close it, like a word document, excel, etc. . . I would have your site mimic that model.
You also have to remember that the web is a disconnected environment and is not required all web applications run like a windows application.
If the user doesn't click the publish/save button then there changes are not saved and that is up to them to remember to do.