Aspnetcore.docs: Mute or remove privileges from a user. Admin changes

[gaazkam]

"Roles are stored in the Identity cookie. Changes made to user roles are not persisted to the cookie until the cookie is regenerated or the user signs out and signs in. Applications that add users to a role should call SignInManager.RefreshSignInAsync(user) to update the cookie."

I am dreadfully sorry but this really doesn't seem to change the observable behavior with regards to issue #8474

I have created an extremely simplistic project to show this, the code is accessible at https://github.com/gaazkam/RefreshSignIn

The project contains a page "Ban" that both allows users to ban other user via adding them to the role "Banned" and should be inaccessible to banned users (for the sake of simplicity)

This is the banning C# code from this page:

            var bannedUser = await userManager.FindByNameAsync(Input.UsernameToBan);
            if (bannedUser != null)
            {
                await userManager.AddToRoleAsync(bannedUser, "Banned");
                await signInManager.RefreshSignInAsync(bannedUser);
                Message = "Succesfully banned user " + Input.UsernameToBan + ".";
            }

As you can see SignInManager.RefreshSignInAsync IS called here

In spite of this the problematic observable behavior persists: if UserA bans UserB while UserB is logged in, UserB STILL can successfully access the Ban page they should not be able to access, at least until they log out and log in again. Or until enough time has passed, as you have mentioned waiting 30mins indeed makes UserB effectivelly banned, but I feel this still should happen immediatelly, not after 30 mins.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: b66f8ffa-699c-8b11-0cab-805f5953805f
• Version Independent ID: 7c151ed5-fd78-84fd-a08a-88912990c4ca
• Content: Create an ASP.NET Core app with user data protected by authorization
• Content Source: aspnetcore/security/authorization/secure-data.md
• Product: aspnet-core
• GitHub Login: @Rick-Anderson
• Microsoft Alias: riande

[Rick-Anderson]

@HaoK is signInManager.RefreshSignInAsync(User); enough to refresh the Identity cookie?

[HaoK]

RefreshSignInCookie refreshes your cookie, it doesn't refresh someone elses cookie. You need to UpdateSecurityStamp on banned user, and that only triggers a refresh after the default validation interval, there is no immediate revocation by default

[Rick-Anderson]

@HaoK Adding roles is a rare event, perhaps we should suggest they send a message to the user in the new role to sign-out/sign. It sounds like the following advice I added is incomplete:

Add a user to a role

Roles are stored in the Identity cookie. Changes made to user roles are not persisted to the cookie until the cookie is regenerated or the user signs out and signs in. Applications that add users to a role should call SignInManager.RefreshSignInAsync(user) to update the cookie.

[HaoK]

Well the typical scenario for RefreshSignIn is when they are on their manage page and doing something on them. Admin scenarios are not something identity supports generally at this time. So changing someone elses roles is not something we typically deal with as its an admin scenario

[Rick-Anderson]

Supporting real-time admin pages is ultra-low priority. I think it's reasonable for the admin to send a message to the user: "If you are currently signed in, sign-out and sign in again to use your new privilege - or wait approximately 30 minutes until the Identity cookie is refreshed.

[HaoK]

Sounds good to me

[gaazkam]

For adding new privileges, that may be so.
But what about banning? Muting?
https://docs.microsoft.com/en-us/aspnet/core/tutorials/signalr?view=aspnetcore-2.2&tabs=visual-studio
Tutorials include a chat app, but those require muting functionality. When someone spams nonsense in chat, I don't think telling them "We've just muted you, please log out so that you may stop spamming chat" is appropriate.
And what about forums? Wikis? All those require banning.
If I might ask, if and how (if yes) does the framework support this?

[HaoK]

Check on the server whether they have privileges rather than trusting the cookie

[HaoK]

Cookies are by definition stale, hit your db if you want to ensure they have permissions

[gaazkam]

Okay, thank you!

[gaazkam]

Just to make certain though, do I understand You correctly that I should use UserManager.IsInRoleAsync https://docs.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.identity.usermanager-1.isinroleasync?view=aspnetcore-2.1

instead of ClaimsPrincipal.IsInRole?

[HaoK]

That hits the database yes so it is guaranteed to be correct