When is the LastActivityDate supposed to be updated? When I click on any other pages in my web application as an authenticated user, the LastActivityDate does not get updated.
I would imagine it should be updated when a user clicks on any page, whether it be to do with membership (change password, GetUser(), etc) or not. But the examples that I have seen, seem only to update it on ValidateUser().
http://msdn.microsoft.com/en-us/library/system.web.security.membershipuser.lastactivitydate.aspx
Under Remarks, it says to do it under ValidateUser method.
When do you update the LastActivityDate? Just inside ValidateUser()?
Thanks
Update: Clarified question.
No, for it to get updated on each page request would require your pages to update it manually, but that would be a bad idea.
The LastActivityDate refers to last activity within the domain of the membership provider i.e. authentication token request, change password etc.
If you want to track page request per user that would be another domain, as is typically implemented as a log file of all page request per user.
Related
I am working on an application where certain actions are performed using ajax requests to a backend api page, such as adding likes to content. The javascript function will pass the user ID and content ID to the api page in an xmlhttp request.
We use Forms Authentication with Active Directory.
For obvious reasons, I want to verify that the input I receive on the api page before doing anything at all.
While my web.config makes sure that only logged in users can access the api page, I can't find any way to get the current user's info such as username.
I tried the following:
Membership.GetUser().Username;
How do I go about getting the logged in users' information from my page?
thanks
HttpContext.Current.User returns an object of type IPrincipal, and IPrincipal.Identity returns an object of type IIdentity.
HttpContext.Current.User.Identity.Name gives you the username
HttpContext.Current.User.Identity.IsAuthenticated gives you the authentication status (boolean)
Armed with that, you can look up other details in the database, possibly storing them in the Session.
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 am aware of the mechanism for preventing multiple user logins: In asp.net site how to prevent multiple logins of same user id?. My scenario is different.
On my website, a single page checks if the user is logged in (default .NET membership provider). Once the user is authenticated, the page redirects them to a premium service on a third-party server. This means I can't use the above mechanism to check on each page the current session ID against a previously stored session ID.
On login, I need to end all previous sessions for the current user. All methods that I came across (e.g. FormsAuthentication.SignOut) only target current user. Is it possible to log out user by membership user name, so no two visitors to the site use the same user name?
You could create a table/custom membership field/static dictionary/etc that tracks a user's current session ID. When the user logs in, set that value to the current ID. Then, in your global.asax handle Application_AuthenticateRequest and check if the current session matches what you have stored. If not, perform the SignOut/redirect.
In my appliation,all pages are protected,so they must login to visit the pages.
And the admin of the system can add users.
Now some people told me that I have to prevent people login at the sametime using the same account.
That's to say if there is a user named "John" logined to the system,so other people cannot login with "John" again event he know the password.
Also,if one user find that someone have logined use the account he wanted,he can make the former user offline. If so I have to judge if the current user have been offed ornot in each page. This is not a work can be done easily.
I wonder if this is necessary?
Since I found so many websites nowdays do not limit this,for exmaple,you can use the same account login your gmail/stackoverflow/yahoo and ect in different machine at the same time.
So Any one can give me a suggestion?
Update:
Now,we use the asp.net's form authenciation,(we do not use the membership yet). And in the t_user table in the databse,we have a column named "isOnline" and "last_login_time".
When user login,we set the "isOnline" to 1,and store the login time.
When another user try to login again,we check the "isOnline" and the time:
if("isOnline"==1 && DateTime.now-LastLogiTIme <40min) // where the 40 min is the form authenaication timeout.
thisAccountHasLogined=true;
But suppose a user logined yet,then he clean the browser cookie,then if he refresh the page,he will be redirected to the login page,but not he can never login again before the form authentication time out because the "isOnline" in the db is 1 and the time span from his login to now does not large than the form timeout.
I am confused.
In some scenarios, I could understand not having multiple logins, but in reality, I have never had to implement it.
Unfortunately, I do not believe there is a standard mechanism for determining if a user is already logged in and this would need to be done by additional logic. In our application, we use a database for storing session information and using this, it would be a simple process to see if a session already exists within this for the user and not allow login if so.
Update
I was interested in this myself and found this;
http://msdn.microsoft.com/en-us/library/system.web.security.membershipusercollection.aspx
and this
http://msdn.microsoft.com/en-us/library/system.web.security.membershipuser.aspx
Using those, it may be possible to get this information with the .IsOnline() However, this does make the assumption you are using standard asp.net membership
the table where you store user name and password add a column status
when a user attempt to login update status to "Online" when logout update status "Logout"
During login check status, if status is online , terminate process. This may be an approch to implement this, hope it will help you
I'm using ASP.NET Roles with a special role "Must Change Password". If a user has not changed their password for more than 90 days, they are automatically added to this role. This happens during the user login process. Authorization rules then deny that role access to all of the application except the "change password" page.
Generally this works great, but there is a problem when the role cache cookie is used to cache roles. What happens is during the login process, the password last changed date is checked, and if > 90 days, the user is added to the "Must Change Password" role. In the same page request, I subsequently call Roles.IsUserInRole("Must Change Password") to decide whether to redirect the user to the Change Password page or not. This is where it falls down - it seems that with the role cache cookie enabled, Roles.IsUserInRole("Must Change Password") doesn't realise that I have changed role mappings for this user, and returns false. However, on the next page request, Roles.IsUserInRole("Must Change Password") returns true.
This behaviour is fixed by setting cacheRolesInCookie="false", but that seems a high price to pay. Is there another way to fix this problem?
Another , IMHO more elegant, solution is to cast HttpContext.User to RolePrincipal and call SetDirty method after adding a new role to the user (read more on RolePrincipal.SetDirty).
The next call of IsInRole or GetRolesForUser methods should trigger request to your default RoleProvider.
Since you said that the problem exists in the same request, how about also setting an item in the HttpContext.Current.Items collection to indicate that the user must change their password, and check both the cookie and the HttpContext.Current.Items collection later on in the code?
Actually, I've found the problem - it is not a problem with caching roles in cookies, but rather a problem with Roles.IsUserInRole(). If I use the overload Roles.IsUserInRole(username, role) then it works fine, with or without roles cached in a cookie.