This project has moved and is read-only. For the latest updates, please go here.

OWIN + IIS working on dev machine but doesn't work when deployed?

Feb 13, 2014 at 4:13 PM
I have a website project integrated with OWIN forms auth & google SSO. Everything works fine locally on my dev machine (with Microsoft.Owin.Host.SystemWeb)

However, when I compiled and deploy the site. The site starts up fine, but when I try to use google SSO, after it is authenticated with google and tries to access the google callback URL of my site (/sigin-google) I'm getting a 404 error. As if the module doesn't get to process the routes.

I've tried adding httpHandler directive in my web.config as suggested in
but after I add the directives my pages becomes blank, for both local dev and compiled site.

Has anyone have any experience with this or suggestion of how to proceed?
Feb 13, 2014 at 5:26 PM
Two options:
  1. I think the config should read key="owin:AppStartup" value="Startup, App_Code" and your startup class should not be in a namespace (i.e. global).
  2. Is your website deployed at the root ( or in a virtual directory ( I've seen a few odd glitches with vdirs.
Feb 13, 2014 at 5:54 PM
  1. I believe the startup is actually run correctly without the assembly name. I've coded so that the google login button only shows up when GetExternalAuthenticationTypes is not null or empty
  2. It is deployed at the root. Oddly enough my dev environment is hosted in a virtual directory and its working correctly.
Feb 13, 2014 at 7:28 PM
I think I've found the reason of getting a blank page for my site when adding

<add name="Owin" verb="" path="" type="Microsoft.Owin.Host.SystemWeb.OwinHttpHandler, Microsoft.Owin.Host.SystemWeb"/>

Basically all requests are being processed by owin and that's it. I need it to process the authentication, but still pass the control over to the aspx pages when that is done. Is this possible?
Feb 13, 2014 at 7:34 PM
Ah, yeah, you don't need to register that handler. Ms.O.H.SystemWeb should auto-register itself.
Feb 13, 2014 at 8:06 PM
That was my understanding as well, however, I can't figure out why the callback paths are returning 404 instead of being processed by the handler.
Feb 15, 2014 at 4:40 PM
So how would I be able to tell if InvokeAsync of the handler is being called or not? Since that's the place where CallbackPath is checked against the request path?
Feb 16, 2014 at 4:22 AM
I added a simple logging to trace to see if request is being passed to OWIN middleware at all when a none existing file path is accessed and noticed a different behavior on local dev site and my deployed site.

accessing /sigin-google

On my local dev site, I can see OWIN middleware being called for processing the request.
While on my deployed site, I don't see the middleware being called and just saw a 404 file not found.

I checked the request filtering on both site, they are exactly the same. any suggestion on where I should check next?
Feb 16, 2014 at 4:26 AM
Make sure all your dependencies are being deployed, especially Microsoft.Owin.Host.SystemWeb.dll.

The folks over in may be able to give you some live help.
Feb 16, 2014 at 4:32 AM
I'm back to square one, I tried adding this line in the web.config

and now my OWIN logging logs the request on deployed machine as well, but it stills shows 404 error....

Wouldn't missing a dependency prevents me to start the site at all? Here's the file I have on my deployed site related to OWIN

Feb 16, 2014 at 5:46 AM
Okay I think I've narrowed it down to the use of external sign in cookie authentication, this is what I have

app.UseCookieAuthentication(new CookieAuthenticationOptions
            AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,
            LoginPath = new PathString("/login"),
            CookieName = AuthCookie.CookieName


Now with runAllManagedModulesForAllRequests="true" and adding logging before each line,
I noticed that when /signin-google is requested, it stops right before the google module is called, so something must be going on at the UseExternalSignInCookie to prevent further processing. Thoughts on why that might be the case?
Feb 16, 2014 at 6:34 PM
Edited Feb 16, 2014 at 6:39 PM
I found the problem!!!

So the problem seems to be that there's no
Set for any other authentication module other than CookieAuthentication.

Not sure if this is a bug or intentional.
But after adding that line, I'm able to login normally on my deployed machine!

So in conclusion, I need to add following into web.config


and add this after all authentication module registration
Any explaination why these two change would be required on one IIS, but not on the other?
Feb 18, 2014 at 5:41 PM
Since I'm only using OWIN for authentication, instead of use runAllManagedModulesForAllRequests, I opted for the following change instead
  1. change and make sure all login path starts with /signin-* (which most already does)
  2. add following configuration to web.config
    <add verb="" path="/signin-" type="Microsoft.Owin.Host.SystemWeb.OwinHttpHandler, Microsoft.Owin.Host.SystemWeb"/>
<add name="Owin" verb="" path="/signin-" type="Microsoft.Owin.Host.SystemWeb.OwinHttpHandler, Microsoft.Owin.Host.SystemWeb"/>
  1. add app.UseStageMarker(PipelineStage.Authenticate); in Startup.Auth.cs
Feb 18, 2014 at 5:46 PM
The stage markers apply to OwinHttpModule, not OwinHttpHandler. With this configuration I think you will double-execute your Startup and middleware (for the Handler and the Module).
Feb 19, 2014 at 4:59 AM
Should I remove OwinHttpModule from the <modules> then? What would the class name be?
Or is there additional setting to ensure that OwinHttpModule is run for all requests (or specifically just the callback requests)?

NOTE: even with app.UseStageMarker(PipelineStage.Authenticate);, I'd need to set runAllManagedModulesForAllRequests="true" to ensure auth modules are all executed.
Feb 20, 2014 at 5:54 PM
You should not need <module> or <handler>, the module auto-registers itself. If you need RAMFAR and stage markers, that's most likely due to a route conflict. IIS's native static file module is very greedy and will bypass ASP.NET entirely for any path that has a match on the file system. Do you have a directory named /signin-?
Feb 22, 2014 at 2:35 PM
Edited Feb 22, 2014 at 2:44 PM
Well, I understand what it suppose to do, but unfortunately it is not doing what it suppose to, otherwise I shouldn't need any of the changes I listed?

No i don't have a folder called /signin-*

Since I'm unable to get module to work properly and forced to register the handlers, is there any way I can remove the module instead to avoid duplicated processing?