In our MVC app, we're by-passing the RolesProvider in favor of just caching our roles in a cookie that will be passed around. Following several suggestions around the interwebs, we're leveraging the Application_AuthenticateRequest
event, like so:
protected void Application_AuthenticateRequest(Object sender, EventArgs e)
{
var user = HttpContext.Current.User;
if (user == null || !user.Identity.IsAuthenticated)
{
return;
}
// read the roles from the cookie and set a custom generic principal
var fi = (FormsIdentity)HttpContext.Current.User.Identity;
var httpCookie = HttpContext.Current.Request.Cookies["Roles"]; // custom cookie set during authentication
if (httpCookie != null)
{
string rolesCookie = httpCookie.Value;
var pmUserRoles = rolesCookie.Split(',');
GenericPrincipal gp = new GenericPrincipal(fi, pmUserRoles);
HttpContext.Current.User = gp;
}
}
I'm stepped through that method and threw in a couple conditionals with some of our roles, and immediately after the current User is set, User.IsInRole("rolename")
works like a charm.
But then, when trying to make the same call in a view:
@if(Request.IsAuthenticated)
{
if (User.IsInRole("role1") || User.IsInRole("role2"))
{
<!-- show something -->
}
else if (User.IsInRole("role3"))
{
<!-- show something else -->
}
}
The roles can't be accessed. When I dig into the User at this point, it looks like the roles don't even exist, right after I confirmed that the User has them at the end of the AuthenticateRequest
event.
This question has similar problems, I was going to just comment there but I guess I can't because of my low rep - but it looks like this isn't just an issue with me.
I also looked at this question which has a similar approach, but this is giving me the same result.
Any suggestions or comments on what's going on?
I finally found the answer to this, using the Application_OnPostAuthenticateRequest
handler instead of Application_AuthenticateRequest
.
Courtesy of this answer (which was surprisingly not the accepted one in that thread!). Thanks to Tiago Matias!