How do I make ImageResizer ignore ASP.NET Forms Authentication rules? - forms-authentication

We're building a web application that is secured using Forms Authentication. On a certain page, we have a list of thumbnails. These thumbnails are generated with ImageResizer like this:
<img src="/Data/Pictures/image01.jpg?width=100" />
This was all working fine during development using the built in web server of Visual Studio 2010. When we deployed the application to our production server (running Windows 2008 and IIS 7.5) we noticed the thumbnails weren't working anymore. When switching our development build to IIS Express instead of Cassini, we had the same problem.
When navigating to /Data/Pictures/image01.jpg directly (when logged in), we can see the image.
When navigating to /Data/Pictures/image01.jpg?width=100 directly (when logged in), we get this error message:
Server Error in '/' Application.
This type of page is not served.
Description: The type of page you have requested is not served because it has been explicitly forbidden. The extension '.jpg' may be incorrect. Please review the URL below and make sure that it is spelled correctly.
Requested URL: /Data/Pictures/image01.jpg
When navigating to /Data/Pictures/image01.jpg.ashx?width=100 directly (when logged in), we can see the resized image.
A workaround for the problem was excluding the pictures directory from Forms Authentication like this:
<location path="Data/Pictures">
<system.web>
<authorization>
<allow users="*" />
</authorization>
</system.web>
</location>
Now the thumbnails are visible again, but I don't feel quite right about this workaround.
I have sumbitted a support ticket on the site of the ImageResizer and asked why images without a querystring work and the ones with a querystring don't. The author of ImageResizer replied and he told me:
Because the ImageResizer doesn't handle non-processed images, those are
handled by IIS. You need to duplicate your rules in to
protect static content: http://www.iis.net/ConfigReference/system.webServer/security/authorization
I have read that page and I have tried to duplicate our authentication and authorization settings to the <security> element inside <system.webServer> but I wasn't able to solve it this way.
What can we do to solve this problem?
Update
I have deployed the application to two of our production servers and they both have the same issue. We also have the issue on two developer machines in IIS Express. Our production servers aren't necessarily indentical in configuration (I'm not sure of this, but I assume there have to be some minor differences). So I guess (actually, I hope :-)) the cause can be found in the Web.Config file below:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<configSections>
<section name="entityFramework" type="System.Data.Entity.Internal.ConfigFile.EntityFrameworkSection, EntityFramework, Version=4.3.1.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
<sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
<section name="MyApp.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
</sectionGroup>
<section name="resizer" type="ImageResizer.ResizerSection" />
<section name="dotless" type="dotless.Core.configuration.DotlessConfigurationSectionHandler, dotless.Core" />
</configSections>
<connectionStrings>
<add name="MyAppContext" connectionString="xxx" providerName="System.Data.SqlClient" />
</connectionStrings>
<system.web>
<pages validateRequest="false" />
<httpRuntime requestValidationMode="2.0" />
<globalization requestEncoding="utf-8" responseEncoding="utf-8" culture="nl-BE" uiCulture="nl-BE" />
<authentication mode="Forms">
<forms loginUrl="~/Default.aspx" timeout="480" />
</authentication>
<authorization>
<deny users="?" />
</authorization>
<compilation debug="true" targetFramework="4.0" />
</system.web>
<entityFramework>
<defaultConnectionFactory type="System.Data.Entity.Infrastructure.SqlConnectionFactory, EntityFramework">
<parameters>
<parameter value="Data Source=.\SQLEXPRESS; Integrated Security=True; MultipleActiveResultSets=True" />
</parameters>
</defaultConnectionFactory>
</entityFramework>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Yahoo.Yui.Compressor" publicKeyToken="f8b4b81ec75097e2" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-1.7.1.0" newVersion="1.7.1.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="AjaxMin" publicKeyToken="21ef50ce11b5d80f" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.51.4507.18296" newVersion="4.51.4507.18296" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="dotless.Core" publicKeyToken="96b446c9e63eae34" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-1.3.0.3" newVersion="1.3.0.3" />
</dependentAssembly>
</assemblyBinding>
</runtime>
<system.webServer>
<validation validateIntegratedModeConfiguration="false" />
<modules>
<add name="ImageResizingModule" type="ImageResizer.InterceptModule" />
</modules>
<handlers>
<add name="dotless" path="*.less" verb="GET" type="dotless.Core.LessCssHttpHandler,dotless.Core" resourceType="File" preCondition="" />
</handlers>
</system.webServer>
<location path="Assets">
<system.web>
<authorization>
<allow users="*" />
</authorization>
</system.web>
</location>
<location path="Data/Pictures">
<system.web>
<authorization>
<allow users="*" />
</authorization>
</system.web>
</location>
<dotless minifyCss="false" cache="true" web="false" />
</configuration>

ImageResizer is designed to integrate properly with ASP.NET URL authorization in the default install of IIS 5, IIS 5.1, IIS 6, IIS 7, IIS 7.5, Cassini, and IIS Express.
However, there are at least a dozen permutations available on IIS7 & IIS 7.5. You can selectively install or uninstall, (as well as enable or disable) the IIS 6 Legacy, IIS 7, ASP.NET 2, and ASP.NET 4 Url Authorization modules. And there's integrated mode or classic mode. And in classic mode, it's all extension-based, meaning they could be customized or there could be a wildcard mapping. Then there is the RAMMFAR attribute, RunAllManagedModulesForAllRequests. Also, you can set preconditions on the several individual UrlAuthorizationModules to control which extensions they execute for. Each of these variables affects which of the 4 URL Authorization engines control which file types, and one or more of these variables is set up wrong.
Now, on a clean install, ImageResizer can ensure everything is handled properly; all images go under ASP.NET rule, following the ASP.NET Authentication and Authorization rules. But there are an awful lot of ways mess up Url Authorization, and without knowing what modules are installed and enabled in IIS, and seeing a full copy of your Web.config, I can't know why ASP.NET UrlAuthorization isn't getting applied consistently.
ImageResizer acts minimalistically - unless an image has a querystring, and that querystring has recognized commands, ImageResizer will not do anything to it. Thus, only processed images are being 'forced' to follow the ASP.NET Url Authorization rules.
By default, the untouched requests (without querystring commands) should be following the ASP.NET rules as well, assuming you're running in Integrated mode. However, something is wrong with your install or configuration. "This type of page is not served." is a known 403 message for IIS, but it also typically means things aren't configured correctly. The fact that static files aren't following the ASP.NET rules is another indicator of a configuration issue.
An easy way to verify it's a OS/IIS configuration issue would be to start up a labslice virtual machine (Only costs a quarter), and put your software on there. If you see the problem again, you know it's in Web.config. If not, it's IIS/Machine.config or OS level.
You've already stated one solution - add URL Authorization exceptions for images so ImageResizer doesn't require authentication to display them.

I had similar problem: Image Resizer worked fine on local but not on server. It was because classic pipeline is used on this project. My solution:
Add this the Web.config
<resizer>
<pipeline fakeExtensions=".axd" defaultCommands="autorotate.default=true"/>
<plugins>
<add name="DiskCache" />
<add name="PrettyGifs" />
<add name="MvcRoutingShim" />
</plugins>
</resizer>
..
<system.webServer>
<validation validateIntegratedModeConfiguration="false" />
<modules>
<!-- This is for IIS7/8 Integrated mode -->
<add name="ImageResizingModule" type="ImageResizer.InterceptModule"/>
</modules>
</system.webServer>
and add this to the image links :
+ ".axd?height=165&width=297&mode=crop";

Related

IIS Management User Login Fails on 7.5 / Works on 8.5

I have a small, simple ASP.Net 4.5.2 Web App for which access is restricted by IIS Manager Users. The parent site is public (Allow Anon / All Users) and the app has all authentication disabled and the IIS User added at server level, and under IIS Authorization Rules as seen in the config below. This works perfectly on IIS 8.5, but the login fails on 7.5 with 401 Unauthorized.
I've combed through the role features and site and server and app settings and I can't find a difference between the two, other than 7.5 on Win Server 2008 vs. 8.5 on Win Server 2012-R2. Both have IIS Management Service running with Windows and IIS Manager Users selected, and the Enable remote connections unchecked (only using it for app access, not administration). Both are using the ASP.Net 4.0 App pool under Network Service, who has full rights to the web folder structures on both servers.
Ideas on what to look for would be appreciated.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.web>
<compilation strict="false" explicit="true" debug="false" targetFramework="4.5.2" />
<customErrors mode="Off" />
<httpRuntime targetFramework="4.5.2" />
<webServices>
<protocols>
<add name="HttpGet" />
<add name="HttpPost" />
</protocols>
</webServices>
</system.web>
<system.webServer>
<handlers>
<add verb="GET,POST" name="About" type="MyApp.About" path="About" />
</handlers>
<modules>
<!-- Replaces Global.asax -->
<add name="AppModule" type="MyApp.AppModule" />
<!-- Required for IIS Manager Users to browse the site -->
<add name="WebManagementBasicAuthentication" type="Microsoft.Web.Management.Server.WebManagementBasicAuthenticationModule, Microsoft.Web.Management, Version=7.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
</modules>
<defaultDocument enabled="false">
<files>
<clear />
</files>
</defaultDocument>
<directoryBrowse enabled="false" />
<security>
<authorization>
<clear />
<remove users="*" />
<add accessType="Allow" users="IIS.Manager.Username.Here" />
</authorization>
</security>
</system.webServer>
</configuration>
Finally found that on the newly spun up 2008 / IIS 7.5 server Network Service didn't have Read permissions to c:\Windows\System32\inetsrv\.

Enabling PUT on IIS 7.5 for an ASHX handler using Windows Authentication

I have an ASP.NET (.NET 4) website that uses http PUT for an .ashx generic handler. The PUT call originates from a Silverlight front end. All works in VS 2010 on my local machine (Cassini web server).
Then I deployed to an IIS7.5 Win Server 2008 R2 box.
The silverlight/website is fine, but PUT calls to the .ashx handler are met with a Windows Login Prompt.
This is a local intranet so Windows Authentication (with NTLM & Negotiate providers) is the only enabled authentication.
Then I read this: http://blogs.msdn.com/b/joseph_fultz/archive/2009/07/23/enabling-the-put-verb-with-handlers-and-iis-7-0.aspx
I've followed his suggestion and I can now make PUT calls via my .ashx handler. Problem is only folks in the Administrators Group of the web server can do this. No one else can. They are met with the windows login prompt.
Any idea what this could be?
I can't give Everyone in the company Admin privileges on the webserver. They would no doubt cut off one of my hands, eat said hand in front of me, and then show me the door.
Ok I figured it out.
Here are the key configuration elements in IIS 7.5:
Under Windows Authentication / Providers - NTLM had to be on top of Negotiate
Domain Users needed write access to the directory containing the ashx handler
URL Authorization was not enabled as a role on the web server. I added it and then stuck this in the web.config under system.webServer:
<security>
<authorization>
<remove users="*" roles="" verbs="" />
<add accessType="Allow" users="*" verbs="GET,HEAD,POST,PUT,DELETE,DEBUG" />
</authorization>
</security>
(I'll trim that down a bit, but for now it works)
My entire system.webServer element is as follows:
<system.webServer>
<modules>
<remove name="WebDAVModule" />
</modules>
<defaultDocument>
<files>
<clear />
<add value="default.aspx" />
</files>
</defaultDocument>
<handlers accessPolicy="Read, Write, Execute, Script">
<remove name="WebDAV" />
<remove name="SimpleHandlerFactory-Integrated-4.0" />
<remove name="SimpleHandlerFactory-Integrated" />
<add name="SimpleHandlerFactory-Integrated" path="*.ashx" verb="GET,HEAD,POST,DEBUG,PUT" type="System.Web.UI.SimpleHandlerFactory" resourceType="Unspecified" requireAccess="Write" preCondition="integratedMode" />
<add name="SimpleHandlerFactory-Integrated-4.0" path="*.ashx" verb="GET,HEAD,POST,DEBUG,PUT" type="System.Web.UI.SimpleHandlerFactory" resourceType="Unspecified" requireAccess="Write" preCondition="integratedMode,runtimeVersionv4.0" />
</handlers>
<security>
<authorization>
<remove users="*" roles="" verbs="" />
<add accessType="Allow" users="*" verbs="GET,HEAD,POST,PUT,DELETE,DEBUG" />
</authorization>
</security>
</system.webServer>
That did it.

IIS7 Forms Authentication Doesn't Deny Image Access

I have a basic ASP.NET website set up in IIS7 with forms authentication enabled on the server. Just for grins, I deny everyone:
<?xml version="1.0"?>
<configuration>
<system.web>
<authentication mode="Forms">
<forms name=".ASPXAUTH" loginUrl="Login.aspx" defaultUrl="Test.aspx" protection="All" timeout="30" path="/" requireSSL="false" slidingExpiration="true"/>
</authentication>
<authorization>
<deny users="*"/>
</authorization>
<compilation debug="true"/>
</system.web>
</configuration>
When I visit the default.aspx page, I get dutifully redirected to the Login.aspx page. However, I can browse to a .txt file or .png file on the root of the same site, and it displays it with no challenge.
This is odd, because in the Cassini dev server, access to those files is blocked. This only occurs once I publish to my IIS7 server.
I must be missing something in IIS7, but I can't figure it out for the life of me.
I have the site on it's own .NET 4.0 app pool with integrated mode enabled.
Forms Authentication is enabled at the server
On the Edit managed Module popup for the FormsAuthentication module, I tried unchecking the "invoke only for requests...", but that tosses some kind of strange error when I do so (assembly of some sort missing? This is a fresh server install with no frills, so I can't imagine what that's about).
Can anyone point me in the right direction on this?
Thanks!
Droidilate
first of all you have to use integrated pipeline and then add this in your web.config:
<system.webServer>
<modules runAllManagedModulesForAllRequests="false">
<remove name="FormsAuthenticationModule" />
<add name="FormsAuthenticationModule" type="System.Web.Security.FormsAuthenticationModule" />
<remove name="UrlAuthorization" />
<add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" />
</modules>
</system.webServer>

Deploying website: 500 - Internal server error

I am trying to deploy an ASP.NET application. I have deployed the site to IIS, but when visiting it with the browser, it shows me this:
Server Error
500 - Internal server error.
There is a problem with the resource you are looking for, and it cannot be displayed.
After fiddling around with the web.config, I got:
The page cannot be displayed because an internal server error has occurred.
How can I see the actual issue behind this server error?
First, you need to enable and see detailed errors of your web messages, because this is a general message without giving information on what's really happening for security reasons.
With the detailed error, you can locate the real issue here.
Also, if you can run the browser on the server, you get details on the error, because the server recognizes that you are local and shows it to you. Or if you can read the log of the server using the Event Viewer, you also see the details of your error.
###On IIS 6
<configuration>
<system.web>
<customErrors mode="Off"/>
<compilation debug="true"/>
</system.web>
</configuration>
###On IIS 7
<configuration>
<system.webServer>
<httpErrors errorMode="Detailed" />
<asp scriptErrorSentToBrowser="true"/>
</system.webServer>
<system.web>
<customErrors mode="Off"/>
<compilation debug="true"/>
</system.web>
</configuration>
Note: You can avoid the Debug=true. You only need to close the custom errors for a while and get the detailed error page.
This can help: How to enable the detailed error messages (from IIS).
I was pulling my hair out over this issue. Making sure the following entry was in the root web.config file fixed it for me:
<configuration>
<system.webServer>
<validation validateIntegratedModeConfiguration="false" />
</system.webServer>
</configuration>
Remember that you have to add this to the existing XML elements, if they're already there. You can't just add at the end of the file, because you can't have multiple copies of any element.
For me, the following code in the web.config was the culprit. When I removed it, the web site worked fine.
<staticContent>
<mimeMap fileExtension=".mp4" mimeType="video/mp4" />
</staticContent>
I finally solved this "500 Internal server" error when deploying the ASP.NET MVC 3.0 application on godaddy.ocm shared hosting.
somehow there were discrepancies on the version of DLL files referenced and version mentioned in file web.config.
I tried all the options mentioned in various forum. Nothing helped, although everyone suggested the same kind of fix, but somehow it didn't work in my scenario. Finally after banging my head for two days.
I decided to delete all DLL file reference and delete web.cofig (make a local copy) from the project and let the application throw the error and then add the DLL files one by one making copy to local=true.
After all the DLL files were added, I created a new ASP.NET MVC application and copied the web.config of new application to my actual application.
So my actual application now has a new web.config, and then I copied the connectionstring and other references from the local copy of web.config that I saved.
I just compiled the application and published to a local folder
and FTP the published folder to goDaddy.
It worked and finally my problem was solved.
In my case, I put a mistake in my web.config file. The application key somehow was put under the <appSettings> tag. But I wonder why it doesn't display a configuration error. The error 500 is too generic for investigating the problem.
My first attempt to publish and then run a very simple site serving only HTML produced "The page cannot be displayed because an internal server error has occurred."
The problem: I had the site set to .NET 3.5 in Visual Studio (right click web site project -> Property Pages -> Build), but had the Web Site in Azure configured as .NET 4.0. Oops! I changed it to 3.5 in Azure, and it worked.
In addition to the other suggestions, make sure to change the existingResponse attribute of the httpErrors node to Auto from Replace, or to remove that property entirely.
<httpErrors existingResponse="Replace" />
^^^^^^^ not going to work with this here
Server Error 500 - Internal server error.
There is a problem with the resource you are looking for, and it cannot be displayed. Goddady. Hosting - Web - Economy - Windows Plesk
In my case, I replace this code:
<configuration>
<system.webServer>
<httpErrors errorMode="Detailed" />
<asp scriptErrorSentToBrowser="true"/>
</system.webServer>
<system.web>
<customErrors mode="Off"/>
<compilation debug="true" targetFramework="4.0"/>
</system.web>
</configuration>
Then change framework 3.5 to framework 4. It shows my detailed error. I delete code in:
<httpModules></httpModules>
It solved my problem.
IIS also reports status code 500 without any event log hints if there are insufficient permissions on the physical home directory (i.e. IIS_IUSRS has no access).
For IIS 10 There is a extra step to do other than changing the customErrors=Off to show the error content.
<system.web>
<customErrors mode="Off" />
</system.web>
<system.webServer>
<httpErrors existingResponse="PassThrough" errorMode="Detailed"/>
</system.webServer>
Raul answered the question in this link Turn off IIS8 custom errors by Raul
Probably your web.config file is wrong or is missing some tag. I solved my problem using the correct config tags for .NET 4.
<system.web>
<compilation debug="true" strict="false" explicit="true" targetFramework="4.0">
<assemblies>
<add assembly="System.Deployment, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A"/>
<add assembly="System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
<add assembly="System.Configuration, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A"/>
<add assembly="System.Data, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
<add assembly="System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
<add assembly="System.Drawing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A"/>
<add assembly="System.Web.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A"/>
<add assembly="System.Xml, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
<add assembly="System.Transactions, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
</assemblies>
</compilation>
<pages controlRenderingCompatibilityVersion="3.5" clientIDMode="AutoID">
<namespaces>
<clear/>
<add namespace="System"/>
<add namespace="System.Collections"/>
<add namespace="System.Collections.Specialized"/>
<add namespace="System.Configuration"/>
<add namespace="System.Text"/>
<add namespace="System.Text.RegularExpressions"/>
<add namespace="System.Web"/>
<add namespace="System.Web.Caching"/>
<add namespace="System.Web.SessionState"/>
<add namespace="System.Web.Security"/>
<add namespace="System.Web.Profile"/>
<add namespace="System.Web.UI"/>
<add namespace="System.Web.UI.WebControls"/>
<add namespace="System.Web.UI.WebControls.WebParts"/>
<add namespace="System.Web.UI.HtmlControls"/>
</namespaces>
</pages>
<authentication mode="None"/>
</system.web>
I realized the permissions for the files and folders in your server also matter. I uploaded my files from a linux operating system and usually the permissions are limited for read and write. So when uploaded, the permission are still same as in the local machine.
I had the same error and i just changed the permissions for the folder i had uploaded and the error was gone.
Hope it helps someone.
500 Internal Error
Windows Hosting Error
Godaddy Hosting issue
I have been facing the same issue, but now my issue has been resolved. Always use in this hosting this it works.
I will also recommend you all to do whatever changes you are looking to make in your web.config file. Please do it one by one and test the same on the live domain so that you can find the exact problem or the features that your hosting provider does not allow you to use.
<?xml version="1.0"?>
<configuration>
<system.web>
<trust level="Medium"/>
<compilation debug="true" targetFramework="4.5">
<assemblies>
<add assembly="System.Data.Linq, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
</assemblies>
</compilation>
<httpRuntime targetFramework="4.5" />
<sessionState mode="InProc" cookieless="false" timeout="90" />
<authentication mode="Forms">
<forms loginUrl="default.aspx"
defaultUrl="default.aspx"
protection="All"
cookieless="UseCookies"
slidingExpiration="false"
timeout="30"
name="aeon.corpusjuris.in" />
</authentication>
<customErrors
mode="Off"
defaultRedirect="errorpage.aspx">
<error statusCode="403" redirect="errorpage.aspx"/>
<error statusCode="404" redirect="errorpage.aspx"/>
</customErrors>
<!-- <httpModules>
<add name="HTTPCaching" type="HTTPCaching"/>
</httpModules>
-->
</system.web>
<runtime>
<performanceScenario value="HighDensityWebHosting" />
</runtime>
<system.webServer>
<!-- <modules runAllManagedModulesForAllRequests="true">
<add name="HTTPCaching" type="HTTPCaching"/>
</modules>
-->
<defaultDocument>
<files>
<clear />
<add value="default.aspx" />
</files>
</defaultDocument>
<httpErrors errorMode="Detailed" />
<asp scriptErrorSentToBrowser="true"/>
<staticContent>
<clientCache cacheControlCustom="public"
cacheControlMaxAge="60:00:00"
cacheControlMode="UseMaxAge" />
</staticContent>
</system.webServer>
<system.web.extensions>
<scripting>
<webServices>
<jsonSerialization maxJsonLength="90000000">
</jsonSerialization>
</webServices>
</scripting>
</system.web.extensions>
</configuration>
If you're using a custom HttpHandler (i.e., implementing IHttpModule), make sure you're inspecting calls to its Error method.
You could have your handler throw the actual HttpExceptions (which have a useful Message property) during local debugging like this:
public void Error(object sender, EventArgs e)
{
if (!HttpContext.Current.Request.IsLocal)
return;
var ex = ((HttpApplication)sender).Server.GetLastError();
if (ex.GetType() == typeof(HttpException))
throw ex;
}
Also make sure to inspect the Exception's InnerException.
500 internal server error can arise due to several reasons. First reason might be that web.config file is not properly created, means you have missed some tag in the web.config file. Secondly this error can be due to some code problem. To check which component of the web application is causing this error you can check Application setting in web.config file. The detail of solving and tracing 500 internal server error with diagram is given here:
Make sure your account uses IIS 7. For more information, see Customizing IIS Settings on Your Windows Hosting Account.
Follow the instructions in Changing Pipeline Mode on Your Windows IIS 7 Hosting Account. Select Integrated Pipeline Mode.
In your Project References section, set Copy Local to True for the following assemblies:
System.Web.Abstractions
System.Web.Helpers
System.Web.Routing
System.Web.Mvc
System.Web.WebPages
Add the following assemblies to your project, and then set Copy Local to True:
Microsoft.Web.Infrastructure
System.Web.Razor
System.Web.WebPages.Deployment
System.Web.WebPages.Razor
Publish your application.
Sometimes, the reason might be one of your .dll assemblies is not registered correctly on the server.
For example, you can successfully run a C# Excel web application on your local machine with Office installed, while getting the 500 error on server deployment, because there is no Office suite installed on the server, and thus you get the server error.
For those who have this possibility (VPS hosting not web hosting):
Connect to your hosting server via Remote Desktop. Open Web Browser from your remote desktop and you will see the detail description of the error.
You don't need to modify web.config or expose any details to anybody else.
If you are using IIS 8.5 it may be that you need to change the ApplicationPool ID setting from ApplicationPoolId to NetworkService
Right click the Application Pool in question, click on "Advanced Settings" and then scroll down to ID - it will probably be set to ApplicationPoolIdentity. Click the button (..) and select NetworkService from the dropdown list instead.
Also make sure that if it is a .NET 2.0 application that you are not referencing the 4.0 framework in your App Pool.
Before changing the web.config file, I would check that the .NET Framework version that you are using is exactly (I mean it, 4.5 != 4.5.2) the same compared to your GoDaddy settings (ASP.Net settings in your Plesk panel). That should automatically change your web.config file to the correct framework.
Also notice that for now (January '16), GoDaddy works with ASP.Net 3.5 and 4.5.2. To use 4.5.2 with Visual Studio it has to be 2012 or newer, and if not 2015, you must download and install the .NET Framework 4.5.2 Developer Package.
If still not working, then yes, your next step should be enabling detailed error reporting so you can debug it.
I recently got into same problem, the disk space was full on the server. Clearing some space has resolved the issue.
Try compiling in Debug mode (in Visual Studio). If you are in Release mode, a lot of URL Rewrite errors will not be available.
Image shows the Debug selection combobox in Visual Studio

How do I protect static files with ASP.NET form authentication on IIS 7.5?

I have a website running on a IIS 7.5 server with ASP.NET 4.0 on a shared host, but in full trust.
The site is a basic "file browser" that allows the visitors to login and have a list of files available to them displayed, and, obviously, download the files. The static files (mostly pdf files) are located in a sub folder on the site called data, e.g. http://example.com/data/...
The site uses ASP.NET form authentication.
My question is: How do I get the ASP.NET engine to handle the requests for the static files in the data folder, so that request for files are authenticated by ASP.NET, and users are not able to deep link to a file and grab files they are not allowed to have?
If you application pool is running in Integrated mode then you can do the following.
Add the following to your top level web.config.
<system.webServer>
<modules>
<add name="FormsAuthenticationModule" type="System.Web.Security.FormsAuthenticationModule" />
<remove name="UrlAuthorization" />
<add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" />
<remove name="DefaultAuthentication" />
<add name="DefaultAuthentication" type="System.Web.Security.DefaultAuthenticationModule" />
</modules>
</system.webServer>
Now you can use the standard ASP.NET permissions in your web.config to force forms authentication for all files in the directory.
<system.web>
<authorization>
<deny users="?" />
</authorization>
<authentication mode="Forms" />
</system.web>
I had the same problem with getting roles to authenticate. Through trial and error I finally got it to work with a small edit to #Joel Cunningham's code:
<modules runAllManagedModulesForAllRequests="true" >
I used these two sites as references: http://forums.iis.net/t/1177964.aspx and http://learn.iis.net/page.aspx/244/how-to-take-advantage-of-the-iis-integrated-pipeline/
This is an old thread, but I happened on it and ran into the same problem as Egil. Here is the version of Joel's fix that includes roles:
<modules runAllManagedModulesForAllRequests="false">
<remove name="FormsAuthenticationModule" />
<add name="FormsAuthenticationModule" type="System.Web.Security.FormsAuthenticationModule" />
<remove name="UrlAuthorization" />
<add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" />
<remove name="RoleManager" />
<add name="RoleManager" type="System.Web.Security.RoleManagerModule" />
<remove name="DefaultAuthentication" />
<add name="DefaultAuthentication" type="System.Web.Security.DefaultAuthenticationModule" />
</modules>
Addendum:
As #eych noted the accepted answer also blocks access to the ~/Content folder (or wherever you have your CSS), and ~/Scripts, and so on.
If you want to allow exceptions -- i.e. allow certain files/folders to be accessible by unauthenticated users -- you can do that by means of the location element. Add the following to web.config:
<location path="Content">
<system.web>
<authorization>
<allow users="*" />
</authorization>
</system.web>
</location>
Update:
An alternative solution is to is to leave access on by default -- which will allow access to your CSS / JavaScript / etc. -- and apply the "lock" (only) to the folder where the static content is stored:
<location path="data">
<system.web>
<authorization>
<deny users="?"/>
</authorization>
</system.web>
</location>
Caveat: in our case (an MVC site) we needed to decorate all our controller actions (except login) with [AuthorizeAttribute]. Which is a good idea anyway, but had previously not been necessary (because previously any unauthorized request was redirected to the login page).
I wanted to know why it would be required to re-add modules (with default options) that are added by default for the Integrated Pipeline, so I dug a little deeper.
You need to remove and re-add the modules because, by default, the modules aren't added with the default options. They have a precondition added for backwards compatibility to run only for content handled by a registered ASP.NET handler (e.g., .aspx pages).
The default looks like this:
<add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule"
preCondition="managedHandler" />
By removing the modules and re-adding them without a precondition, those individual modules run for every request (including your static content). It is more granular than enabling runAllManagedModulesForAllRequests.
You can read about it in a couple articles from when the Integrated Pipeline was introduced with IIS 7:
ASP.NET Integration with IIS 7
How to Take Advantage of the IIS 7.0 Integrated Pipeline
Note that there is a typo or the module name in the second article (and #John's answer) was changed from FormsAuthenticationModule to FormsAuthentication at some point.
The set of working modules in IIS 7.5 thru 8.5 looks like this for me:
<system.webServer>
<modules>
<!-- Re-add auth modules (in their original order) to run for all static and dynamic requests -->
<remove name="FormsAuthentication" />
<add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule" />
<remove name="DefaultAuthentication" />
<add name="DefaultAuthentication" type="System.Web.Security.DefaultAuthenticationModule" />
<remove name="RoleManager" />
<add name="RoleManager" type="System.Web.Security.RoleManagerModule" />
<remove name="UrlAuthorization" />
<add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" />
</modules>
</system.webServer>
If you application pool is running in Classic mode, you can do the following. You will have to repeat these steps for each file extension you'd like to handle, but I'm using .html here.
First, add a page build provider to the Web.config:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.web>
<compilation>
<buildProviders>
<add type="System.Web.Compilation.PageBuildProvider" extension=".html"/>
</buildProviders>
</compilation>
</system.web>
</configuration>
Then add a page handler factory:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.web>
<httpHandlers>
<add type="System.Web.UI.PageHandlerFactory" path="*.html" verb="*"/>
</httpHandlers>
</system.web>
</configuration>
Then add a page handler:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<handlers>
<add scriptProcessor="C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll" requireAccess="Script" preCondition="classicMode,runtimeVersionv2.0,bitness32" path="*.html" verb="GET,HEAD,POST,DEBUG" modules="IsapiModule" name="HtmlHandler-Classic-32" />
<add scriptProcessor="C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll" requireAccess="Script" preCondition="classicMode,runtimeVersionv2.0,bitness64" path="*.html" verb="GET,HEAD,POST,DEBUG" name="HtmlHandler-Classic-64"/>
</handlers>
</system.webServer>
</configuration>
This worked for me. (Credit: http://www.ifinity.com.au/Blog/EntryId/66/How-To-301-Redirect-htm-or-html-pages-to-DotNetNuke-aspx-pages.)

Resources