Flex:Browser Refresh Issue - apache-flex

I was working with my application which shows login first time and goes to the second screen after successful validation. But there is a problem occurs when browser get refresh by F5 or browser button the application gets reloaded and shows the very first screen i.e. the Login screen.
How to avoid this, I mean irrespective of browser reloading the current screen/component should remain intact (it should not start with the beginning).
As an example I have a link from where I took this example & uses in my code:
http://www.vipercreations.com/media/tutorials/login_system_with_flex_and_php/
credentials: user: test and pass: test
Here, once u logged in and press F5 you will back to the Ist screen rather than staying at the same screen.
Thanks,Shuo

If your login creates something like a session you can pass that same session object to the application via FlashVars.
When your application is starting, test if a session is already existing. If existing, validate it against the server. If successful: you are logged in, so skip the login screen. Otherwise: show login screen.
Besides: This is not a refresh issue but boils down to session management. Instead of hitting the refresh button I could also open the same website again and would have to login which seems akward.

Ofcourse it will reload, it is not the flash who is reloaded.. its the whole web page. or HTML file.
I have this code to disable F5 or refresh
<script>
window.history.forward(1);
document.attachEvent("onkeydown", my_onkeydown_handler);
function my_onkeydown_handler()
{
switch (event.keyCode)
{
case 116 : // 'F5'
event.returnValue = false;
event.keyCode = 0;
window.status = "We have disabled F5";
break;
}
}
</script>

You could store the sessionID in a cookie via ExternalInterface or in a shared object. This way you can even add a expiration date that of course should be in sync with the serverside expiration of the session.
Additionally you can use the HistoryManager or the BrowserManager to encode states of the app in the URL. If you design the states carefully, hitting F5 (or accessing the page via bookmarks) will direct the browser to the last state instead of the beginning. Just remember to verify the session.

Related

REST API Wordpress back button

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.

Is it possible to detect a page refresh (F5) serverside?

...in comparison to requests of normal link click behaviour. I thought I might be able to use this to throw away some cached stuff on the serverside. For a more technical orientated target audience this could be a relative natural way of clearing a cache for i.e. graphs and charts.
To be clear - I am using ASP.NET MVC
I've just checked the three browsers you're likely to care about, and all three add extra cache headers in the request when you refresh the page. Conceivable you could check for those headers to throw out some server-side cache. It also seems a logical and natural way to do it.
IE: adds "Pragma: no-cache"
Chrome: adds "Cache-Control: max-age=0" and "If-Modified-Since: Tue, 17 Dec 2013 10:16:22 GMT" (disclaimer: time may vary)
Firefox: adds "Cache-Control: max-age=0"
I just checked this by refreshing this page in all three browsers, and checking Fiddler. It is possible there is more sophisticated logic going on that I haven't caught on to.
Since it's in MVC, I would use the TempData to achieve this. On the first load of your method, you can set a value in the TempData so on the next load(the refresh) you would have a value set in this.
Let say you have a Add method, I think that should do the trick :
public virtual ActionResult Add(Model model)
{
if(TempData.ContainsKey("yourKey"))
{
//it means that you reload this method or you click on the link
//be sure to use unique key by request since TempData is use for the next request
}
TempData.Add("yourKey", true);
return View(model);
}
Add this script to your head section:
<script>
$(window).keydown(function (e) {
if (e.which == 116) {
e.preventDefault();
var l = window.location;
var lp = (l + "?").split('?');
window.location = lp[0] + "?f5=1&" + lp[1];
return false;
}
});
</script>
In server side just check if Request["f5"]=="1"
If you prefer not to modify the URL, you may add a temporary cookie. something like this:
<script>
$(window).keydown(function (e) {
if (e.which == 116) {
AddCookie("F5","1")
}
});
</script>
On page load check if the cookie exists and delete it for next request.
You could compare the current session ID to the last page that was loaded and then compare the IsPostBack command.
If IsPostBack is true you know the user has clicked something on that page to post the page back.
If the last page that was retrieved for the current session ID was not the same as the page you are currently loading then they arrived at this page from another page.
If the last page that was retrieved is the same for the current session ID as the current page you are processing then this was likely a refresh (F5).
The only problem would be that you would detect F5 the same as someone putting their cursor in the address bar and hitting the Enter key once the page had finished loading, but I doubt this would be a problem for you.
EDIT:
There seems to be some confusion on the comments about how this system would work so let me explain further. As was pointed out to me IsPostBack is not available in MVC so you have to test for post backs as shown here:
ASP.NET MVC - Is IsPostBack still here?
Let us consider the three ways in which you can end up at a page, any page. For our examples let us assume we want to detect refreshes on page X.
You can get to Page X these ways:
1. User presses a button on page A which takes you to page X.
2. User presses a button on Page B which posts you back to page B (post back).
3. User presses F5 or reloads the page some other way. - this is the one we want to detect..
There is scenario 4 which is 'user comes to page X from another site' but this would start a new session so let us not consider this.
Everytime a user loads a page you store that page somewhere along with the SessionID. The SessionID is constant for any one user for the duration of the session time out. There are some caveats to this such as accessing from different browsers on a single machine but I do not want to confuse matters.
Scenario 1:
User loads page A, we look in our memory and there are no records at present. We store 'Page A' and the sessionID in memory.
User clicks button on Page A.
User is redirected, posts or transferred to Page B.
Page B loads, we check the 'IsPostBack' flag, it may or may not be true at this point. If it is we know it is not a refresh, if it is false we need to continue to test as follows. we look in our memory and there is a record for 'Page A' for the current Session ID (remember the session ID does not change between requests for any given user).
because the previous page was 'Page A' and we are on Page B we know this is NOT a refresh.
We store 'Page B; and the sessionID in memory (in practice we either erase or update the previous record pointing to Page A).
Scenario 2:
User loads page B, we store 'Page B' and the sessionID in memory.
User clicks a button on page B.
Page B loads, we check 'IsPostBack' flag. It is true so we know this is not a refresh.
Scenario 3:
User loads Page B, we store 'Page B' and the sessionID in memory.
User refreshes the page or reloads it by putting their cursor in the address bar and hitting enter.
Page B loads, we check the 'IsPostBack' flag, it is false so we need to continue to test as follows. we look in our memory and there is a record for 'Page B' for the current Session ID. Because the previous page was 'Page B' and we are on Page B we know this IS a refresh.
By using this approach you can detect refreshes. If you are using MVC you can test Request.HttpMethod=="POST"
The only problem you get is if the user does a POST, you do a redirection, then the user goes back one page and refreshes from there are is will resubmit the form, sending the POST again. This will be detected as a fresh submission when it is actually a refresh. This can be eliminated using a Nonce approach or something similar.

Request.Form[“__EVENTTARGET"] value not clearing

When I try to log off the system, my login page is loaded. After that press the browser back button and it shows web page has expired and when I refresh the page, the database call is again made since the value in Request. Form[“__EVENTTARGET”] attribute and textbox values are retaining its previous values and the function for logging in is again executed.
Please suggest a way to solve this issue.
Ex : Server side code is given below:
if (IsPostBack)
{
string parameter = Request.Form["_EVENTTARGET"];
string argument = Request.Form["_EVENTARGUMENT"];
if (parameter == "LOGIN")
{
ValidateLoginDetails();
}
}
After log off, When I press the browser back button, browser shows web page has expired. Then I refreshed the page and I am getting the values of the string parameter. What can be the reason and how can I solve this issue.
Sounds like you haven't logged the user out correctly - you shouldn't be able to hit server-side code on a page that's configured to be authenticated until authentication has happened.
Another option is that there's a problem with the authentication configuration - have you checked that User.Identity.Name returns the value you expect?

Prevent viewing a restricted page page on pressing back/forward button

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.

Back button must not go to previous page after signing out

I am developing an asp.net web site and I am not using inbuilt authentication controls of asp.net. I have created manually tables for users for site.
What I want is as follows
After logging in user can access the pages (that is already done)
When user press sign out (user goes to specific page - example - default.aspx)
Now when user press "back" button of browser, it must not go to previous page (that is done in Yahoo pages - I want to implement the same)
To prevent users from seeing the previous page when pressing the back button you need to instruct the browser not to cache this page:
Response.Cache.SetExpires(DateTime.UtcNow.AddDays(-1));
Response.Cache.SetValidUntilExpires(false);
Response.Cache.SetRevalidation(HttpCacheRevalidation.AllCaches);
Response.Cache.SetCacheability(HttpCacheability.NoCache);
Response.Cache.SetNoStore();
You could put this code in all authenticated pages, thus preventing them from being cached on client browsers.
For a page not to be cached the browser needs to respond appropriately to caching instructions, but there is no guarantee that this will work on every browser! (An appropriately evil person could write their own browser to ignore caching information, or write a proxy to strip it out...)
So you can't get this to work 100% of the time, but you're always going to face the problem that a user can easily take a screenshot, print out a page, save a copy on their disk, etc. once you've fed a page to them anyway...
the answer for you question is:
for When user press sign out. ( user goes to specific page - example - default.aspx )
you can add a LinkButton as Signout link and in the click event handler you can write
Response.Redirect("Default.aspx");
for Now when user press "back" button of browser It must not go to previous page
//add the following code to your code behind of the page
protected override void OnPreRender(EventArgs e)
{
base.OnPreRender(e);
string strDisAbleBackButton;
strDisAbleBackButton = "<script language="javascript">\n";
strDisAbleBackButton += "window.history.forward(1);\n";
strDisAbleBackButton += "\n</script>";
ClientScript.RegisterClientScriptBlock(this.Page.GetType(), "clientScript", strDisAbleBackButton);
}
refer to csharpdotnetfreak.blogspot.com

Resources