I had the OwinStartup configuration code working perfectly and then it stopped working. Unfortunately I'm not sure exactly what I did to get it to stop working and am having a really hard time figuring it out.
To make sure I have the basics covered, I doubled checked to make sure the I have the
[assembly:OwinStartup(typeof(WebApplication.Startup))]
attribute assigned properly and made sure that I don't have an appSetting for owin:AutomaticAppStartup that is set to false so I made one set to true to be safe as there was nothing there before.
<add key="owin:AutomaticAppStartup" value="true" />
I also tried specifically calling out the appSetting:
<add key="owin:appStartup" value="WebApplication.Startup" />
Before it stopped working I upgraded the Microsoft.Owin.Security NuGet packages to 2.0.2, so I tried reverting them to 2.0.1 (that was a pain) but it didn't change anything. I have WebActivator installed on the project and am using that to bootstrap other things but I've tested that on a fresh WebApplication template and it works there so I don't think that is the culprit.
I also tried removing my Startup class and using Visual Studio to add a new one using the OWIN Startup Class type in Add New Item and that isn't getting called either. Next I tried adding a second Startup class since I know it will throw an exception if there is more than one OwinStartup attributes defined, but it isn't throwing any exception there.
Not sure what else to try. Any thoughts?
Update
Turns out that Resharper removed the reference to Microsoft.Owin.Host.SystemWeb when I used it to remove unused references.
Make sure you have installed Microsoft.Owin.Host.SystemWeb package in the project. This package is needed for startup detection in IIS hosted applications. For more information you can refer to this article.
If you've upgraded from an older MVC version make sure you don't have
<add key="owin:AutomaticAppStartup" value="false" />
in your web.config. It will suppress calling the startup logic.
Instead change it to true
<add key="owin:AutomaticAppStartup" value="true" />
I realize you already mentioned this but sometimes people (like me) don't read the whole question and just jump to the answers...
Somewhere along the line - when I upgraded to MVC 5 this got added and I never saw it until today.
Alternative answer to the original problem discussed - Owin "not firing." In my case I spent hours thinking it wasn't firing due to being unable to set a breakpoint in it.
When debugging OWIN startup in visual studio
IIS Express - Running "F5" will break on the OWIN startup code
IIS - Running "F5" will not break until after OWIN (and global.asax) code is loaded. If you attach to W3P.exe you will be able to step into it.
If you are having trouble debugging the code in the Startup class, I have also had this problem - or I thought I did. The code was firing but I believe it happens before the debugger has attached so you cannot set breakpoints on the code and see what is happening.
You can prove this by throwing an exception in the Configuration method of the Startup class.
DEBUGGING TIPS
If debugging does not work try using IIS Express or try the method below for local IIS
Using local IIS
For some reason this method enables debugging of this method:
Request a webpage
Attach to w3wp.exe process
Touch the web.config file
Request a webpage
Extra tip
Maybe doing this will flush a cache:
In web.config add the optimizeCompilations attribute with a false value
<compilation debug="true" ... optimizeCompilations="false">
Run site
Undo the change in web.config
I had a similar issue to this and clearing Temporary ASP.NET Files fixed it. Hope this helps someone.
I had the same problem. Microsoft.Owin.Host.SystemWeb package was installed but during the installation NuGet was not able to add the dll as a reference for some reason. Make sure your project has that reference. If not you can try to reinstall:
update-package Microsoft.Owin.Host.SystemWeb -reinstall
I had an error like below on reinstall but somehow it worked:
System call failed. (Exception from HRESULT: 0x80010100
(RPC_E_SYS_CALL_FAILED))
I had same problem when I added Owin to an existing web project. I eventually found the problem was due to the following in the web.config file.
<assemblies>
<remove assembly="*" />
<add assembly="System.Web.Mvc" />
<add assembly="System.Web.WebPages" />
...
</assemblies>
The remove assembly="*" was causing the problem. When I remove this line the Owin startup code ran.
I eventually change it to the following and it worked perfectly
<assemblies>
<remove assembly="*" />
<add assembly="Microsoft.Owin.Host.SystemWeb" />
<add assembly="System.Web.Mvc" />
<add assembly="System.Web.WebPages" />
<add assembly="System.Web.Helpers" />
...
</assemblies>
In my case this Microsoft.Owin.Host.SystemWeb package is present in the project.
But below two tags are not present in web.config.
<add key="owin:AutomaticAppStartup" value="true" />
<add key="owin:appStartup" value="namespace.className.methodName" />
after adding them it works smoothly.
In my case, the IIS application pool was not set to v4. It was v2.
Changed the AppPool to v4 and everything was okay.
In my case, my web.config had
<authorization>
<allow users="?" />
</authorization>
To force it to fall back to Owin, I needed it to be
<authorization>
<deny users="*" />
</authorization>
I found the following article to be very helpful:
https://weblog.west-wind.com/posts/2015/Apr/29/Adding-minimal-OWIN-Identity-Authentication-to-an-Existing-ASPNET-MVC-Application#MinimalCodeSummary
In my case, I had to set the following before Owin authentication would work instead of windows authentication:
<system.web>
<authentication mode="None" />
<system.web>
This worked for me:
add authentication mode="None"
<system.web>
<compilation debug="true" targetFramework="4.6.1" />
<httpRuntime targetFramework="4.6.1" />
<authentication mode="None" /><!--Use OWIN-->
</system.web>
In my case, my website's output path is changed by somebody, the IIS Express even not load OWIN, and the setup class will not be hit of course. After I set the output path as "bin\", it works well.
I am not sure if this will still help someone, but I've done all of the solutions above (and from some other posts) to no avail.
What fixed the issue on my end was to put a backslash to the end of RedirectUri value in the web.config (crazy, I know!). RedirectUri is a parameter in UseOpenIdConnectAuthentication.
So, instead of:
<add key="ida:RedirectUri" value="https://www.bogussite.com/home" />
Do this:
<add key="ida:RedirectUri" value="https://www.bogussite.com/home/" />
And updated the Reply URL on the Azure App Settings as well.
That somehow made the Startup to run as expected (probably cleared some cache), and the breakpoints are now firing.
FYI. I was modelling my code from here: https://github.com/microsoftgraph/aspnet-connect-sample
After converting a class library to a Web Application Project, I ran into this and became stubborn. Turned out, in my .csProj file, I had this:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
<DebugSymbols>true</DebugSymbols>
<DebugType>full</DebugType>
<Optimize>false</Optimize>
<OutputPath>bin\Debug\</OutputPath>
<DefineConstants>DEBUG;TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<DebugType>pdbonly</DebugType>
<Optimize>true</Optimize>
<OutputPath>bin\Release\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
</PropertyGroup>
thus building the various dll's into a subfolder of the bin-folder (which ifc. won't work). Solution was to change both text-contents for OutputPath to just bin\.
For me it was because they are not in the same namespace. After I remove my AppStart from "project.Startup.AppStart" and let they both Startup.cs and Startup.Auth.cs with "project.Startup" namespace, everything was back to work perfectly.
I hope it help!
If you are seeing this issue with IIS hosting, but not when F5 debugging, try creating a new application in IIS.
This fixed it for me. (windows 10) In the end i deleted the "bad" IIS application and re-created an identical one with the same name.
I think what some people were trying to get to above is that if you want to programatically make your OWIN server "come to life", you'd be calling something like this:
using Microsoft.Owin.Hosting;
IDisposable _server = WebApp.Start<StartupMethod>("http://+:5000");
// Start Accepting HTTP via all interfaces on port 5000
Once you make this call, you will see the call to StartupMethod() fire in the debugger
In case you have multiple hosts using the same namespace in your solution, be sure to have them on a separate IISExpress port (and delete the .vs folder and restart vs).
I messed around with a lot of the suggestions on this post.
I had the following but still could not land on a break point. Throwing an exception proved the code was being entered.
<appSettings>
...
<add key="owin:AutomaticAppStartup" value="true" />
<add key="owin:appStartup" value="SSOResource.Startup, SSOResource" />
...
</appSettings>
Finally out of desperation I looked at project->properties, and then under the WEB section I also checked the NATIVE CODE checkbox (ASP.NET should be already checked).
That finally fixed it for me.
Note : I am using Visual Studio 2017 Professional.
First add the OWIN Auth Class and then enable OWIN:AutomaticAppStartup key in your web.config like
Now it will fire
What happened to our Umbraco instance? It looks like this when I'm logged in, and when I check the browser console I see lots of 500 Internal Server Errors for both the backoffice and the front-end website, with failures for .css and .js files.
I've tried recycling, stopping and starting the app pool, and restarting IIS. I've tried updating the clientDependency version number in clientDependency.config, that didn't work.
I double-checked and I'd added a mime-type via the web.config (in the section), and I'd also added it as a mime type via IIS. This breaks loading of static content, so I defined the mime-type in the web.config only and removed it from IIS, and this fixed the issue.
I tries to load a gif-file and just like ProNotion says:
I found this line in web.config without any remove element:
<mimeMap fileExtension=".woff" mimeType="application/x-font-woff" />
Add change to
<remove fileExtension=".woff" />
<mimeMap fileExtension=".woff" mimeType="application/x-font-woff" />
That fixed the issue for me.
It's likely a permissions problem. I'd suggest that you first need to try and find some detail on the 500 error. Can you inspect it for further detail?
If that doesn't help disable the ClientDependency framework by setting debug="true" on the compilation node of youur web.config file. It's located under the system.web node and looks like this:
<compilation defaultLanguage="c#" debug="true" batch="false" targetFramework="4.0">
If you still have issues after that you can at least browse directly to those resources to view details of the error.
Simon
It is not liking my web config at all. I need to make this change for my REST service so I do not get
IIS specified authentication schemes 'Basic, Anonymous', but the binding only supports specification of exactly one authentication scheme. Valid authentication schemes are Digest, Negotiate, NTLM, Basic, or Anonymous. Change the IIS settings so that only a single authentication scheme is used.
So the change I made is
<system.webServer>
<security>
<authentication>
<anonymousAuthentication enabled="true" />
<basicAuthentication enabled="false" />
</authentication>
</security>
<validation validateIntegratedModeConfiguration="false" />
<modules runAllManagedModulesForAllRequests="true" />
</system.webServer>
And when I try to load the rest service it says
HTTP Error 500.19 - Internal Server Error
The requested page cannot be accessed because the related configuration data for the page is invalid.
This configuration section cannot be used at this path. This happens when the section is locked at a parent level. Locking is either by default (overrideModeDefault="Deny"), or set explicitly by a location tag with overrideMode="Deny" or the legacy allowOverride="false".
Any ideas?
We're using Elmah as our error logging system for an app that will be going into production soon. It's extremely useful, but if it goes into production like this anyone in the world access the error log because all they have to do is visit ourdomain.com/elmah.axd.
This is obviously not ideal. I originally intended to restrict access to that page only to IP addresses within our company, but now our SysAdmins are saying that's not possible. So I'm asking here how can I prevent access to this resource?
We running an ASP.NET MVC app on IIS 6.
The typical scenario for securing elmah.axd is allowing only some authenticated user to be able to access it. But if your site doesn't use any authentication at all this might not be applicable.
Here's what I would recommend you:
Disable completely the elmah.axd handler on your main site
Configure elmah to write the logs to some shared data source (like a shared file, SQLite database or even SQL Server)
Configure a second site in IIS, probably on another network or server, which has only elmah installed and which points to this same shared data source. Now you would always use the second site to read the logs. Obviously the second site would only be accessible to you.
If you decide to use SQL Server you could even read the logs of multiple applications running on multiple web servers in a farm from within a single internal application accessible only to you.
I found this is most acceptable for MVC applications:
http://www.beletsky.net/2011/03/integrating-elmah-to-aspnet-mvc-in.html
You can point the elmah http handler to another url (for example "Secure/elmah.axd") in web.config. You can secure the url as any other asp.net page in the web config.
<httpHandlers>
...
<add verb="POST,GET,HEAD" path="/Secure/elmah.axd" type="Elmah.ErrorLogPageFactory, Elmah" />
</httpHandlers>
<location path="Secure" > <!-- secure the host.com/Secure path -->
<system.web>
<authorization>
<deny users="?" />
<!-- Or anything else... -->
</authorization>
</system.web>
</location>
We are successfully using this approach on IIS7 using active directory membership providers, and it works great. I am not sure if it works on IIS6 though.
If you're using ASP.NET Membership, it's pretty easy to restrict access to the elmah.axd HttpHandler for anonymous users and only allow logged in users in an "Administrators" group. I've done it like this:
<configuration>
...
<location path="elmah.axd">
<system.web>
<authorization>
<allow roles="Administrators"/>
<deny users="*"/>
</authorization>
</system.web>
</location>
</configuration>
Anybody who's logged in AND member of the "Administrators" role can access the page now.
Here are some useful links:
Securely Implement ELMAH For Plug And Play Error Logging
Securing Error Log Pages
If your intention is to disable remote users from accessing it, simply change the value of <security allowRemoteAccess="yes" /> to <security allowRemoteAccess="no" />
I used IP Restrictions from the IIS 7 configuration. By default, you can't simply apply it in <location path="elmah.axd"> because it's locked on the parent configuration level. As such, I created an empty folder "logs" and applied restrictions in IIS to this folder, then modified the location path for the elmah.axd file. That's it! You have remote access to yourdomain.com/logs/elmah.axd, but only from specific IPs.