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
Related
This is not a cross-site attack because it happens on the same website.
Before we render to the browser, we figure out in server-side whether to render a button or not based on whether the user has sufficient credit in their account (example case). So, if they have insufficient credit, the check out button doesn't even make it to the page on page load.
Here's what they did:
Go to a purchase product page when they have sufficient credit. The check out button shows.
They look at Inspector (FireFox) or any other in-browser developer tool and copy the html input element that submits the form.
They purchase as normal. Now, they have insufficient credit.
They go to another purchase product page, and of course, the check out button will no longer show (because it didn't even make it on page load in the first place).
They open up their in-browser developer tool and paste the input element copied from the other previous page when they had sufficient credit. The button shows up on the rendered page. They click it, then they proceed as if they had sufficient credit.
The problem is, the submit button's event handler in code behind is unaware of the existence or non-existence of that submit button, and will execute if called, and that we give it a hard-coded id.
The obvious solution would be to do a credit vs. price check [again] on the click event handler. From inside the event handler, is there a way to determine whether the control existed on page load? I figure that the sender parameter would not be null if they pasted a control in-browser, so there's not much help there.
Any solutions on this?
The only safe solution to this is to check if the user has sufficient credits ON THE SERVER after the postback occurs.
protected void OnSubmit(object sender, eventargs e)
{
if (product.Price > User.Credits) {
throw new Exception();
}
purchase();
}
If you use the check the button approach then they can still use the JavaScript console to call __doPostBack
Never rely on the client side for authorization
You could store in ViewState whether the button was rendered or not; this is encrypted and cannot be changed on the client. If you set it as ViewState["ButtonRendered"] = true;, then you can check this to see if it's true or false, and act accordingly.
Because of the nature of the user opening up multiple browsers, and other tricks, I would 100% recommend you do another database query to make sure they have sufficient credit, and if not, display an error to the user. That would be the absolute best way of handling it. What would keep them from opening up firefox and chrome, and trying to attempt to simultaneously purchase two different items?
I have an ASP.NET Web Form (C#) that users fill out, it has a couple of drop down lists that cause post backs and some validation that causes post backs. I also use a couple of different update panels. One panel is visible for user input and the other panel appears after the user clicks submit and the data is added to the database. The confirmation panel (the last panel) also displays a confirmation number to the user.
After the last panel displays, I would like to prevent the page from reloading when the user presses F5 or refresh. The reason is, I don't want the user to accidentally click refresh or F5 and lose the confirmation number and message. When the user presses F5, the browser interprets it as wanting to load a new page and at that point the session is cleared (as indicated in code below).
My first thought was to reprint the message and confirmation number and make sure that the panel holding it stayed visible. I was going to do this in the else section of the code below - but since there are multiple postbacks and they all trigger the page load, that doesn't work, unless there is someway to determine if the postback is the result of a form element or the f5 key.
protected void Page_Load(object sender, EventArgs e)
{
try
{
if (!IsPostBack)
{
Session.Clear();
GetList();
}
}
catch (Exception ex)
{
//Do something();
}
}
I've seen a few different posts that recommend using Javascript, but I am avoiding that if possible, in the remote chance that someone has javascript turned off.
Here is the flow of the program:
User opens form, fills in fields in the contactpanel and the clicks submit. The fields are validated using ASP.NET server validation controls and if everything is good, the data is sent to the database and a confirmation number is returned. Finally, the contactpanel is set to visibility=false and the confirmationpanel is set to visibility=true.
Hope this helps. Appreciate any suggestions.
Thanks,
Move your content that's on the final screen (the confirmation) to an entirely new page. Whatever data is saved to get to that confirmation should go in some type of data storage (like a database), and then whatever ID or variables the visitor needs to pull that information should go in a Session var. This way when the user refreshes the page, they will still see the content as you intend. It's pretty much how we had to do all forms back in the day anyway.
For instance:
~/form_page.aspx
- User lands
- Fills in information
- Post backs save data as the user progresses
- Save all data collected to a resource such as a database
- Save an ID to access that information to a Session variable
- Redirect user to...
~/form_thankyou.aspx
- On load, get the Session variable needed to pull the information
- Retrieve information from the resource
- Display results to user
(That's not actual code, I was just having trouble with the formatting.)
Using this technique will also make it easier on your SEO/Metrics team to track conversions (even though there are plenty of other ways).
I have one button on page, page name abc.aspx . when user click on that button
it should redirect to finishwork.aspx page.
After finishwork.aspx page user must not go back to abc.aspx page. when user press back button in browser, he should be redirect to workallreadyfinish.aspx page
Disable caching on that pages and avoid caching the page.
Response.Cache.SetExpires(DateTime.UtcNow.AddMinutes(-1));
Response.Cache.SetCacheability(HttpCacheability.NoCache);
Response.Cache.SetNoStore();
location.replace() can be used to replace your page in the history.
There are many ways to accomplish this, but, as you are using ASP.NET and I'm going to assume, WebForms, why don't you make use of the <asp:Wizard> control?
You will be able to have a much detailed control over your steps and block the user to go back and all sort of nice things.
If you want to take the normal way, you can always warn the user that the page will no longer be valid using a javascript event.
You can also make use of hashing and submit the form by an ajax call instead of a normal POST
You can write a cookie once the form is submitted and the next time, show such warning, so even if the user goes back and press the Submit button again, you will not care. Remember to erase the Cookie on if (!Page.IsPostBack) { ... }
Having your user workflow around the browser back button is not such a good idea.
Browser back buttons are not entire in your control.
If you want to provide a logical back in your application, use a back button in your application.
If you only want that a user cannot go back to a page, you should tell the browser not to cache it set the page to expire.
You can use javascript function for this:-
function disableBackButton()
{
window.history.forward();
}
setTimeout("disableBackButton()", 0);
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 am trying to place an action to happen after an entire .aspx page displays. The "action" is a function that uses the Response object to send a file to the user.
More detailed information:
I am trying to replicate the behavior of a link on the page, from a sidebar. I.E. I have a link on the main page for the Export action, and it works fine -- since the page is already displayed before the user clicks it. But when the user is on a sidebar, clicks the link, it should take them back to this main page and then send the file after it displays.
I did some research and thought that using the PageComplete event would be well-suited for this, so I created my event handler and put the call to the export code (it keys off of a query string when loaded from the sidebar) inside my PageComplete event handler. But it behaves just the same way - the browser download box pops up and the page is never loaded before or after.
If it helps to understand what I'm doing here is a snippet of the code used to send the list to the user.
Response.Clear();
Response.BufferOutput = true;
Response.ContentType = "application/ms-excel";
Response.AppendHeader("content-disposition", "attachment;filename=MyList.xls");
Response.Write(listManager.ExportLists(mycode));
Response.End();
I would prefer a way to use a page event to load the page, rather than tinkering with this logic. But, if there is a clean and easier way to get the file sent, and it allows for loading the page then sending the file, that would be fine too.
Is there another Page event I can use besides PageComplete, or is it possible I am missing something?
EDIT: Sorry about the verbosity. I realize that I can't change the way HTTP requests work - I'm only looking for an acceptable solution that achieves more or less the same results. It seems like the way to go is to force a refresh of the page after a couple of seconds (thus ensuring that it loads before the file download code is executed) -- so I am looking for a way to do this as the first answer suggests - refresh to a download. (It doesn't have to be delayed either, if there's a way to refresh with no waiting)
Why doesn't this code work?
private void Page_LoadComplete(object sender, System.EventArgs e)
{
if (Request.QueryString["action"] != null)
{
if (Request.QueryString["action"] == "export")
{
Response.Redirect("MyHome.aspx?action=exportnow", false);
}
if (Request.QueryString["action"] == "exportnow")
{
ExportMasterList();
}
}
}
What it's supposed to do: after page loading is complete, do a Response.Redirect, reloading itself with a different query string. When it reaches the Page LoadComplete event again, the second time it will trigger the function which writes out the file.
What it actually does: Apparently repeats the same problem twice... it goes back to the same problem, how do you execute an action after the page loads, or wait until the page completely finishes loading, then trigger a refresh which will execute the action? Is there no way for ASP.NET to do something by itself without the user clicking on something?
If that's the case, then an auto-refresh after 2 seconds would also be acceptable... but I'm not sure how to do that.
The server can only return one object to the user, a file download or a page. The best you can manage is to return the user to a page that refreshes to a file download.