Storing Login Status

[Scott.Macmaster]

After authentication a user I've been storing the login status in a session variable. Basically, like this,


Session.Item("UserLoginStatus") = UserLoginStatus.LoginSuccessful


UserLoginStatus is an enum I created to store possible login status codes so I don't have to worry about mistyping the code


Public Enum UserLoginStatus
Timeout
Logout
InvalidUserName
WrongPassword
AccountLocked
AccountDisabled
NotAuthorized
LoginSuccessful
End Enum


Anyway, my question is about storing the status is a session variable. Is that good/bad/ok? What is the best way to store login status?


Thanks

[Shuja Ali]

I am not sure why you want to use Session, when you should be using the ASP.NET's built-in functionality for all this. If you are using Form's authentication then you are already half way through.

[Scott.Macmaster]

I considered using forms authentication. However, I decided against. First, it uses cookies to store the token. I didn't like that idea. Plus, I wanted the login page to redirect back to the original page. If ASP.NET automatically redirects to the login page. I'll have no way to record the source page to have it redirect back. However, I suppose it's possible ASP.NET can do that. However, that doesn't matter since I can't use it because it uses cookes.


Thanks,
Scott

[dglienna]

Uses HIDDEN strings built INTO the webpage, that gets returned WITH the webpage to the server. Or do you mean a cookie stored on the hard drive?

[Shuja Ali]

Forms Authentication does allow you cookie less Authentication. Take a look at how it is being done
http://geekswithblogs.net/dotnetrodent/archive/2006/05/02/76944.aspx
http://msdn.microsoft.com/en-us/library/aa480476.aspx#pagexplained0002_cookielessforms

[Scott.Macmaster]

So the only other option is to have the token encoded in the url? Isn't that worse?

Maybe I'm missing something but doesn't having this in a cookie or in the url allow a person to be able to hack it and be able to bybase authentication? So it seems better to store the token on the server and relate it to their session id. However, ASP.NET doesn't seem to have that option. So that makes me wonder if missing something.


Thanks,

[Shuja Ali]

Here is how you can mitigate the risk of un-secure cookieless sessions.

1. Make sure the communication is happening over a secured channel (SSL).
2. Tie the sessionid with the IP address from which the request is coming.

Having said that, cookiesless sessions are ideally suited for local intranet applications. May be your other option is to use http headers.