When the CacheRolesInCookie property is set to true in the Web.config file, role information for each user is stored in a cookie. When role management checks to see whether a user is in a particular role, the roles cookie is checked before the role provider is called to check the list of roles at the data source. The cookie is dynamically updated to cache the most recently validated role names.
a) As far as I understand the above text, even though role management checks the roles cookie, role provider still checks the list of roles at the data source?
b) Above text talks about role management, which is invoked before role provider is called. What class acts as a role management?
thanx
EDIT:
As far as I understand it, the information cached within the cookie includes all available roles, not just the ones your user is a member of. So I do not believe that the database would be hit each and every time.
From same site as the quote from my previous post:
Roles.CacheRolesInCookie Property Value
true if the current user's roles are cached in a cookie; otherwise, false. The default is true.
This suggests that only roles for current user are stored in a cookie. Besides, if all roles where stored in a cookie, then role manager would still have to check the DB to see which of the roles current user is member of?!
Role management is handled by the System.Web.Security.Roles class.
I thought the text used the term role management to refer to class/module that calls the methods of System.Web.Security.Roles, which in turn check whether user is a member of particular role?
Role management is handled by the System.Web.Security.Roles class. As far as I understand it, the information cached within the cookie includes all available roles, not just the ones your user is a member of. So I do not believe that the database would be hit each and every time.
If you were to change the list of available roles (i.e. by creating a new role), then the provider would invalidate the cache in the cookie on the next round trip.
//Richard.
Related
In MVC5 asp.net - Is there a way to allow user login only if the user has a particular claim in the user database? I'd like to assign a "CanLogin" claim to users in my user database that are allowed to log in at any given time. By removing the "CanLogin" claim, I could effectively lock the users out of the system until further notice.
This would have to work for a first time login as well as cookie login at a later stage if the user has checked "remember my login".
Using authentication filter, you can check the identity.claims property to validate whatever claims are present in the context.
The claims must be added during the login process
Then you can check whether a particular user is enabled or not.
However, if the user database is self maintained, you can just set a disabled flag and then reject the login request, instead of returning such a claim.
The claims are used for Authorization to a particular functionality rather than Authentication to an app. A valid user will have certain claims which can tell what all the user is permitted to do.
ASP.NET 4.5 / C# / SQL 2012
I already have a well defined database with a users table and a roles/permissions column. The column contains a delimited list of roles. I was hoping to use ASP.NET's built in features on the back-end so I can be lazy and use things like the and filter by role. I'd like to read my roles from the database and tell ASP these are the roles my user is in. Custom...but hopefully simple. Here is what I have so far:
//create an identity
GenericIdentity objIdentity = new GenericIdentity("Matt"); //this would actually be the username/email of the newly authenticated user
//get roles for user
string[] strRoles = { "ADW", "USR" }; //this will get read from the database on authentication
//add identity and roles to a principal
GenericPrincipal objPrincipal = new GenericPrincipal(objIdentity, strRoles);
//add to current user
HttpContext.Current.User = objPrincipal;
//add the principal to the current context of the current thread
Thread.CurrentPrincipal = objPrincipal; //not sure what this does, doesn't affect my results/tests
If I execute the code above and then run the following:
Response.Write(User.IsInRole("ADW"));
Response.Write(User.IsInRole("xxx"));
I get a True/False as expected. However, this doesn't persist to the next page. I did a fair amount of reading on custom membership/role providers, but I can't find this specific use case. Most talk about setting up a DB specifically for this task. I also saw mention of the newer Simple Membership, but couldn't get any love from that end either. I'm hoping there is a solution that involves what I'm already doing. I'd love to execute this code when the user authenticates, but be able to reference this user in other pages. I could always call to the database for every page. I'm assuming that would suck, and that's not what the built in provider does.
Thanks all.
You are approaching it from the wrong side. You don't have to create identity and principal manually, assuming you are not creating a custom authentication module.
In any other case, you only choose the persistence mechanism and the corresponding authentication module sets the identity/principal according to the persistence.
A commonly used persistence mechanism is Forms Authentication, where you issue forms cookies. The forms authentication module makes sure the identity/principal is set early in the pipeline and takes the cookie as the source of information.
If you want to replace the cookie by your custom cookie (in other words - replace forms authentication with your own) - you have to think of a way to persist the security info, to the cookie for example.
Note, however, that this is probably not necessary. The very same forms authentication can be used with any custom membership and role providers. This is because these two have different responsibilities - membersip provider is for actual authentication whereas forms authentication module is for persisting the information for consecutive requests.
Edit: to add a role for a user so that it is persisted in the user database:
Roles.AddUsersToRoles( ... );
But first, you'd have to create users in the user database:
Membership.CreateUser( ... );
Note that Roles and Membership are facades for actual role and membership providers. While default providers use the membership database, you can easily create custom providers that persist the information anywhere at the server side.
In my application I can change user permissions and roles in backend.
When a user is logged in and I remove a role of the user, the user can still access content which he actually is not permitted to access anymore, because he is missing the role. The changes take effect only when the user reauthenticates himself with logout/login.
So my question is, can I access the session of a logged in user (not me)? I know I can access my own session and destroy it which forces me to login again. But I want to get the session of any user who is logged in. Is this possible? I could not find any resources about that.
I use PdoSessionStorage with symfony2.1 and fosuserbundle.
Make your user class implement Symfony\Component\Security\Core\User\EquatableInterface.
If you return false from the isEqualTo() method, the user will be reauthenticated. Use that method to compare only those properties that when changed should force reauthentication — roles in your case.
You can get around this issue by following an approach similar to what I did:
When user logs in, store all permissions in session along with a checksum of those permissions.
Store the same checksum in a database, or on disk, against that user ID
Whenever the user makes a request, verify that the checksum on disk matches the one in session for that user. If it is different, reload the permissions into the user's session
When you change the permissions, update the checksum in the database (or on disk) that is stored against that user. This will trigger a resync on their next request.
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.
I am using ASP.NET Forms Authentication (Roles, Users, Membership, etc).
In short, I'm looking for something that will give me a unique UserId for users -before- they are logged in or before they create an account.
I would like the user to be able to personalize the site to a certain extent -before- they go about the work if creating an account. I realize that work would be lost if they clear their cookies.
I store personalized settings in a table with their ASP.NET Auth UserId. I'm hoping that users get assigned a cookie-based UserId even before they log in and create an account, rather than every "guest" having the same "guest id".
If and when they do create an account or log in I'd have to migrate their saved settings to their "permanent" UserId, but that's ok with me.
I could re-invent something, creating a Guid and storing it in a cookie, but I'd like to avoid reinventing the wheel if there's already a mechanism in ASP.NET.
Thanks!
Dave
See Personalization and User Profiles in ASP.NET 2.0 - Handling Anonymous Users.
Note that each anonymous user gets a unique anonymous ID the first time they visit a site. This ID is stored persistently in a cookie. Thus, if a second user opens up a browser on the same computer as the first, the second user will be seen by the site as having the same anonymous ID that was issued to the first user.
The short answer is No. There is no user id assigned to anonymous users that you can store in the Profile table. You will have to create an "AnonymousSettings" table that you store customization information on a per user basis. You would generate your own cookie with a unique ID (a GUID would be a good choice) and the use that to lookup the anonymous user.
Once the user registers, you can transfer their settings from the anonymous table to the profile settings.
Asp.net Automatically generate SessionID per user.
You can use SessionID of active user.
Session.SessionID returns unique key for user. SessionID stored in Cookies.
Asp.Net doesn't remove Session Cookie. After User logged in. So
You can match SessionID and UserId.