12

We have an ASP.NET MVC 5 application that has been using Forms Authentication with sliding expiration. We recently switched to OWIN Cookie Authentication and are experiencing issues with our sessions not extending properly.

Previously, a session could be extended from an AJAX xhr request. With this configuration, however, they are not extending. I'm receiving a 200 for every request (both GET and POST) that should be extending, even after the server has killed the session.

The current setup is:

app.SetDefaultSignInAsAuthenticationType(CookieAuthenticationDefaults.AuthenticationType);

UrlHelper url = new UrlHelper(HttpContext.Current.Request.RequestContext);
app.UseCookieAuthentication(new CookieAuthenticationOptions()
{
   AuthenticationType = "Cookies",
   CookieSecure = CookieSecureOption.SameAsRequest,
   CookieName = Constants.CatalystPortalCookieName,
   LoginPath = new PathString(url.Action(nameof(LoginController.Index), "Login")),
   SlidingExpiration = true,
   ExpireTimeSpan = TimeSpan.FromMinutes(20),
   CookiePath = "/",
});

If I click a link that causes the entire page to be loaded as a document response, however, the server properly extends the session.

rarrarrarrr
  • 1,129
  • 13
  • 18
  • 1
    are you using *session.abandon* to kill session/logout? if so that is not correct way with OWIN. With OWIN you should use AuthenticationManager.SignOut method – Nandip Makwana Oct 19 '15 at 05:05
  • 1
    If you look at the response headers do you see things like no-cache set? If so you may be hitting a cookie conflict issue: http://katanaproject.codeplex.com/wikipage?title=System.Web%20response%20cookie%20integration%20issues – Tratcher Oct 20 '15 at 01:18
  • 1
    It might be worth cracking open [fiddler](http://www.telerik.com/fiddler) and inspecting the requests/responses. – Phil Cooper Oct 21 '15 at 12:30
  • How are you calling the ajax request? Be sure when you use jQuery to specify `cache:false;` – Niels V Oct 25 '15 at 21:20
  • did you ever find answer to this? – Kyle Jan 21 '16 at 10:15
  • @Kyle Check the answer I just posted. – rarrarrarrr Jan 21 '16 at 22:27

1 Answers1

0

I ended up having some faulty assumptions. The AJAX requests were extending. The return of the 200 was throwing me off. After looking with fiddler at the actual response, I saw that with the change to OWIN, the 401 is actually moved in the response:

X-Responded-JSON: {"status":401,"headers":{...foo...}}

So, we ended up just setting the status of the response back to 401. That's probably horrible, but it fit our needs.

protected void Application_EndRequest() {
    var context = new HttpContextWrapper(Context);
    var header = context.Response.Headers["X-Responded-JSON"];
    if (header != null && header.Contains("\"status\":401")) {
        Context.Response.Clear();
        Context.Response.StatusCode = 401;
    }

Here's probably a more robust solution: OWIN: unauthorised webapi call returning login page rather than 401

Community
  • 1
  • 1
rarrarrarrr
  • 1,129
  • 13
  • 18