Search code examples
asp.netiis-7owingoogle-oauth

What might cause signin-google to return "not found" (UseExternalSignInCookie breaks owin pipeline)?


I need some new ideas for debugging ASP.NET 4.5.2 Identity OWIN. In IIS Exoress on localhost everything works - login works, Microsoft.Owin.Security.Google is configured corrected so it redirects to first signin-google and from there to the page that handles the actual login/signup, but when publishing it to a real IIS (version 7, Windows 2008 server), while normal application login works fine, when trying to login using google, the /signin-google page returns 404 "not found".

I tried placing loggin information in the OWIN pipeline like this (abbreviated):

app.Use(async (Context, next) =>
{
  // code to log "1"
  await next.Invoke();
  // code to log "4"
});   
app.UseExternalSignInCookie(DefaultAuthenticationTypes.ExternalCookie);
// code to log "2"
app.UseGoogleAuthentication(new GoogleOAuth2AuthenticationOptions()
    {
      ClientId = ....,
      ClientSecret = ...
    });
// code to log "3"

On normal page requests the "code to log" will log "1, 2, 3, 4" But on IIS when hitting the /signin-google there is only logged "1, 4" - so I am assuming something in UseExternalSignInCookie causes the pipeline to fail so it never reaches UseGoogleAuthentication (which I assume is the one that catches requests to /signin-google, since the page does not actually exist). The result of OWIN not handling that request is that IIS defaults to returning "Not found" because there is no such static file.

So, does anybody got any idea what might have gotten lost or be different between IIS Express / Visual Studio 2015 where it works, and a staging environment IIS 7.0 on Windows Web Server 2008 SP2?


Solution

  • Okay, based on search for similar problems, there might be a module or handler that - if removed and added again - suddenly will make it work on Windows Server 2008.

    But since Windows Server 2012 have other advantages I will not waste any more time on it, and have instead used this problem as an argument to get new 2012 servers and start the migration of the production environment :-P