I have setup an asp.net 4.0 site where if someone tries to access an authorized area they get redirected to a SignIn page and the status is set to 403.
On my local machine it redirects to the SignIn page with the 403 status. On IIS 7 I get a nasty 403 Forbidden page instead of the SignIn page.
How can I get it to work on IIS 7 like it does on my Local?
IIS has default pages for all the HTTP error codes. You can override these in IIS to redirect to your own page.
IIS also recognizes the ASP.NET tag in the web.config file and uses that first if it's available, so you will need to setup your custom errors tags as follows:
<customErrors defaultRedirect="defaultError.aspx" mode="On">
<error statusCode="403" redirect="my403page.aspx"/>
</customErrors>
Hope this is what you're after. You can also use forms authentication in ASP.NET to achieve this, it uses cookies but works quite well with the scenario you described, unless you specifically need them to be redirected to a 403 page.
By "nasty" it sounds like you mean that IIS is throwing up its default 403 err message page. You could set the custom 403 error in IIS to redirect the user to your friendly signin page.
Not sure that's the best design, necessarily, but it probably would solve your problem based on how you've explained it...
I would check to make sure the authentication settings in your web.config file are the same in both environments.
EDIT
You might also be running into a problem with the anonymous authentication identity. I've run into this issue myself when first moving a site to IIS7. MSDN has a page the runs through your possible options.
Related
I have a controller where an action returns a 404 error on ASP.NET MVC. Working locally, I get the page with 404 error correctly. When I deploy it to azure, instead of the page, I only get a text-only page:
The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.
I've tried all three values on on customErrors mode in web.config (mode = Off, On, RemoteOnly) and it doesn't seem to change anything at all.
Why is Azure behaving differently on 404 errors and how can I make it behave the same as local IIS?
Okay I've found out the problem. Apparently, it wasn't even hitting the ASP.NET's custom errors handler, and was being caught at server level.
I've played with web.config and added this:
<httpErrors errorMode="Detailed">
<remove statusCode="500"/>
</httpErrors>
It now passes my error to the ASP.NET's custom error handler correctly.
I have a webpage(home.aspx) that requires Windows Authentication. If the browser automatically sends in valid credentials, then home.aspx is displayed. Otherwise, login.aspx is displayed.
In IE, I have checked off the "Prompt for User name and Password" checkbox in Internet Options > Local Intranet > Custom level > User Authentication.
I have following the steps in http://www.codeproject.com/Articles/11202/Redirecting-to-custom-page-when-quot-Access-de , and it works fine on my local development server. However, on the production server, it is a different story.
In IIS, Home.aspx has anonymous authentication disabled, and windows authentication enabled. Login.aspx has anonymous authentication enabled and windows authentication disabled.
In the development server, on a computer that is logged in using correct credentials, home.aspx shows up. And, when the browser does not send in the credentials, Application_EndRequest is hit with a 401 status code, then the default Windows Authentication Prompt shows.
After cancelling this dialog, login.aspx is shown. This is the correct behavior.
However, in production server, on a computer that is logged in using correct credentials, home.aspx shows up. And, when the browser does not send in the credentials, Application_EndRequest is hit with a 401 status code, then the default Windows Authentication Prompt shows. After cancelling this dialog, the default 401 page shows.
Does anyone what is going on the production server, and why I am not able to intercept the 401 status code and redirect to a custom web page.
In IIS 7, they added an attribute in web.config that controls the behavior of custom errors. By default, custom and detailed errors are only shown on the local browser. To show your custom errors, you need to change this in the web.config <httpErrors> element, errorMode attribute.
<configuration>
<system.webServer>
<httpErrors errorMode="DetailedLocalOnly" defaultResponseMode="File" >
<remove statusCode="500" />
<error statusCode="500"
prefixLanguageFilePath="C:\Contoso\Content\errors"
path="500.htm" />
</httpErrors>
</system.webServer>
</configuration>
DetailedLocalOnly is the default; other possible values are Detailed and Custom.
For more reading, here is the Microsoft article that talks about this configuration.
Aside: The article you linked is more than 10 years old, and is therefore quite suspect for "modern" development. One of the comments on the article, posted about 5 years later, points to this same problem and solution.
I have a ASP.NET 5 site that I want to add custom error pages to. I'm used to adding entries in the web.config (from ASP.NET 4 days) but I want to use the new approach in ASP.NET 5. So I have the following in my Startup.cs class:
if (env.IsEnvironment("Development"))
{
app.UseErrorPage(ErrorPageOptions.ShowAll);
}
else
{
app.UseStatusCodePagesWithReExecute("/Home/Error");
app.UseErrorHandler("/Home/Error");
}
When I run locally using kestral my error page is displayed properly. However, when I deploy to Azure I get the very generic white error page when I try to test 404 errors:
"The resource you are looking for has been removed, had its name changed, or is temporarily unavailable."
I tried implementing this answer in my web.config and it does not resolve my issue:
https://stackoverflow.com/a/29539669/8320
This is the relevant part of my web.config:
<system.web>
<customErrors mode="Off" />
</system.web>
I have also ensured that ASPNET_ENV="Production" in the Configure / App Settings section of the Azure Website.
Any ideas? If I can provide more info let me know.
IIS is a tricky beast and we're still working through this in ASP.NET 5. When you run on IIS, we run through the middleware pipeline and then call back into IIS native modules if nothing handled the request. When you get a 404 that was un-handled by any middleware, it will re-enter the IIS pipeline and trigger IIS specific error pages. The UseStatusCodePagesWithReExecute middleware still runs, but by then, IIS has already sent the headers and body to the client (browser in this case).
In order to respond in any cfm with a cfheader statuscode=404, in web.config I have setup this:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<httpErrors existingResponse="PassThrough" />
</system.webServer>
</configuration>
That's works great.
To respond with a custom page when the client access to an inexsistent page, I have setup a Custom 404 page to a cfm in IIS7 manager but it respond with a blank page (with 404 code) and not my custom cfm page.
How can I configure IIS to respond with a custom page AND passthough from cfheader ?
Take a look at this link that answers a related question. The solution was found on a server running ColdFusion 9 Standard but I believe the result will be the same on ColdFusion 10, since my own problem - discussed in another thread - began with that version.
Long story short: For problem-free operation you must put a 404 handler under the web root of your site and use IIS Error Pages to specify that ColdFusion page as the 404 handler for the site. Complete details in the link.
Control Panel, Admin tools, Sites, Error pages.
I'm working on IIS6, ASP.NET, VS2008. The web site uses a custom error handler to catch 404 errors and serve an alternate page. When presented with an url of the form:
http://srv/crimson/articles/index
Everything works perfectly. But an url of the form:
http://srv/crimson/blog.aspx
Where blog.aspx does not exist, fails with the following message:
Server Error in '/Crimson' Application. Description: HTTP 404...
When I try and debug, none of the breakpoints in my 404 handler are hit. So it appears that something is catching the request earlier. Where? And how to I get it to pass the request on to my handler?
Edit
Thanks to those who answered, but none of those ideas worked. I've decided to attack the problem another way.
You might wanna try this:
In IIS6:
open "properties" for your website
go to "home directory" tab
click on "configuration"
look for the extension ".aspx"
click on "edit"
check the checkbox which says "verify that file exists"
edit
And what about this:
http://msdn.microsoft.com/en-us/library/h0hfz6fc(VS.80).aspx
<customErrors defaultRedirect="sorry.htm" mode="On">
<error statusCode="404" redirect="NotFound.aspx"/>
</customErrors>
Since 'RemoteOnly' specifies that custom errors are shown only to the remote clients, and that ASP.NET errors are shown to the local host.
hmm, Assaf is right, but to add to his answer I need to post some code.
Yes, Assaf does mean something else ASP.NET offers it's own error handling, configured through the web.config. You can either manage this through the IIS Admin snap in, or directly in the web.config file.
Within the <system.web> element you should have:
<customErrors defaultRedirect="sorry.htm" mode="RemoteOnly">
<error statusCode="404" redirect="NotFound.aspx"/>
</customErrors>
You can configure a different page for each HTTP error code, or let the default redirect handle them all.
You'll find that you do indeed need to set these error pages up in both the IIS custom errors and the ASP.NET configuration, as otherwise you'll end up in this situation - some pages go to your 404, and others use a default that you've not customised.
You should also make sure that your custom 404 page actually returns a 404 header to ensure that search engines etc treat it correctly.
Response.StatusCode = 404;
Response.StatusDescription = "Not found";
ASP.Net has a custom errors configuraiton of its own.
Go to the ASP.Net configuration of your virtual directory (web application) and right-click -> ASP.Net -> Edit Configuration -> Custom Errors.
Maybe you got a 500 so redirect for 404 is not triggered. You may focus on this 500 error at first.