ASP.net Identity 2.0 not creating a valid authenti

问题:

I am having a problem implementing Microsoft's latest Identity 2.0 in my ASP.net 4.5 Web Forms project. This is my scenario...

I have downloaded the latest Webforms.Samples code from https://aspnet.codeplex.com/SourceControl/latest and pretty much performed a straight port (for the purposes of testing) into my project.

In development, the code/implementation works correctly, when we move to our IIS 7.5 staging server, after a period of time (usually 3 or 4 hours, but varies) the test users experience the following problem...

When they login, the login process appears to run correctly and redirects them back to the specified return url, but the authorisation is not complete/recognised and they get immediately returned back to the login page.

I should say that the login page/process doesn't fail (no errors) and the underlying code return 'success' (as this is the only path that will invoke the redirect), but the actual mechanism appears to be passive. To prove this, I have created a test page that simply echoes the user's identity and even immediately after an apparently successful login, the user identity is anonymous.

The only way I have found of fixing the issue is to restart the web application and again it runs fun for a while.

Can anyone give me any pointers on where I can look to begin to debug this issue or what the cause might be?

Thanks.

回答1:

ASP.NET_SessionId + OWIN Cookies do not send to browser This page seems to provide a workaround to the issue by creating a session on application start up.

回答2:

Starting with this 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.