Checking user authentication in Page_Load()... anywhere else? - asp.net

For each page in my ASP.Net WebForms app I check the user's access like this:
protected void Page_Load(object sender, EventArgs e) {
if (!UserCanAccessPage())
RedirectToAccessNotPermitted();
// < if user has access, set up the page >
}
My question is, is that single check enough or should I check at all other handlers:
protected void seriousDeleteButton_Click(object sender, EventArgs e) {
// ** DO I NEED TO CHECK ACCESS AGAIN HERE? **
// < do stuff that only some users have access to >
}
I know under a normal page lifecycle the Page_Load() should always be called before the event handlers, but I'm wondering if there's a tricky way to hit other ASP.NET endpoints with curl or mucking around with javascript or something.
(I'm only talking about regular WebForms-style postbacks, no explicit AJAX stuff. But of course UpdatePanel uses asynchronous javascript and I'm sure other controls do to.)

Yes, it is enough, because Page_Load will be called every time a user requests a new page or posts back the page. You do not need to check again in button click events.
However, it is fine with a website with a couple of pages. In other words, if you have multiple pages, maintenance is will be nightmare.
Normally, you want to use Form Authentication, and restrict acesss to pages by using web.config.

Related

How to prevent/stop event bubbling/propagation on page load in asp.net

I would like to know if I can prevent the event bubbling / propagation on the page load based on condition like:
protected override void OnLoad(EventArgs e)
{
// If the user press F5 from the browser
if (IsRefresh)
{
// Here I want to stop propagation/bubbling the events like OnClick of a submit button but without using the button object (I want it generic)
}
else
{
base.OnLoad(e);
}
}
Is this possible?
Prevent the event bubbling has two difficulties - detect the F5 and stop the events - i would simply use the Post/Redirect/Get-pattern:
protected void Button1_Click(object sender, System.EventArgs e)
{
// do what you need to do
// now redirect to the same page,
// then a browser-refresh via F5 won't trigger this event again
Response.Redirect(Request.Url.PathAndQuery);
}
I did once in ASP.NET WebForms project when user press on F5 it'll do something other than refresh, I done this by use jQuery keypress even for the page and call e.preventDefault(); check this
Update:
$(document).ready(){function(){
this.keydown(e){
if (e.which == 116){
e.preventDefault();
window.location.href = "http://foo.com/?IsReferesh=1";
}
};
)};
You can use the QueryString to check if user press F5 and the reflection in Code Behind. If I missed something, then I didn't fully understand your question.
Regarding the specifics of your question, how about inverting it? Maybe add a Load event listener (say, in page Init) only if the condition is not met.
Another option might be doing something like:
this.Load -= MyPageLoadMethod;
You are likely looking at the event itself, not the OnLoad method. Eitherway, I think it is possible, see some options here How to remove all event handlers from a control
There is a big "BUT" though...
Like most people here, I think you are not solving the right problem. I'm sorry the same applies for Emad's solution I think.
Tim nailed it. This answer will try to explain this option more.
The pattern Post-Get-redirect is very popular and very standard. In most of our applications, submitting the same form more than once either by re-clicking the submit button before page loading or refreshing the browser causing another POST call is wrong, so, the practice of redirect after a non-AJAX form submission has become so standard.
Everything else you may try will be no more of a dirty workaround than a proper solution.
--
Now, comes the problem of providing feedback to the user. Ruby On Rails provides a nifty helper for this called Flash helper. It's a message you can set before redirecting (or even in the same page if there is no redirect) and the next time you display it, it'll destroy itself, the next time you call it, you get nothing. so, you display nothing.
ASP.NET MVC has something like this which is TempData. TempData can be stored in many places, by default in the Session, so, if you are redirecting from an MVC action, you can set something like TempData['Message'] , and read it in the next Controller. ASP.NET MVC will handle removing it after the redirect.
So, how about Webforms? There's nothing to prevent you from doing it too. It really isn't rocket science
You can check for URL Referrer whether it is an edit page or not and display message based on that.
You can store a message in Session before redirect, and check for it in every page load, if found, you display it and delete it from Session
If Session is disabled, you can use cookies. You can check the date of the cookie before sending, so that if the redirect never happened (use network dropped or whatever) and use came to the page later in the time he doesn't see an outdated message.
You can also store in Cache (with some key related to user of course, as Cache is application wide), You can then set the Cache expiration to some short period to avoid the problem explained in cookies option
You can also google for Rails Flash-like for ASP.NET Webforms to see what reusable components other people came up with. This result for example came in my search:
http://highoncoding.com/Articles/542_Creating_Rails_Like_Flash_Feature_in__NET_The_Flash_Control.aspx
Check NuGet also maybe there's something there. Again, it's not hard to build your own anyway.
Update:
Another simple approach might be to just redirect to the same URL, this'll cause a GET request and will not run any handler, pretty close to the original implementation of Post-Get-Redirect (yours will be Post-Post-Redirect maybe, kidding), and pretty safe as well.
Something like:
Response.Redirect(Request.RawUrl);
Update 2
Just as mentioned above, if you are running after page init, say in page Load, you can always emove events in a way similar to:
this.SubmitButton.Click -= SubmitButton_Click;
You get the idea...
That's useful if what you want is stop particular events, while the previous bits of the answer were assuming you are trying to stop most of the events.
http://gurustop.net
protected override void OnLoad(EventArgs e)
{
if (!IsPostBack)
{
if (Request.UrlReferrer != null)
if (Request.UrlReferrer.PathAndQuery == Request.RawUrl)
{
// Show Message
}
}
}
protected void Button1_Click(object sender, System.EventArgs e)
{
Response.Redirect(Request.Url.PathAndQuery);
}
Note:
if (Request.UrlReferrer.PathAndQuery == Request.RawUrl) // does not work with chrome
so you can replace it with
if (Request.UrlReferrer.AbsolutePath == Request.Url.AbsolutePath)
static string REFRESH_CHECK_GUID = "REFRESH_CHECK_GUID";
protected void Page_Load(object sender, EventArgs e)
{
if (ViewState[REFRESH_CHECK_GUID] != null && !ViewState[REFRESH_CHECK_GUID].ToString().Equals(Session[REFRESH_CHECK_GUID].ToString()))
{
Response.Redirect("Login.Aspx");
}
Session[REFRESH_CHECK_GUID] = System.Guid.NewGuid().ToString();
ViewState[REFRESH_CHECK_GUID] = Session[REFRESH_CHECK_GUID];

Prevent rendering of user control

in our asp.net webforms application, we dynamically load usercontrols into placeholders. In order to retain changes across post-backs, our page-life-cycle is a little more complex than usual. We ALWAYS restore the previous control structure in pageInit in order to successfully load our viewstate. Only then do we clear the placeholder and load a new control into it.
This unfortunately means an entire life-cycle both for the old AND the new usercontrol, including server-side-processing of the old module's entire .ascx markup-file.
Now my question: Is there any possibility to minimize server-side processing of the old module, as it never gets sent back to the client (i.e. it's server-side rendering is completely unnecessary). What I'd ideally want to achieve is a sort of "light-weight" loading of a usercontrol, when it's only purpose is restoring vewstate information without it ever reaching the client.
The goal of the exercise is performance optimization.
Any hints, ideas or suggestions appreciated!
I have resolved code running in webcontrol lifecycle events of dynamically added controls by simply checking if the control was visible (http://msdn.microsoft.com/en-us/library/system.web.ui.control.visible.aspx)-
protected void Page_Load(object sender, EventArgs e)
{
if (this.Visible)
{
//Your code here
}
}
If you have any methods that aren't triggered by a page lifecycle event, and have to be triggered by a user action, such as-
protected void Button1_Click(object sender, EventArgs e)
{
//Do something
}
This can safely be left as is, the method code will not be run until the control is added to the page and the action is triggered.
Although the visibility check doesn't feel especially elegant, it's probably the best way to deal with auto wired events on dynamically loaded controls.

How to track http referrer across post back?

I have a page in my website that can be reached from several other pages. On this page I have a cancel button and when people click that I would like to execute some code on the server and then redirect back to the page they came from.
I was trying to do this by referencing Request.UrlReferrer, but once a post back occurs, this is set to the current page.
I have come up with a workaround using session state:
protected void Page_Load(object sender, EventArgs e)
{
if (!Page.IsPostBack)
{
Session["referrer"] = Request.UrlReferrer.AbsoluteUri;
}
}
btn_Cancel_click(object sender, EventArgs e)
{
//Some other code and then the line below:
Response.Redirect(Session["referrer"]);
}
But I'm curious if there is a more graceful way to do this without using session state. Can anyone suggest a better solution for this?
The UrlReferrer is not safe to be used for return back with the cancel because many users can ether select to block it (and not giving information's from where they have come from), and also I have see some times that malicious programs place there spam sites.
The correct way is to use a parameter on the url that tell to your page where to return on cancel - eg:
http://www.yoursite.com/callpage.aspx?ref=/signin/

Asp.Net call function from a different *.aspx.cs page

If I have a button inside one page for example "main.aspx". And upon being clicked I want the clicked method in "main.aspx.cs" to call a function from a different *.aspx.cs page but also redirect to that *.aspx page...is that possible?
A more concrete example of what you're trying to do would be useful. Otherwise you'll get all sorts of answers, many of which will be off the mark.
You should put common code in the App_Code folder. You should also not have any business logic inside a forms code-behind.
The fact that you need one page to call a method in another page indicates that you haven't done this. Pages are for displaying and interpreting actions, but they should not hold any of the business logic.
e.g. a lame example of a shopping cart.
ProductView.aspx - calls Cart.AddToCart(Product p)
CartView.aspx - displays all items in the cart, and the user
can update or remove items.
- calls Cart.RemoveItem(int cartIndex)
- calls Cart.UpdateItem(int cartIndex, int newItemCount)
Cart itself doesn't belong in either CartView.aspx or ProductView.aspx. It instead belongs in ~/App_Code/Cart.cs
So your solution could look something like
/ (root of your web folder)
Product/
ProductView.aspx
ProductView.aspx.cs
Cart/
CartView.aspx
CartView.aspx.cs
App_Code/
Cart.cs
Product.cs
Also, to add the App_Code folder if it's not already there, right-click the web project and select Add ASP.NET folder and choose App_Code
You need to understand the ASP.NET Page lifecycle and you'll see why this is not Kosher. If you really need to call a method from multiple pages, it sounds like a good candidate for some external class/object.
Alternately, instead of using a querystring parameter, you can set a Session flag and then redirect to this new page. Then clear the session flag when you call that page's method.
In a very basic way, for Main.aspx to go to Other.aspx and to pass some small amount of data on the querystring to indicate an action.
Main.aspx
protected void OnSomeButtonClicked(object sender, EventArgs e)
{
if( someCondition )
{
Response.Redirect("~/Other.aspx?action=runAway");
}
}
in Other.aspx
protected void Page_Load(object sender, EventArgs e)
{
if( !IsPostBack )
{
if( "runAway".Equals(Request.QueryString["action"] )
{
RunAway();
}
}
}
You should also read up on Server.Transfer versus Response.Redirect. Which one to use is situation dependent.
Also note that QueryString parameters can be altered easily by the user, so always verify them and never trust the user.
Why don't you just redirect with a querystring parameter and then execute the function on the destination page?
Instantiate an object from your other page class and call the method.
protected Button1_Clicked(Sender s, Eventargs e){
MyNamespace.Page_Other po = new MyNamespace.Page_Other();
po.Method1();
Response.Redirect("~/page_other.aspx");
}

Managing page sequence

In an ASP.NET 3.5 site we have a relatively standard payment checkout progess that contains a number of pages that need to be visited in sequence (shopping basket, payment details etc)
Each page has a "Continue" button that redirects to the next page in the sequence.
I would like a way of managing the page sequence so that:
I can have a Master page that defines the "Continue" button and its code-behind OnClick event handler
If the user attempts to visit a page out of sequence (by typing the URL directly into their browser, for example) they get redirected to the correct page
This page sequence is nicely defined in one place in my code (in an enum for example)
Why not use the ASP.NET Wizard control?
Alternatively (and I haven't tried it so I can't say how well it works), you could use Windows Workflow to define a sequential workflow and let that control the order pages come up in. There's an article at http://www.devx.com/dotnet/Article/34732 that takes you through doing it this way.
Check the HttpRequest.UrlReferrer variable in each Page_Load method...
http://msdn.microsoft.com/en-us/library/system.web.httprequest.urlreferrer.aspx
... and don't forget to check for nulls! You can bounce them to where they are supposed to be, based on where they came from.
protected void Page_Load(object sender, EventArgs e)
{
if (!IsPostBack)
{
Session["PreviousPage"] = Request.UrlReferrer.ToString();
...
}
else
{
...
}
}

Resources