I cache information about the currently logged in user in the session. This info lazy loads whenever a CurrentUser property on my global application class is used. It does this by calling GetUser() on my custom implementation of MembershipProvider, which either loads the user up from the session, or loads the user from the DB and throws the user object in the session.
How should I handle this scenario?
User logs in.
Administrator deletes user (or deactivates...the point is
they can't log in any more).
User's session expires.
User navigates to a page or makes a request, or whatever.
Currently if this scenario occurs, NullReferenceExceptions are thrown all over the place, because the ASP .NET framework calls GetUser() which returns nothing because it can't find the user in the database (and there's nothing in the session because it expired).
If your app thinks a user is signed in but the user cannot be found, one option might be to use FormsAuthentication.SignOut() to make ASP.NET forget about the user. They should then be kicked back to the login screen or anonymous mode.
Throw an exception from GetUser() if you're going to return null. Then you can have the Application_Error event trap that specific exception and redirect to your login page.
Related
I'm setting up Forms Authentication for the first time.
I am validating the username and password(hashed) against a local SQL database.
All of this is working fine in my logon.aspx file in a ValidateUser() function.
I am also allowing the logon criteria to be persistent so the user does not have to re-enter their credentials when they return to the page.
The problem is, when the previously logged in user returns to my site and the cookie/ticket is used my ValidateUser() function is not called, SO... if I have deactivated the user or changed the user's password the user still gets logged in.
I've considered doing this in Application_AuthorizeRequest or Application_PostAuthorizeRequest in Global.asax, but I would also like to set some session variables at the time I re-verify the credentials against the database and the session is not yet created when these are called for the first time when a user logs in.
Any advise would be greatly appreciated.
For first time when user authorized at that time create session for that user e.g Session["Username"] check session whenever he enters in any page if session is not present redirect him to login page, after that when he log out abandon that session.
So whenever he want to access next time he wants to login again.
I have an ASP.Net MVC3 app. When the LogIn action is called, I use the MembershipProvider to validate the user and FormsAuthentication to set the cookie.
Additionally, I get some info about the user from a database and store it in Session.
When the user subsequently visits the site, they're already authenticated via the cookie, and I'm looking for somewhere to hook into so I can fetch the info about the user from the database again.
Is HttpApplication.AuthorizeRequest() the best place to do this? Obviously this is called for every request so I was hoping there was something I could use that just indicated the user had been authenticated - either explicitly after logging in or when they're authenticated automatically.
There are several events that get triggered on every request, HttpApplication.AuthorizeRequest() should work.
In order to only fetch from the database for logged in users, you can check the Name property of User.Identity which only gets set once the user authenticates:
if(!string.IsEmpty(User.Identity.Name))
{
//make call to database
}
I'm using the DropCreateDatabaseAlways Initializer so my database gets destroyed every time I start the application (at least I hope so). The funny thing is I still see myself as logged in. I get pass the Authorize attribute and can do dangerous stuff. This is probably because of leftover cookies from previous testing.
Registration/login part of my app is the MVC 4 Internet Application template untouched. Shouldn't ASP.NET check the cookie values against users saved in the DB? WebSecurity.IsAuthenticated returns true and WebSecurity.CurrentUserName returns the name.
The only thing working as expected is WebSecurity.CurrentUserId which returns -1. I'm a newbie so I can only guess this is because UserId isn't stored in the cookie and must be retrieved from the database.
Am I right? If so, does it mean I should always use WebSecurity.CurrentUserId to determine whether a user is logged in? WebSecurity.IsAuthenticated and User.Identity.IsAuthenticated seem pretty useless in that case. I can delete a user's account and he or she remains unaffected. What should be done differently if I am wrong?
If you want to realiably check whether a user has not been deleted, you just have to consult the database.
Note that users and administrators work concurrently. This means that a user can be deleted just a second after he has been authenticated. A cookie can be then even one or two seconds old (!) and the user could probably have been just deleted.
In a most pessimistic scenario, a user types a valid username and password and is succesfully logged in and get the "sorry, your account has been deleted" just one request later (because the account has really just been deleted).
There will be a small window where if a user is deleted and they are still logged in that they can still access the site. Since most actions require a validate user id, you can simply throw an excpetion and log the user out.
Normally the database does not get blown away on each build, so I'm guessing this is not a use case SimpleMembership was coded for. You can of course check for this. I'll make another assumption that you are not closing your browser when you rebuild the site and deploy the new database. In a real world scenario these things just don't happen. The database is never blown away and the user id is never lost.
Generally once you've logged in the user, the user is not authenticated anytime after that (unless they have logged out, or the session has expired). That's the point of login. The authentication cookie is an indication that the authentication happened and was successful. The assumption going forward is the user has access to your site and is not reauthenticated.
As long as the authentication session remains open (i.e. browser now closed), the session cookie remains active and MVC assumes that the user is still valid.
Remove the cookie by using FormsAuthentication.LogOff() if the user is authenticated (User.Identity.IsAuthenticated == true) and there's no valid user in UserTable (WebSecurity.CurrentUserId == -1).
I had the same issue, but solved it by specifying the required role(s) in the Authorize attribute. As soon as you do this, it start getting to the database and fails with the "user does not exist" error, which is what you want.
[Authorize(Roles = "Customer")]
public class DashboardController : Controller
In normal case adding Session.Abandon(); to to your LogOff action in AccountController would do the job of clearing session:
public ActionResult LogOff()
{
FormsAuthentication.SignOut();
Session.Abandon();
return RedirectToAction("Index", "Home");
}
So I think you can try adding Session.Abandon(); in init code, where you use DropCreateDatabaseAlways to clear session each time.
The ticket issuing time is usually encrypted within the authentication cookie then you can use it to require re-authentication to sensitive areas (inbox/billing etc.) if more than X time passed since login.
If you insist on invalidating all current auth tickets upon application changes (i.e database/configuration) you can change this settings in your web.config:
<machineKey validationKey="..." decryptionKey="" />
I've set up an STS with WIF and want to expose whether a user is signed in so that an RP can determine if the user is signed in without requiring the user to redirect to the STS and return. If the user is signed in, a different process flow will occur on the RP so it's important to know but not to force the sign-in at this point in the process.
My plan was to create a simple generic handler on the STS which, when hit via an HttpWebRequest, returns the output of context.User.Identity.IsAuthenticated (where context is the HttpContext passed into the ProcessRequest method:
public void ProcessRequest(HttpContext context)
{
context.Response.ContentType = "text/plain";
if (context.User != null && context.User.Identity.IsAuthenticated)
context.Response.Write("True");
else
context.Response.Write("False");
}
My problem is, if the user is signed in and I hit this handler directly, it returns True but if I programmatically hit the handler from the RP, it returns False (in fact the Identity is null).
Am I just completely wrong in doing this and hitting the handler from the RP will return the status of the User on the RP or could I be doing something wrong?
This handler will only work (return true), if you send the STS authentication cookies with the request. Only your web browser may have these cookies. Therefore it can't be done via HttpWebRequest. Also this is why it works, when you call the handler directly from the browser.
I know this is a bit old thread, but the answer may help others who land on this page.
The thing that does the magic behind the authentication is the session and authentication cookies which are sent to the user's client (e.g. browser) from your STS app. I'm not sure how your STS and RP apps are designed and communicate, so I will keep the answer generic. To notify your RP app of the authentication status, you need to:
1) either somehow share both cookies between the user's client and the your RP app. In this scenario, I'm afraid you will have to build your own client and make your users use it to visit the STS app. This is because you cannot get the cookies from the standard browsers. The client you build sends the cookies somewhere where your RP app can get them and place them in HttpWebRequest.CookieContainer which then can successfully get the result of your handler. I'm only explaining this method to say that it is doable and show how complex and twisted it is.
2) or you will have to track the login status of your users. Instead of checking the context.User, your handler must get the user ID from the calling RP app and then check if that user is logged in (that is there is an active session for that user). For example, you can track or store your sessions in the database, or have a look at the following thread for some methods of accessing active sessions:
List all active ASP.NET Sessions
I'm building a web application: some pages will be accessible by non logged-in users (demo and sign-up pages) and others will only be accessible by logged-in users (actual application). In the global.asax file, I'm currently handling the session start event by loading some variable from a query that's based on the UserID. What will happen when a non-logged in user looks at a page? I guess my question is really about how to handle the session start event when it's a logged-in user, when it's not and when a user logs in. I want a certain number of queries to run only once per session, after the user logged in.
Thanks.
I would suggest to implement Forms-Based Authentication, instead of to handle authentication via session. An example can be obtained from here:
http://support.microsoft.com/kb/301240
Don't confuse "login session" with "session state". Session state has nothing to do with whether the user is logged in.
If you want some queries run when the user logs in, you should run them when the user logs in, not in Session_Start.