ASP .NET Custom RoleProvider not respecting cacheRolesInCookie="true" - asp.net

I've implemented a custom role provider, and configured it in my web.config file like this:
<roleManager enabled="true" defaultProvider="TDRoleProvider" cacheRolesInCookie="true">
<providers>
<clear/>
<add name="TDRoleProvider" type="TDRoleProvider"/>
</providers>
</roleManager>
I've overridden the GetRolesForUser function in my custom role provider, and I've stepped into it, and it works just fine - loads up 60 roles for the user I'm testing with. However, I've noticed that the GetRolesForUser gets called on every request that calls User.IsInRole. In other apps I've written, it only calls it once, then caches the result in the cookie. For some reason, the caching is not working for this app. Any ideas as to why?

https://web.archive.org/web/20101123220352/http://connect.microsoft.com/VisualStudio/feedback/details/104688/rolemanager-cacherolesincookie-option-does-not-work
"The issue of when to cache (or not cache) in RolePrincipal went through a number of design iterations, and we finally settled on only caching for the method exposed by the IPrincipal interface (i.e. IsInRole). "

I was having the same problem. In my case the issue was that I was setting Context.User to GenericPrincipal and not RolePrincipal. So instead of:
this.Context.User = new GenericPrincipal(customIdentity, roles);
this fixed for me:
HttpCookie roleCookie = this.Context.Request.Cookies[Roles.CookieName];
if (IsValidAuthCookie(roleCookie))
{
this.Context.User = new RolePrincipal(customIdentity, roleCookie.Value);
}
else
{
this.Context.User = new RolePrincipal(customIdentity);
var x = this.Context.User.IsInRole("Visitor"); // do this to cache the results in the cookie
}
The IsValidAuthCookie method checks for null and empty:
private static bool IsValidAuthCookie(HttpCookie authCookie)
{
return authCookie != null && !String.IsNullOrEmpty(authCookie.Value);
}
UPDATE: After upgrading to MVC5 .NET 4.5 roleManager stopped working (not saving roles in cookie) so had to save it myself:
HttpCookie roleCookie = filterContext.HttpContext.Request.Cookies[Roles.CookieName];
if (IsValidAuthCookie(roleCookie))
{
filterContext.Principal = new RolePrincipal(customIdentity, roleCookie.Value);
RolePrincipal rp = (RolePrincipal)filterContext.Principal;
if (!rp.IsRoleListCached) // check if roles loaded properly (if loads old cookie from another user for example, roles won't be loaded/cached).
{
// roles not loaded. Delete and save new
Roles.DeleteCookie();
rp.IsInRole("Visitor"); // load Roles
SaveRoleCookie(rp, filterContext);
}
}
else
{
filterContext.Principal = new RolePrincipal(customIdentity);
filterContext.Principal.IsInRole("Visitor"); // do this to cache the results in the cookie.
SaveRoleCookie(filterContext.Principal as RolePrincipal, filterContext);
}
Save the roleCookie
private void SaveRoleCookie(RolePrincipal rp, AuthenticationContext filterContext)
{
string s = rp.ToEncryptedTicket();
const int MAX_COOKIE_LENGTH = 4096;
if (string.IsNullOrEmpty(s) || s.Length > MAX_COOKIE_LENGTH)
{
Roles.DeleteCookie();
}
else
{
HttpCookie cookie = new HttpCookie(Roles.CookieName, s);
cookie.HttpOnly = true;
cookie.Path = Roles.CookiePath;
cookie.Domain = Roles.Domain;
if (Roles.CreatePersistentCookie)
cookie.Expires = rp.ExpireDate;
cookie.Secure = Roles.CookieRequireSSL;
filterContext.HttpContext.Response.Cookies.Add(cookie);
}
}
Place this code on AuthenticationFilter and register it globally. See here.

Same is true for me. It keeps calling GetRolesForUser()

Related

ASP.NET MVC 5 Custom Role Provider Not Working?

i have a problem with my custom role providor "string[] GetRolesForUser(string username)" method but the proccess dont go through it. My code is:
Controller (Just a piece of it):
[Authorize(Roles="Administrator")]
public class UsersController : AdminBaseController
{
private IUsersRepository users;
private IDepartmentsRepository departments;
public UsersController()
{
this.users = new UsersRepository(new TicketsContext());
this.departments = new DepartmentsRepository(new TicketsContext());
}
}
Custom Role Provider:
public class CustomRoleProvider : RoleProvider
{
public override bool IsUserInRole(string username, string roleName)
{
var userRoles = GetRolesForUser(username);
return userRoles.Contains(roleName);
}
public override string[] GetRolesForUser(string username)
{
//Return if the user is not authenticated
if (!HttpContext.Current.User.Identity.IsAuthenticated)
return null;
//Return if present in Cache
var cacheKey = string.Format("UserRoles_{0}", username);
if (HttpRuntime.Cache[cacheKey] != null)
return (string[])HttpRuntime.Cache[cacheKey];
//Get the roles from DB
var userRoles = new string[] { };
var user = db.Users.Where(u => u.email == username).FirstOrDefault();
if (user != null)
{
if(user.access_level == 0)
{
userRoles = new[] { "Administrator" };
}
else
{
userRoles = new[] { "Normal" };
}
}
//Store in cache
HttpRuntime.Cache.Insert(cacheKey, userRoles, null, DateTime.Now.AddMinutes(_cacheTimeoutInMinutes), Cache.NoSlidingExpiration);
// Return
return userRoles.ToArray();
}
}
Web.config
<!-- Custom Role Provider -->
<roleManager enabled="true" defaultProvider="TicketsRoleProvider">
<providers>
<add name="TicketsRoleProvider"
type="Tickets.CustomRoleProvider"
cacheTimeoutInMinutes="30" />
</providers>
</roleManager>
I cant get it to work, and i dont know why.
Can anyone help me pls ?
Thanks
I can't see anything obvious, but I would:
Remove the check for "HttpContext.Current.User.Identity.IsAuthenticated" in the GetRolesForUser method. This method should just get the roles for the username supplied as an argument.
To debug, I'd start by examining HttpContext.Current.User.GetType() inside a controller action method (one that isn't secured). Is it of type System.Web.Security.RolePrincipal?
You should implement IsUserInRole in your custom RoleProvider. The implementation can just check that the supplied role is in the array returned by GetRolesForUser. I don't think this is your problem though: IsUserInRole isn't used by RolePrincipal (though it is used by System.ServiceModel.Security.RoleProviderPrincipal if you use ASP.NET roles in a WCF service, so it's a good idea to implement it anyway.
UPDATE
You've confirmed HttpContext.Current.User is a RolePrincipal. I suggest you examine it closely using the debugger. In particular examine:
the ProviderName property, which should match the name of your custom RoleProvider.
the Identity property, which should match the name of the current user.
You might also try calling HttpContext.Current.User.IsInRole from code in your controller. The first time this is called, it should call your custom RoleProvider's GetRolesForUser method.
You can also try calling the RolePrincipal.SetDirty() method: this marks the cached role list as having been changed, and the next call to IsInRole or GetRoles should call your custom RoleProvider's GetRolesForUser method again.

Sessions ASP.NET Timeout

I have problems with sessions in asp.net. I searched the web for a while, but couldn't find the reason why it doesn't works. The session disappears after some minutes. It is a project that isn't created by myself, i'm not a hero in aspx. But I'm trying to solve this problem.
Web.config
<system.web>
<authentication mode="Forms">
<forms loginUrl="~/Default.aspx" timeout="120" slidingExpiration="true" />
</authentication>
<customErrors mode="RemoteOnly"/>
<httpRuntime requestValidationMode="2.0"/>
<pages validateRequest="false" />
<sessionState mode="InProc" cookieless="false" timeout="120" />
</system.web>
Checking if Logged in on the pages that you have to be logged in
if (!functions.isLoggedIn(Session))
{
Response.Redirect("Default.aspx");
}
Functions
public static bool isLoggedIn(HttpSessionState session)
{
return session["user"] != null;
}
Not logged in ? Showing login form, filling in the form and then send it to server to check
protected void Page_Load(object sender, EventArgs e)
{
if (Request["do"] != null)
{
switch (Request["do"])
{
case "logout":
Session.Abandon();
break;
}
}
if (Request.ServerVariables["REQUEST_METHOD"].ToLower() == "post")
{
//get username en password
string username = Request["username"];
string password = Request["password"];
if (String.IsNullOrWhiteSpace(username) || String.IsNullOrWhiteSpace(password))
{
LoginMessage.Text = "Please fill in all the fields...";
}
else
{
password = FormsAuthentication.HashPasswordForStoringInConfigFile(
password,
"SHA1");
UserService gs = new UserService();
user g = gs.getUserByLogin(username, password);
if (g == null)
{
//wrong login
LoginMessage.Text = "Invalid username/password.";
}
else
{
//good login
Session["user"] = g;
System.Diagnostics.Debug.WriteLine("timeout:" + Session.Timeout);
Response.Redirect("Home.aspx");
}
}
}
}
GetUserByLogin function in userservice
public user getUserByLogin(string username, string password)
{
user g;
var db = new projectName.Db.Models.projectnetContext();
IQueryable<user> query = from gb in db.users
where gb.username.Equals(username)
&& gb.Passwoord.Equals(password.ToLower())
&& gb.Status == 1
select gb;
if (!query.Any())
g = null;
else
g = query.First();
return g;
}
After login in, creating the session
Session["user"] = g;
My problem is that I have set the time-out. But it doesn't seems to work. If I check the timeout on the server, it is set to 120. But after 2 minutes, I'm redirected to the login form. Can I solve this? If I debug on localhost, It seems to work, but not online.
The login works. The session is set (otherwise I couldn't enter the next pages). If I go to another page (faster then +-5minutes), then I'm still logged in. So the problem is reproductive.
Or if it isn't possible, Cookies? Normally I work with cookies in PHP,.. But is there a way to do it in ASP.NET on a safe way?
Hmm I Recommend you to use profile instead of session in asp .net .
There is two aspects in your scenario. You have the authentication and the session. These are two different things.
Session that you are manage in your web.config stored a value with a timeout of 120 minutes (2 hours)
But Authentication also have a configuration section in web.config.
https://msdn.microsoft.com/en-us/library/532aee0e%28v=vs.85%29.aspx
So what do you want to do exactly first ?
Please find this MVC controller action method sample.
// POST: /Secure/Login
[HttpPost]
[AllowAnonymous]
[ValidateAntiForgeryToken]
public ActionResult Login(LoginFormModel model, string returnUrl)
{
if (ModelState.IsValid)
{
if (Membership.ValidateUser(model.Login, model.Password))
{
using (var db = new DatabaseEntities())
{
var user = db.Users.Single(u => u.Login == model.Login);
Membership.UpdateUser(new MembershipUser("UserMembershipProvider", user.Login, null, null, null, null, true, false, DateTime.MinValue, DateTime.Now, DateTime.MinValue, DateTime.MinValue, DateTime.MinValue));
#region Create Authentication Cookie
Response.Cookies.Add(MyAppFormAuthenticationCookie.Create(user, model.RememberMe));
#endregion
if (!string.IsNullOrWhiteSpace(returnUrl))
{
return Redirect(HttpUtility.UrlDecode(returnUrl));
}
if (model.UserFormType == UserType.Candidate)
{
return RedirectToAction("Index", "Dashboard", new { area = "Candidate" });
}
if (model.UserFormType == UserType.Recruiter)
{
return RedirectToAction("Index", "Dashboard", new { area = "Recruiter" });
}
if (model.UserFormType == UserType.SuperAdmin || model.UserFormType == UserType.Admin)
{
return RedirectToAction("Index", "Dashboard", new { area = "Admin" });
}
}
}
ModelState.AddModelError("", "Incorrect username and/or password");
return View("Index", model);
}
return RedirectToAction("Index", "Home");
}
In this sample, you have :
UPDATE of the user profile to set the last connection date and others if you want ...
CREATION of the authentication cookie in a custom way for this sample
REDIRECTION to the homepage according to the type of user
So, do you have a similar approach to authenticate user in your application ?
EDIT1:
Normally you must finalize authentication process something like this :
var authTicket = new FormsAuthenticationTicket("MyAuthTicket", rememberMe, timeout: 120);
var encryptAuthTicket = FormsAuthentication.Encrypt(authTicket);
Response.Cookies.Add(new HttpCookie(FormsAuthentication.FormsCookieName, encryptAuthTicket) { Expires = authTicket.Expiration });
Just an advice... do you have any re-directions(Response.Redierct) to diff. sites or trying to access the resources for which you don't have access? Session will expire in these cases.

ASP.NET_SessionId + OWIN Cookies do not send to browser

I have a strange problem with using Owin cookie authentication.
When I start my IIS server authentication works perfectly fine on IE/Firefox and Chrome.
I started doing some testing with Authentication and logging in on different platforms and I have come up with a strange error. Sporadically the Owin framework / IIS just doesn't send any cookies to the browsers. I will type in a username and password which is correct the code runs but no cookie gets delivered to the browser at all. If I restart the server it starts working then at some point I will try login and again cookies stop getting delivered. Stepping over the code does nothing and throws no errors.
app.UseCookieAuthentication(new CookieAuthenticationOptions
{
AuthenticationMode = AuthenticationMode.Active,
CookieHttpOnly = true,
AuthenticationType = "ABC",
LoginPath = new PathString("/Account/Login"),
CookiePath = "/",
CookieName = "ABC",
Provider = new CookieAuthenticationProvider
{
OnApplyRedirect = ctx =>
{
if (!IsAjaxRequest(ctx.Request))
{
ctx.Response.Redirect(ctx.RedirectUri);
}
}
}
});
And within my login procedure I have the following code:
IAuthenticationManager authenticationManager = HttpContext.Current.GetOwinContext().Authentication;
authenticationManager.SignOut(DefaultAuthenticationTypes.ExternalCookie);
var authentication = HttpContext.Current.GetOwinContext().Authentication;
var identity = new ClaimsIdentity("ABC");
identity.AddClaim(new Claim(ClaimTypes.Name, user.Username));
identity.AddClaim(new Claim(ClaimTypes.NameIdentifier, user.User_ID.ToString()));
identity.AddClaim(new Claim(ClaimTypes.Role, role.myRole.ToString()));
authentication.AuthenticationResponseGrant =
new AuthenticationResponseGrant(identity, new AuthenticationProperties()
{
IsPersistent = isPersistent
});
authenticationManager.SignIn(new AuthenticationProperties() {IsPersistent = isPersistent}, identity);
Update 1: It seems that one cause of the problem is when I add items to session the problems start. Adding something simple like Session.Content["ABC"]= 123 seems to create the problem.
What I can make out is as follows:
1) (Chrome)When I login I get ASP.NET_SessionId + my authentication cookie.
2) I go to a page that sets a session.contents...
3) Open a new browser (Firefox) and try login and it does not receive an ASP.NET_SessionId nor does it get a Authentication Cookie
4) Whilst the first browser has the ASP.NET_SessionId it continues to work. The minute I remove this cookie it has the same problem as all the other browsers
I am working on ip address (10.x.x.x) and localhost.
Update 2: Force creation of ASPNET_SessionId first on my login_load page before authentication with OWIN.
1) before I authenticate with OWIN I make a random Session.Content value on my login page to start the ASP.NET_SessionId
2) then I authenticate and make further sessions
3) Other browsers seem to now work
This is bizarre. I can only conclude that this has something to do with ASP and OWIN thinking they are in different domains or something like that.
Update 3 - Strange behaviour between the two.
Additional strange behaviour identified - Timeout of Owin and ASP session is different. What I am seeing is that my Owin sessions are staying alive longer than my ASP sessions through some mechanism. So when logging in:
1.) I have a cookied based auth session
2.) I set a few session variables
My session variables(2) "die" before the owin cookie session variable forces re-login, which causes unexpected behaviour throughout my entire application. (Person is logged in but is not really logged in)
Update 3B
After some digging I saw some comments on a page that say the "forms" authentication timeout and session timeout need to match. I am thinking normally the two are in sync but for whatever reason the two are not in sync.
Summary of Workarounds
1) Always create a Session first before authentication. Basically create session when you start the application Session["Workaround"] = 0;
2) [Experimental] if you persist cookies make sure your OWIN timeout / length is longer than your sessionTimeout in your web.config (in testing)
I have encountered the same problem and traced the cause to OWIN ASP.NET hosting implementation. I would say it's a bug.
Some background
My findings are based on these assembly versions:
Microsoft.Owin, Version=2.0.2.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
Microsoft.Owin.Host.SystemWeb, Version=2.0.2.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
OWIN uses it's own abstraction to work with response Cookies (Microsoft.Owin.ResponseCookieCollection). This implementation directly wraps response headers collection and accordingly updates Set-Cookie header. OWIN ASP.NET host (Microsoft.Owin.Host.SystemWeb) just wraps System.Web.HttpResponse and it's headers collection. So when new cookie is created through OWIN, response Set-Cookie header is changed directly.
But ASP.NET also uses it's own abstraction to work with response Cookies. This is exposed to us as System.Web.HttpResponse.Cookies property and implemented by sealed class System.Web.HttpCookieCollection. This implementation does not wrap response Set-Cookie header directly but uses some optimizations and handful of internal notifications to manifest it's changed state to response object.
Then there is a point late in request lifetime where HttpCookieCollection changed state is tested (System.Web.HttpResponse.GenerateResponseHeadersForCookies()) and cookies are serialized to Set-Cookie header. If this collection is in some specific state, whole Set-Cookie header is first cleared and recreated from cookies stored in collection.
ASP.NET session implementation uses System.Web.HttpResponse.Cookies property to store it's ASP.NET_SessionId cookie. Also there is some basic optimization in ASP.NET session state module (System.Web.SessionState.SessionStateModule) implemented through static property named s_sessionEverSet which is quite self explanatory. If you ever store something to session state in your application, this module will do a little more work for each request.
Back to our login problem
With all these pieces your scenarios can be explained.
Case 1 - Session was never set
System.Web.SessionState.SessionStateModule, s_sessionEverSet property is false. No session id's are generated by session state module and System.Web.HttpResponse.Cookies collection state is not detected as changed. In this case OWIN cookies are sent correctly to the browser and login works.
Case 2 - Session was used somewhere in application, but not before user tries to authenticate
System.Web.SessionState.SessionStateModule, s_sessionEverSet property is true. Session Id's are generated by SessionStateModule, ASP.NET_SessionId is added to System.Web.HttpResponse.Cookies collection but it's removed later in request lifetime as user's session is in fact empty. In this case System.Web.HttpResponse.Cookies collection state is detected as changed and Set-Cookie header is first cleared before cookies are serialized to header value.
In this case OWIN response cookies are "lost" and user is not authenticated and is redirected back to login page.
Case 3 - Session is used before user tries to authenticate
System.Web.SessionState.SessionStateModule, s_sessionEverSet property is true. Session Id's are generated by SessionStateModule, ASP.NET_SessionId is added to System.Web.HttpResponse.Cookies. Due to internal optimization in System.Web.HttpCookieCollection and System.Web.HttpResponse.GenerateResponseHeadersForCookies() Set-Cookie header is NOT first cleared but only updated.
In this case both OWIN authentication cookies and ASP.NET_SessionId cookie are sent in response and login works.
More general problem with cookies
As you can see the problem is more general and not limited to ASP.NET session. If you are hosting OWIN through Microsoft.Owin.Host.SystemWeb and you/something is directly using System.Web.HttpResponse.Cookies collection you are at risk.
For example this works and both cookies are correctly sent to browser...
public ActionResult Index()
{
HttpContext.GetOwinContext()
.Response.Cookies.Append("OwinCookie", "SomeValue");
HttpContext.Response.Cookies["ASPCookie"].Value = "SomeValue";
return View();
}
But this does not and OwinCookie is "lost"...
public ActionResult Index()
{
HttpContext.GetOwinContext()
.Response.Cookies.Append("OwinCookie", "SomeValue");
HttpContext.Response.Cookies["ASPCookie"].Value = "SomeValue";
HttpContext.Response.Cookies.Remove("ASPCookie");
return View();
}
Both tested from VS2013, IISExpress and default MVC project template.
In short, the .NET cookie manager will win over the OWIN cookie manager and overwrite cookies set on the OWIN layer. The fix is to use the SystemWebCookieManager class, provided as a solution on the Katana Project here. You need to use this class or one similar to it, which will force OWIN to use the .NET cookie manager so there are no inconsistencies:
public class SystemWebCookieManager : ICookieManager
{
public string GetRequestCookie(IOwinContext context, string key)
{
if (context == null)
{
throw new ArgumentNullException("context");
}
var webContext = context.Get<HttpContextBase>(typeof(HttpContextBase).FullName);
var cookie = webContext.Request.Cookies[key];
return cookie == null ? null : cookie.Value;
}
public void AppendResponseCookie(IOwinContext context, string key, string value, CookieOptions options)
{
if (context == null)
{
throw new ArgumentNullException("context");
}
if (options == null)
{
throw new ArgumentNullException("options");
}
var webContext = context.Get<HttpContextBase>(typeof(HttpContextBase).FullName);
bool domainHasValue = !string.IsNullOrEmpty(options.Domain);
bool pathHasValue = !string.IsNullOrEmpty(options.Path);
bool expiresHasValue = options.Expires.HasValue;
var cookie = new HttpCookie(key, value);
if (domainHasValue)
{
cookie.Domain = options.Domain;
}
if (pathHasValue)
{
cookie.Path = options.Path;
}
if (expiresHasValue)
{
cookie.Expires = options.Expires.Value;
}
if (options.Secure)
{
cookie.Secure = true;
}
if (options.HttpOnly)
{
cookie.HttpOnly = true;
}
webContext.Response.AppendCookie(cookie);
}
public void DeleteCookie(IOwinContext context, string key, CookieOptions options)
{
if (context == null)
{
throw new ArgumentNullException("context");
}
if (options == null)
{
throw new ArgumentNullException("options");
}
AppendResponseCookie(
context,
key,
string.Empty,
new CookieOptions
{
Path = options.Path,
Domain = options.Domain,
Expires = new DateTime(1970, 1, 1, 0, 0, 0, DateTimeKind.Utc),
});
}
}
In your application startup, just assign it when you create your OWIN dependencies:
app.UseCookieAuthentication(new CookieAuthenticationOptions
{
...
CookieManager = new SystemWebCookieManager()
...
});
A similar answer has been provided here but it does not include all of the code-base required to solve the problem, so I see a need to add it here because the external link to the Katana Project may go down and this should be fully chronicled as a solution here as well.
Starting with the great analysis by #TomasDolezal, I had a look at both the Owin and the System.Web source.
The problem is that System.Web has its own master source of cookie information and that isn't the Set-Cookie header. Owin only knows about the Set-Cookie header. A workaround is to make sure that any cookies set by Owin are also set in the HttpContext.Current.Response.Cookies collection.
I've made a small middleware (source, nuget) that does exactly that, which is intended to be placed immediately above the cookie middleware registration.
app.UseKentorOwinCookieSaver();
app.UseCookieAuthentication(new CookieAuthenticationOptions());
Katana team answered to the issue Tomas Dolezar raised, and posted documentation about workarounds:
Workarounds fall into two categories. One is to re-configure
System.Web so it avoids using the Response.Cookies collection and
overwriting the OWIN cookies. The other approach is to re-configure
the affected OWIN components so they write cookies directly to
System.Web's Response.Cookies collection.
Ensure session is established prior to authentication: The conflict between System.Web and Katana cookies is per request, so it may be
possible for the application to establish the session on some request
prior to the authentication flow. This should be easy to do when the
user first arrives, but it may be harder to guarantee later when the
session or auth cookies expire and/or need to be refreshed.
Disable the SessionStateModule - If the application is not relying on session information, but the session module is still setting a
cookie that causes the above conflict, then you may consider disabling
the session state module.
Reconfigure the CookieAuthenticationMiddleware to write directly to System.Web's cookie collection.
app.UseCookieAuthentication(new CookieAuthenticationOptions
{
// ...
CookieManager = new SystemWebCookieManager()
});
See SystemWebCookieManager implementation from the documentation (link above)
More information here
Edit
Below the steps we took to solve the issue. Both 1. and 2. solved the problem also separately but we decided to apply both just in case:
1.
Use SystemWebCookieManager
2.
Set the session variable:
protected override void Initialize(RequestContext requestContext)
{
base.Initialize(requestContext);
// See http://stackoverflow.com/questions/20737578/asp-net-sessionid-owin-cookies-do-not-send-to-browser/
requestContext.HttpContext.Session["FixEternalRedirectLoop"] = 1;
}
(side note: the Initialize method above is the logical place for the fix because base.Initialize makes Session available. However, the fix could also be applied later because in OpenId there's first an anonymous request, then redirect to the OpenId provider and then back to the app. The problems would occur after the redirect back to the app while the fix sets the session variable already during the first anonymous request thus fixing the problem before any redirect back even happens)
Edit 2
Copy-paste from the Katana project 2016-05-14:
Add this:
app.UseCookieAuthentication(new CookieAuthenticationOptions
{
// ...
CookieManager = new SystemWebCookieManager()
});
...and this:
public class SystemWebCookieManager : ICookieManager
{
public string GetRequestCookie(IOwinContext context, string key)
{
if (context == null)
{
throw new ArgumentNullException("context");
}
var webContext = context.Get<HttpContextBase>(typeof(HttpContextBase).FullName);
var cookie = webContext.Request.Cookies[key];
return cookie == null ? null : cookie.Value;
}
public void AppendResponseCookie(IOwinContext context, string key, string value, CookieOptions options)
{
if (context == null)
{
throw new ArgumentNullException("context");
}
if (options == null)
{
throw new ArgumentNullException("options");
}
var webContext = context.Get<HttpContextBase>(typeof(HttpContextBase).FullName);
bool domainHasValue = !string.IsNullOrEmpty(options.Domain);
bool pathHasValue = !string.IsNullOrEmpty(options.Path);
bool expiresHasValue = options.Expires.HasValue;
var cookie = new HttpCookie(key, value);
if (domainHasValue)
{
cookie.Domain = options.Domain;
}
if (pathHasValue)
{
cookie.Path = options.Path;
}
if (expiresHasValue)
{
cookie.Expires = options.Expires.Value;
}
if (options.Secure)
{
cookie.Secure = true;
}
if (options.HttpOnly)
{
cookie.HttpOnly = true;
}
webContext.Response.AppendCookie(cookie);
}
public void DeleteCookie(IOwinContext context, string key, CookieOptions options)
{
if (context == null)
{
throw new ArgumentNullException("context");
}
if (options == null)
{
throw new ArgumentNullException("options");
}
AppendResponseCookie(
context,
key,
string.Empty,
new CookieOptions
{
Path = options.Path,
Domain = options.Domain,
Expires = new DateTime(1970, 1, 1, 0, 0, 0, DateTimeKind.Utc),
});
}
}
Answers have been provided already, but in owin 3.1.0, there is a SystemWebChunkingCookieManager class that can be used.
https://github.com/aspnet/AspNetKatana/blob/dev/src/Microsoft.Owin.Host.SystemWeb/SystemWebChunkingCookieManager.cs
https://raw.githubusercontent.com/aspnet/AspNetKatana/c33569969e79afd9fb4ec2d6bdff877e376821b2/src/Microsoft.Owin.Host.SystemWeb/SystemWebChunkingCookieManager.cs
app.UseCookieAuthentication(new CookieAuthenticationOptions
{
...
CookieManager = new SystemWebChunkingCookieManager()
...
});
If you are setting cookies in OWIN middleware yourself, then using OnSendingHeaders seems to get round the problem.
For example, using the code below owinResponseCookie2 will be set, even though owinResponseCookie1 is not:
private void SetCookies()
{
var owinContext = HttpContext.GetOwinContext();
var owinResponse = owinContext.Response;
owinResponse.Cookies.Append("owinResponseCookie1", "value1");
owinResponse.OnSendingHeaders(state =>
{
owinResponse.Cookies.Append("owinResponseCookie2", "value2");
},
null);
var httpResponse = HttpContext.Response;
httpResponse.Cookies.Remove("httpResponseCookie1");
}
I faced the Similar Issue with Visual Studio 2017 and .net MVC 5.2.4, Updating Nuget Microsoft.Owin.Security.Google to lastest version which currently is 4.0.1 worked for me!
Hope this Helps someone!
The fastest one-line code solution:
HttpContext.Current.Session["RunSession"] = "1";
Just add this line before CreateIdentity method:
HttpContext.Current.Session["RunSession"] = "1";
var userIdentity = userManager.CreateIdentity(user, DefaultAuthenticationTypes.ApplicationCookie);
_authenticationManager.SignIn(new AuthenticationProperties { IsPersistent = rememberLogin }, userIdentity);
I had the same symptom of the Set-Cookie header not being sent but none of these answers helped me. Everything worked on my local machine but when deployed to production the set-cookie headers would never get set.
It turns out it was a combination of using a custom CookieAuthenticationMiddleware with WebApi along with WebApi compression support
Luckily I was using ELMAH in my project which let me to this exception being logged:
System.Web.HttpException Server cannot append header after HTTP
headers have been sent.
Which led me to this GitHub Issue
Basically, if you have an odd setup like mine you will want to disable compression for your WebApi controllers/methods that set cookies, or try the OwinServerCompressionHandler.

ReportViewer - "Unable to serialize the session state. in 'stateserver' and 'sqlserver' mode

I am using VS2010 Report Viewer control in web application. The applications sessionstate mode is set to StateServer as follows
<sessionState timeout="30" mode="StateServer" stateConnectionString="tcpip=127.0.0.1:42424" sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes" cookieless="false" />
The reportviewer control is working fine on my devlopment machine but when the applicaiton is deployed onto server and when the reportviewer control page is loaded the following error is thrown.. All the other pages are working fine.
"Unable to serialize the session state. In 'StateServer' and 'SQLServer' mode, ASP.NET will serialize the session state objects, and as a result non-serializable objects or MarshalByRef objects are not permitted. The same restriction applies if similar serialization is done by the custom session state store in 'Custom' mode."
Can anyone please help, any idea will be of great help..
Thanks in advance.
rptvw.ProcessingMode = ProcessingMode.Remote;
rptvw.ServerReport.ReportServerUrl = new Uri("http://localhost:90/reportserver");
rptvw.ServerReport.ReportPath = string.Format("/Reports/{0}", reportName);
var param = new ReportParameter[4];
param[0] = new ReportParameter("Parameter1", DropDownListCodes.SelectedValue));
param[1] = new ReportParameter("Parameter2", DropDownListQuarters.SelectedValue));
param[2] = new ReportParameter("Parameter3", DropDownListComparators.SelectedValue));
param[3] = new ReportParameter("Parameter4", comptype);
rptvw.ServerReport.SetParameters(param);
rptvw.ServerReport.Refresh();
I managed to get it to work.
I followed this link for my solution msdn link
"When implementing the IReportServerCredentials interface, it is important know that the ReportViewer control stores the instance of the object in ASP.NET session. If the server's ASP.NET session is being stored out of process, such as in Reporting Services, the class must be marked Serializable so that it may be serialized for storage." taken from above link.
Created a new file in App_Code\ReportServerConnection.cs
[Serializable]
public sealed class ReportServerConnection : IReportServerConnection2
{
public bool GetFormsCredentials(out Cookie authCookie, out string userName, out string password, out string authority)
{
authCookie = null;
userName = null;
password = null;
authority = null;
// Not using form credentials
return false;
}
public WindowsIdentity ImpersonationUser
{
// Use the default Windows user. Credentials will be
// provided by the NetworkCredentials property.
get { return null; }
}
public ICredentials NetworkCredentials
{
get
{
// Read the user information from the web.config file. By reading the information on demand instead of
// storing it, the credentials will not be stored in session, reducing the vulnerable surface area to the
// web.config file, which can be secured with an ACL.
// User name
string userName = ConfigurationManager.AppSettings["ReportViewerUser"];
if (string.IsNullOrEmpty(userName))
throw new InvalidOperationException("Please specify the user name in the project's Web.config file.");
// Password
string password = ConfigurationManager.AppSettings["ReportViewerPassword"];
if (string.IsNullOrEmpty(password))
throw new InvalidOperationException("Please specify the password in the project's Web.config file");
// Domain
string domain = ConfigurationManager.AppSettings["ReportViewerDomain"];
if (string.IsNullOrEmpty(domain))
throw new InvalidOperationException("Please specify the domain in the project's Web.config file");
return new NetworkCredential(userName, password, domain);
}
}
public Uri ReportServerUrl
{
get
{
string url = ConfigurationManager.AppSettings["ReportServerUrl"];
if (string.IsNullOrEmpty(url))
throw new InvalidOperationException("Please specify the report server URL in the project's Web.config file");
return new Uri(url);
}
}
public int Timeout
{
// set timeout to 60 seconds
get { return 60000; }
}
public IEnumerable<Cookie> Cookies
{
// No custom cookies
get { return null; }
}
public IEnumerable<string> Headers
{
// No custom headers
get { return null; }
}
}
On the Report.aspx.cs page
protected void Page_Init(object sender, EventArgs e)
{
rptvw.ServerReport.ReportServerCredentials = new ReportServerConnection();
}
Changed this line in the code on the main post
rptvw.ServerReport.ReportServerUrl = rsc.ReportServerUrl;
And in the Web.config
<appSettings>
<add key="ReportViewerServerConnection" value=" App_Code.ReportServerConnection, App_Code"/>
<add key="ReportViewerUser" value="username"/>
<!-- Used as the user name by the ReportServerConnection class. -->
<add key="ReportViewerPassword" value="password"/>
<!-- Used as the password by the ReportServerConnection class. -->
<add key="ReportViewerDomain" value="domainname"/>
<!-- Used as the domain by the ReportServerConnection class. -->
<add key="ReportServerUrl" value="http://localhost:90/reportserver"/>
<!-- Used as the report server URL by the ReportServerConnection class. -->

IsAuthenticated works on browser - but not with Air client!

My login code, after authentication:
var authTicket = new FormsAuthenticationTicket(
1,
userName,
DateTime.Now,
DateTime.Now.AddMinutes(20), // expiry
false,
roles,
"/");
var cookie = new HttpCookie(FormsAuthentication.FormsCookieName, FormsAuthentication.Encrypt(authTicket));
Response.Cookies.Add(cookie);
and, thanks to Darin Dimitrov, I have a custom Authorize attribute:
[AttributeUsage(AttributeTargets.Method | AttributeTargets.Class, Inherited = true, AllowMultiple = true)]
public class TJAuthorize : AuthorizeAttribute {
public override void OnAuthorization(AuthorizationContext filterContext) {
string cookieName = FormsAuthentication.FormsCookieName;
if (!filterContext.HttpContext.User.Identity.IsAuthenticated ||
filterContext.HttpContext.Request.Cookies == null || filterContext.HttpContext.Request.Cookies[cookieName] == null) {
HandleUnauthorizedRequest(filterContext);
return;
}
var authCookie = filterContext.HttpContext.Request.Cookies[cookieName];
var authTicket = FormsAuthentication.Decrypt(authCookie.Value);
string[] roles = authTicket.UserData.Split(',');
var userIdentity = new GenericIdentity(authTicket.Name);
var userPrincipal = new GenericPrincipal(userIdentity, roles);
filterContext.HttpContext.User = userPrincipal;
base.OnAuthorization(filterContext);
}
This all works beautifully when I'm working in a browser session. But now I am working with a Flash/Adobe Air client, and the authentication attribute is causing a failure. By putting debug statements into the code, I can tell that:
filterContext.HttpContext.User.Identity.IsAuthenticated
is false - even after a successful login!
Why should there be any difference between using a browser client and an Air client? And how do I fix this?
EDIT: Another clue: after putting in some more debug statements, I have found that the filterContext.HttpContext.User.Identity is not correctly set when making the call from Air - the Name property comes out blank! Session ID is correct, cookie ID is correct - but the User.Identity is not set. Any ideas why this might be happening?
Perhaps HttpCookieMode (http://msdn.microsoft.com/en-us/library/system.web.httpcookiemode.aspx) is set to the wrong value?
Default is UseDeviceProfile ... what happens when you force it to UseCookies ?
It's a longshot, but IsAuthenticated depends on client's ASPXAUTH cookie (or whatever you've named id) being sent with request. Make sure that flash/air is sending that cookie (by wireshark or any other network tool)
Does the HttpContext.User.Identity show up in the Application_AuthorizeRequest in global.asax?

Resources