i have an ASP MVC web site that is published.
and i adjusted <security allowRemoteAccess="yes"/> in webconfig
and now anybody can access Elmah page
by saying that i didnt use ASP.Net Identity,how can i secure ELmah Page?
I wrote a blog post a couple of months ago, that explains everything you need to know: ELMAH security and allowRemoteAccess explained. Basically, you will need to install the Elmah.MVC package and add app settings like this:
<appSettings>
<add key="elmah.mvc.requiresAuthentication" value="true" />
<add key="elmah.mvc.allowedRoles" value="Admin" />
<add key="elmah.mvc.allowedUsers" value="Thomas" />
</appSettings>
I'm developing an ASP.NET MVC application, and when I run it from VS, if I let the browser sit on a page for a short time like 45 seconds, and then try to take some action, the request never makes it to my controller. Everything functions as expected if I don't wait at all before making a navigation/request. This problem has existed for the life of the project.
The IIS Express logs do not show any requests when this happens; however, in debug mode, VS can see that the browser did make a request. No breakpoints inside of the ActionResult get hit though, so I know it isn't getting called. The browser's debug tools show the request sitting in the pending state forever. The website is still running though, IIS doesn't crash. I can open another browser and access the login page, however, the POST doesn't fire the controller action.
This happens on every machine and with every browser. I've scoured the web and couldn't find others with my problem. My webconfig and applicationHosts look like the default generated ones, except for some forms auth settings.
<appSettings>
<add key="webpages:Version" value="3.0.0.0" />
<add key="webpages:Enabled" value="false" />
<add key="ClientValidationEnabled" value="true" />
<add key="UnobtrusiveJavaScriptEnabled" value="true" />
<add key="PreserveLoginUrl" value="true" />
</appSettings>
<system.web>
<compilation debug="true" targetFramework="4.6.1" />
<httpRuntime targetFramework="4.6.1" requestValidationMode="2.0" />
<authentication mode="Forms">
<forms slidingExpiration="true" timeout="60" loginUrl="~/Account/LogIn" />
</authentication>
Turns out the issue was a loader lock being made by a thread that was dying (terminated?) before it could release the lock. This lock would block any threads handling HTTP requests. Application Insights appeared in the callstack for the problematic thread, and after disabling it, the problem no longer occurs.
I have the following configuration in my "web.config":
<customErrors mode="Off">
</customErrors>
<compilation debug="true" targetFramework="4.5" />
<httpRuntime targetFramework="4.5" />
<pages>
<namespaces>
<add namespace="System.Web.Helpers" />
<add namespace="System.Web.Mvc" />
<add namespace="System.Web.Mvc.Ajax" />
<add namespace="System.Web.Mvc.Html" />
<add namespace="System.Web.Routing" />
<add namespace="System.Web.WebPages" />
</namespaces>
</pages>
If I have a mistake in my environment clearly shows errors, but when I upload it to windows azure shows the screen where it tells me that I have to put:
<customErrors mode="Off" />
or
<customErrors mode="RemoteOnly" redirectMode="~/file.html" />
and not shows errors. Is there some extra settings that I have to do in "web.config" in "ASP.NET MVC 5" to show the errors?
The default for publishing to Azure is to use the Release configuration. The Release configuration, among other things, disables the yellow screen of death you see in development, because this is information that 1) is potentially dangerous if seen by the wrong person (malicious) and 2) is not user-friendly for the casual user.
If you want to see the errors, then you follow the advice on that page. If your problem is that you have done that, and the errors still aren't showing then #Zabavsky, is probably right; you didn't add it to the configuration that it was deployed with (most likely Release).
However, I would caution you from actually doing that. Like I said earlier, the stack trace shown on error can potentially contain sensitive information that a malicious user could use to compromise your site, and if you turn it on in Release, even if just for a little while to debug, there's a good chance you might forget to turn it off. The ideal is to work out all your bugs in development. For the final verification when deploying to Azure, you can deploy using the Debug configuration (which will show the errors) to a staging version of your site. Then, once everything is good, you can do the final deployment using the Release configuration, instead.
If you want to get the stack trace from errors in production on an ongoing basis, your best bet is to use a tool like ELMAH, which will log exceptions that occur and present them to you in a protected way. By default, that will be only over localhost, which would require that you browse from within the server the site is running on. If you can't do that because you're just using an Azure Website instead of a virtual machine, then you can also enable access to a certain user role, or only via a certain IP (your static IP).
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
I have a basic MVC site built on Umbraco 6.1.2 and hosted with 1&1 (1and1) using their shared Windows hosting.
The site works perfectly on my local machine but once deployed it throws an encoding error on Firefox, Chrome and IE (other browsers untested, but I assume this will affect all browsers). The back office is accessible and I am able to log in and navigate through the content tree, it is just the rendering of the site content using MVC and Razor which appears to be affected by the problem.
I disabled gzip in Firefox (using this method: http://forgetmenotes.blogspot.co.uk/2009/05/how-to-disable-gzip-compression-in.html) and the website worked as expected, therefore I can only assume that this is an issue with 1&1's gzip configuration.
Has anybody had the same issue? Is it related to Umbracp or has anyone seen the same problem with standard MVC applications?
You should probably enable gzip in your web.config
<system.webServer>
<httpCompression directory="%SystemDrive%\inetpub\
temp\IIS Temporary Compressed Files">
<scheme name="gzip" dll="%Windir%\system32\inetsrv\gzip.dll"/>
<dynamicTypes>
<add mimeType="text/*" enabled="true"/>
<add mimeType="message/*" enabled="true"/>
<add mimeType="application/javascript" enabled="true"/>
<add mimeType="*/*" enabled="false"/>
</dynamicTypes>
<staticTypes>
<add mimeType="text/*" enabled="true"/>
<add mimeType="message/*" enabled="true"/>
<add mimeType="application/javascript" enabled="true"/>
<add mimeType="*/*" enabled="false"/>
</staticTypes>
</httpCompression>
<urlCompression doStaticCompression="true" doDynamicCompression="true"/>
</system.webServer>
There are a few more tricks here
Setting the gzip compression in asp.net
I have found the cause of the problem. I commented out all references to ClientDependency in the Web.config and now my site runs as expected. It seems as though that module is attempting to compress content but failing. This forum post helped locate the issue: http://our.umbraco.org/forum/ourumb-dev-forum/bugs/13525-Client-Dependency-Module-playing-havoc-with-gzip-content-compression
This causes some problems with the core product and is therefore not a fix, it does however give us a starting point for investigations into how the problem can be resolved.
I have updated the Umbraco issue tracker with this information. For those who are interested see here: http://issues.umbraco.org/issue/U4-2203