views:

63

answers:

3

I am working on a website (developed in ASP.NET with C#) that was passed on to me. As I'm working through the site, I notice much of the site has this type of code in it:

EmailLabel.Visible = false;
WhateverButton.Visible = false;
AnotherControl.Visible = false;
...

This is all typically done in the code-behind of the site (in the Page_Load method). Essentially, this was put in place to prevent a non-logged in user from accessing components (the rule for the site is that a non-logged in user shouldn't be able to see any part of the site until they log in). The way above works...but it seems rather expensive to have to always check if the user is logged in and then flip to the correct status for all those components.

Is there a different way that this problem could be approached. Just from thinking about it/research, I thought perhaps there would be a way that I could do a redirect back to the home page if a user is not logged in. Even further, I could extend a base page which would do this for any page that extends the base page. However, my knowledge in this area is limited, so my suggestion may not work.

What can SO suggest? Anything better? Is what is there good enough?

+1  A: 

Hey,

There is a loginview component that is a panel which has an anonymous view, authenticated view, and views for specific roles. This makes it easy to do this.

http://www.creativeui.com/2007/10/05/net-membership-part-ii-loginview/

Brian
I actually learned about this in a later question I asked. Thanks for pointing this out!
JasCav
+1  A: 

It would be many, many orders of magnitude more expensive to issue a redirect than to set the Visible flags on a number of controls.

If your page allows both anonymous access and logged in access, then redirecting would also require you to allow anonymous access some other way, probably by building a second version of the page.

The expense question is really just an aside though, it likely doesn't matter at all. To answer your main question, without knowing more about the architecture of your app, I would consider both these things as undesirable. The advantages of just setting the controls to Visible = false is that nothing gets rendered to the output stream for the invisible controls, but they can still interact with server requests.

Without knowing more about the requirements of your page, it's hard to suggest alternatives. As someone else mentioned, a LoginView might meet your needs if the invisible controls don't participate at all with anonymous users.

womp
Good answer (+1), but I'm curious why a redirect is "many orders of magnitude more expensive." Particularly because, there is little chance that a non-logged in user will be able to "break out" of the home page anyway (unless they memorize the address to a random page). So, this shouldn't be something that should happen often.
JasCav
Consider that setting some visible flags takes a few processor cycles, whereas generating a redirect requires a round-trip to the browser, with all the network latency, server resources to handle a new request, and complete page-lifecycle to be dealt with.
womp
+1  A: 

We do this a lot at my work.

The way we accomplish this is by creating a BasePage class that inherits from System.Web.UI.Page. Then you override OnInit, call the base.OnInit, and add code to check for a logged in user. If the user is not logged in, Redirect them to a login page (which would not inherit from BasePage.)

Then, on every page that needs to be protected, just change the page to inherit from BasePage.

And contrary to what womp says above, if you write Response.End(); after the redirect, it is much faster that even continue processing the rest of the page!

Hope that helps.

TJMonk15
While this approach is definitely recommended for most situations, it's impossible for it to be faster. How can setting some boolean variables be anywhere near the overhead of issuing a 301 roundtrip to the browser? You're talking nanoseconds of processor time vs. hundreds of milliseconds of network latency and the server dealing with multiple browser requests. And Response.End() throws a ThreadAbortException, which generates it's own overhead.
womp
Just to clarify though - protecting pages that require *only* authenticated access should definitely be done this way. I'm unclear as whether the OP requires this or not though.
womp
The reason that this is faster, is that none of the Page-Cycle Methods after OnInit get called this way. Saving plenty of CPU time. And for all intents and purposes, an extra roundtrip and the time associated with it are expected by the user in the event that they haven't logged in.
TJMonk15