Simple login across the site - New Site Considerations

[IntegrityWebDev]

At the urging of our resident expert, I'm posting this question.

THE BACKGROUND:
I am working on a complete re-tooling of an existing site. one feature I need on this site that is not in the old site, is in the upper right corner there needs to be a place for users to enter an account number (not username/pwd).

*If the account number is not entered, a simple text, textbox and submit button will appear and parts of the site will not be visible.

*If the account number has been entered, a simple "Welcome Joe" type message will appear in that top right area, and certain things, such as pricing tables, will appear in the site.

It has not yet been determined if this account number log in will be needed on every page or almost every page. My guess is it can go on every page.

THE QUESTION:
How would you implement this on a website? I'm not so much interested in how to look up the account number in the DB and so forth as I am the general thought (and maybe some examples) on how and where on the site to implement this, how to do the sessions etc. Would it be a global class in the App_Code folder? Somewhere else?

Please let me know your thoughts. Thanks!

Chris

[Ocean10000]

To be honost I would think you would need an account # and a password. So to prevent people from entering other peoples Account numbers. So I would end up using the standard Login System, just renaming Login Name with Account #. Microsoft actually supplies controls and samples for a default login system, it uses sessions/cookies to track the login information, so it can be used on any browser that accepts cookies.

Reference:
Login Web Server Controls [msdn.microsoft.com]
isauthenticated [msdn.microsoft.com]
How To Implement Forms-Based Authentication [support.microsoft.com]

[marcel]

My first thought was also that there should be some kind of password verification, but I have seen some sites (usually Intranet sites) that are set up this way.

A very simple way to do it is to use Masterpages to show the Login/Welcome area.

For Session variables (and also config settings) I prefer to have a helper class to give me typed values, so for the Session values I would use the following code:

public class SessionHelpers
{
/// <summary>
/// Gets or Sets the AccountNumber of the Session.
/// </summary>
public static string SessionAccountNumber
{
get
{
return (string)HttpContext.Current.Session["AccountNumber"];
}
set
{
HttpContext.Current.Session["AccountNumber"] = value;
}
}
/// <summary>
/// Returns true if the user has been authenticated.
/// </summary>
public static bool isAuthenticated
{
get
{
return !String.IsNullOrEmpty(SessionAccountNumber);
}
}
}

You can then easily Get and Set this value with:

SessionHelpers.SessionAccountNumber = "12345";
string san = SessionHelpers.SessionAccountNumber;

//and also
bool isAuthenticated = SessionHelpers.isAuthenticated;

and then in the MasterPage I would have the following:

protected void Page_Load(object sender, EventArgs e)
{
if (SessionHelpers.isAuthenticated)
{
// Show Stuff
}
else
{
// Hide Stuff
}
}

This is all very simple and not yet well thought out, but hopefully it will give you some ideas.

[IntegrityWebDev]

I know the basic thought of MasterPages but I've never used them. One thing I know is that some pages are going to have a pretty different layout than other pages. Would that make a difference for MasterPage?

[marcel]

One thing I know is that some pages are going to have a pretty different layout than other pages. Would that make a difference for MasterPage?

Yes, it could make things a little more difficult, depending on the differences.

You could also use the Page_Load code in all of your seperate Pages, but make sure that all of the verification logic is done in a central place like the Helpers file, otherwise it could be a nightmare to maintain if you decide the verification rules need adapting.

[IntegrityWebDev]

Gotcha....all of this is prelim where i can get my thoughts in order. There are a lot of things still unanswered on my end. The things I'm asking about are where my team is at "at this point". As with all projects its all subject to change. :-) Any other thoughts or suggestions from anyone? It's been great feedback so far!

[marcel]

One thing I forgot to add, as you're from a PHP background, and fairly new to the ASP.NET / WebForms idea, maybe ASP.Net MVC will be an option for you?

MVC will give you the benefits of C# Object Orientation, and the power to control the HTML output as you are used to from PHP. (and hopefully the learning curve will be less steep than having to get used to the WebForms architecture)

Here is a great starter to MVC:
[asp.net...]

[IntegrityWebDev]

Thanks for all the feedback so far. I have changed the scenario slightly and come up with some code that works. Instead of a login on every page, there would only be 1 login page, but every page needs to keep track of if they are logged in or not. Also on this example I assumed there could/would be a master page.

This works but I am hoping for some feedback as to if this is suitable or if not, what I should do differently.



On the master page I have this label:

<asp:Label ID="LogInBox" runat="server" Text="Label"></asp:Label>

On the master page code behind I have this (sloppy but just for testing) code:

public partial class MasterPage : System.Web.UI.MasterPage
{
 protected void Page_Load(object sender, EventArgs e)
 {
 //if the session var for account number does not exist, create it.
 if (HttpContext.Current.Session["StoreAccountNumber"] == null)
 {
  HttpContext.Current.Session["StoreAccountNumber"] = "no";
 }

 //show message for login or already logged in.
 if (HttpContext.Current.Session["StoreAccountNumber"] == "no")
 {
  LogInBox.Text = "Please visit the Login page to sign in.";
 }
 else
 {
  LogInBox.Text = "Welcome Joe Customer";
 }
 }
}

Then on the Login.aspx page there is a simple form to enter the account number. Here is the main logic on the code behind for that page:

 if (IsPostBack)
 {
  //will check account numbers here and do stuff
  HttpContext.Current.Session["StoreAccountNumber"] = LoginBox.Text;
 }

As I said, this is working but I am looking for your thoughts on it. Is there a better way of doing it for this scenario?

Feedback has been great so far, thanks all!
Chris

[marcel]

I wouldn't bother with this part:

//if the session var for account number does not exist, create it.
if (HttpContext.Current.Session["StoreAccountNumber"] == null)
{
HttpContext.Current.Session["StoreAccountNumber"] = "no";
}

My opinion is that if the session variable is Null or Empty, then the user has not been verified, there's no point in filling it with "no".

I would still recommend using a Helper Class to Get and Set the Session Variable though (like in the example of my first post). It will give you a central place to get and set the SessionVariables (amongst other things) which should ease maintenance issues in the future.

Imagine if later it is decided that the account number must meet certain conditions, instead of combing through all of your code to check for this, just change it in the helper class, for example all account numbers must begin with "D":

public static string SessionAccountNumber
{
get
{
return (string)HttpContext.Current.Session["AccountNumber"];
}
set
{ if (!value.StartsWith("D"))
{
Throw new Exception("Invalid Account number");
}
else
{
// Valid account number, set the session variable
HttpContext.Current.Session["AccountNumber"] = value;
}
}

(I havent tested this code, so it may not work)

Another thing to consider is to Create a 'AccountUser' class, and store this in the session variable, instead of just the account number, that way you can store all of the users details in this class (such as name, age, address etc.). This is one way to avoid having to retrieve user details from the database multiple times.

I haven't the time now, but I will post some example code later.

[marcel]

Here is a simple example, first the UserAccount Class:

public class UserAccount
{
public string AccountNumber { get; set; }
public string Name { get; set; }
public string Street { get; set; }
public string ZipCode { get; set; }
public string City { get; set; }
}

Then the session Helpers:

public class SessionHelpers
{
/// <summary>
/// Gets or Sets the UserAccount of the Session.
/// </summary>
public static UserAccount UserAccount
{
get
{
return (UserAccount)HttpContext.Current.Session["UserAccount"];
}
set
{
HttpContext.Current.Session["UserAccount"] = value;
}
}
}

And an example login helpers Class (with pseudo code)

public class LoginHelpers
{
/// <summary>
/// Allows the user to login
/// </summary>
/// <param name="AccountNumber">The account number to get the UserAccount for.</param>
/// <returns>Returns a UserAccount object is the user has been verified, otherwise null.</returns>
public static UserAccount UserLogin(string AccountNumber)
{
// Verify the Account number (via DB or whatever)

if (//UserAccount is verified)
{
UserAccount myUserAccount = new UserAccount();
myUserAccount.AccountNumber = AccountNumber;
// Get the rest from the DB or whatever
// myUserAccount.Name = ...
// myUserAccount.Street = ...

// Also add to session
SessionHelpers.UserAccount = myUserAccount;

return myUserAccount;
}
else
{
return null;
}
}
}

Just something simple to show you an alternative idea, but, the more I think about this the more I tend to agree with Ocean10000.

How about using the built-in membership controls. But, instead of having a password, use the account number for both the login and password (as a sort of verification), you can then change the login box from type='password' to type='text' to avoid the stars.

[IntegrityWebDev]

Good ideas. I like the class idea as at some point I may be using other info from their account.

Just as an FYI, the reason I was shying away from some kind of usr/pwd combo at this point is that, due to our antiquated systems here, they have to call in to create their account number and its on a completely different system (AS/400) :-( Then a nightly batch by an RPG programmer gets the AS/400 info into the DB. I didn't want to tell them "first you have to call us to create an account number, THEN you have get online and create a PWD for said account number". Trying to remove barriers. But the idea of using the built-in controls with the acct # for both may work...I could even discuise it as a "retype your account number" box. Hmmmm.... something to think about...

[Ocean10000]

I just wanted to show some customized Form Authentication code, which I have in the global.asax using the BeginRequest event.

The code checks the standard Forms Cookie, and creates a Principal object which I assign to the Context.User. What this does is allow code on the rest of the request to use standard User object to determine what to do. And this will be usable in the entire application.

In this example I redirect to an SSL connection if they are authenticated.

 //---------------------------------------------------------------------- 
 // 
 //---------------------------------------------------------------------- 
 string cookieName = System.Web.Security.FormsAuthentication.FormsCookieName; 
 if (string.IsNullOrEmpty(cookieName) == false) 
 { 
 if (this.Request.Cookies[cookieName] != null && string.IsNullOrEmpty(this.Request.Cookies[cookieName].Value) == false) 
 { 
 this.Context.User = new Ocean2.Web.Code.Principal(this.Request.Cookies[cookieName].Value); 
 } 
 } 
 
 //---------------------------------------------------------------------- 
 // 
 //---------------------------------------------------------------------- 
 if (this.Request.IsSecureConnection == true) 
 { 
 if (this.Context.User == null || this.Context.User.Identity.IsAuthenticated == false) 
 { 
 string strSecureURL = "http://" + this.Request.ServerVariables["SERVER_NAME"] + this.Request.Url.PathAndQuery; 
 this.Response.Redirect(strSecureURL); 
 this.Response.End(); 
 return; 
 } 
 } 
 else 
 { 
 if (this.Context.User != null && this.Context.User.Identity.IsAuthenticated == true) 
 { 
 string strSecureURL = "https://" + this.Request.ServerVariables["SERVER_NAME"] + this.Request.Url.PathAndQuery; 
 this.Context.Response.Redirect(strSecureURL); 
 this.Response.End(); 
 return; 
 } 
 } 

Reference
Role-Based Security [msdn.microsoft.com]