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.

6
  • 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 Commented Oct 19, 2015 at 5: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: katanaproject.codeplex.com/… Commented Oct 20, 2015 at 1:18
  • 1
    It might be worth cracking open fiddler and inspecting the requests/responses. Commented Oct 21, 2015 at 12:30
  • How are you calling the ajax request? Be sure when you use jQuery to specify cache:false; Commented Oct 25, 2015 at 21:20
  • did you ever find answer to this? Commented Jan 21, 2016 at 10:15

1 Answer 1

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

Sign up to request clarification or add additional context in comments.

Comments

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.