According to Microsoft's documentation, for static (i.e. HTML) content, web.config should read responseMode="File" for each error.
Currently, my web.config includes
<httpErrors errorMode="Custom">
<!-- remove statusCodes -->
<error statusCode="404" path="/error/404.html" responseMode="ExecuteURL" />
</httpErrors>
This returns the correct custom error page, but returns a 200 OK status code.
When I change "ExecuteURL" to "File", my server does return a 404, but the custom error page is not displayed. Instead, I get the message "The resource you are looking for has been removed, had its name changed, or is temporarily unavailable."
How is web.config supposed to read, to return a static file, but also a 404?
Edit: removed <customErrors> questions after learning that that tag is for IIS <= 6.0
I was figthing with exactly same problem pretty long time. Now I found out by accident that the problem is in the slash character.
this is working for me - no beginning slash and use \ instead of /
<error statusCode="404" path="Static\WebServer\PageNotFound.htm" responseMode="File" />
Related
Using the 301 Redirect Module for Sitecore 7, I'm having a problem establishing the proper Requested Expression and Source values to use in the Sitecore Redirect Module. I have an example url that is typically getting request that I want redirected to the home page of the site.
The example url requests all contain excite.com at the end of the URL:
https://www.example.com/products/foods/apples/excite.com
https://www.example.com/products/foods/oranges/excite.com
https://www.example.com/products/foods/pears/excite.com
I would like these requests that contain excite.com at the end to be redirected to the home page (https://www.example.com) but I can't for the life of me figure this out.
I haven't used the 301 Redirect Module but have used similar modules. There are 2 issues that need resolving.
You need to create a redirect using the Pattern Match Redirect. The regex you need is "match any request that ends with /excite.com"
.*(/excite.com)$
The other issue is that Sitecore is seeing the .com part of the url as an extension and then filtering the request. You need to add com to the list of Allowed extensions.
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
<sitecore>
<preprocessRequest>
<processor type="Sitecore.Pipelines.PreprocessRequest.FilterUrlExtensions, Sitecore.Kernel">
<param desc="Allowed extensions (comma separated)">aspx, ashx, asmx, com</param>
</processor>
</preprocessRequest>
</pipelines>
</sitecore>
</configuration>
All that said, if you are using the IIS Rewrite module then you could just add a rule in there which will get resolved and redirect before you even hit the Sitecore pipelines and therefore you do not need to worry about the allowed extensions filter.
<rules>
<rule name="Redirect excite.com" stopProcessing="true">
<match url=".*(/excite.com)$" />
<action type="Redirect" url="https://{HTTP_HOST}" appendQueryString="false" />
</rule>
</rules>
Change the regex to (excite.com)$|.*(/excite.com)$ if you also want it to match http://ww.example.com/excite.com
I have read through NWebSec's documentation to try and resolve the problem.
Set the web.config to
<nwebsec>
<httpHeaderSecurityModule
xsi:noNamespaceSchemaLocation="NWebsecConfig/HttpHeaderSecurityModuleConfig.xsd"
xmlns="http://nwebsec.com/HttpHeaderSecurityModuleConfig.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<redirectValidation enabled="false">
<allowSameHostRedirectsToHttps enabled="false"/>
<add allowedDestination="https://www.facebook.com/"/>
<add allowedDestination="http://www.nwebsec.com/"/>
<add allowedDestination="https://www.google.com/accounts/"/>
</redirectValidation>
<securityHttpHeaders>
<strict-Transport-Security max-age="365" includeSubdomains="true" httpsOnly="false" preload="true" />
</securityHttpHeaders>
</httpHeaderSecurityModule>
but I am still getting
A potentially dangerous redirect was detected. Add the destination to the whitelist in configuration if the redirect was intended. Offending redirect: https://www.facebook.com/dialog/oauth?response_type=code&
This came up in google before the answer, which is here: https://docs.nwebsec.com/en/latest/nwebsec/Redirect-validation.html
In summary you have to whitelist the URL which your login service refers to, like this:
app.UseRedirectValidation(opts =>
{
opts.AllowedDestinations( "https://www.facebook.com/dialog/oauth");
opts.AllowedDestinations("https://login.microsoftonline.com"); // Tested
});
I've got an azure website (at http://ekpowestore.azurewebsites.net/) that won't show a Facebook like button in Explorer or Firefox. It does in Chrome and Safari. Yet if I change the address to https (as in https://ekpowestore.azurewebsites.net/), the Like and Share buttons render just fine.
Liking an https isn't the same as http. I guess I can refer folks to the https site, but I'm still curious about what the root cause is.
Of course, I tried about 100 different things before finally throwing up a nearly empty page on my azure site.
seems your page returns 307 "Internal Redirect" while trying to load the Facebook script on HTTP request. I am not sure, but you possibly used "Protocol relative" referencing on your javascript like
js.src = "//connect.facebook.net/en_US/sdk.js";
which will redirect the action with using the current protocol (https://connect.facebook.... if you are using HTTPS or to HTTP). Could you please try to replace it with full url to give it a try ?
eg.
js.src = "https://connect.facebook.net/en_US/sdk.js";
I give up. This isn't the actual answer to the o.p., so I won't mark it as such. But it is what I did to address the problem - So perhaps someone will find this useful.
Note that I did take the entire app down to just an html doc with a facebook like plugin in it - No other dependencies - And yet then still IE and FF no love, Safari and Chrome fine. This was both using a protocol relative Facebook path (i.e. - "//connect.facebook.net/en_US/sdk.js") and a specified https path (i.e. "https://connect.facebook.net/en_US/sdk.js")
So rather than fight the http - https mixed content war that Gaurav pointed out may have been happening with the Facebook reference, I changed the Azure site so it always forwards http to https. Problem solved, moving on ('problem solved' being slightly different than 'question answered').
Added a web.config file consisting of the following worked for me:
````
<system.webServer>
<validation validateIntegratedModeConfiguration="false" />
<rewrite>
<rules>
<rule name="Redirect HTTP to HTTPS" stopProcessing="true">
<match url="(.*)"/>
<conditions>
<add input="{HTTPS}" pattern="^OFF$"/>
</conditions>
<action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="SeeOther"/>
</rule>
</rules>
</rewrite>
</system.webServer>
I have a long querystring value I need to pass in (itself a questionable practice, I understand), and I am not able to get it to take effect on my Appharbor app instance.
Locally, I've made this change to my web.config and confirmed that the URL in question works locally:
<httpRuntime maxQueryStringLength="2097151"/>
And ensured that it exists in the resultant web.config post the transformation by my Web.Release.config. That said, when I push to AppHarbor, the transformation should pick it up...yet I'm still getting this exception:
The length of the query string for this request exceeds the configured maxQueryStringLength value.
Stack Trace:
at System.Web.HttpRequest.ValidateInputIfRequiredByConfig()
at System.Web.HttpApplication.PipelineStepManager.ValidateHelper(HttpContext context)
Any ideas? Thanks for your help.
My original testing was done against Cassini (VS 2010's built-in web server). I pushed locally to IIS 7.5 and found this error:
HTTP Error 404.15 - Not Found
The request filtering module is configured to deny a request where the query string is too long.
Which appeared because I didn't specify the maxQueryLength in the <system.webServer> section of my web.config as well as the <httpRuntime>. So the answer is to specify BOTH the <system.web> and <system.webServer> sections:
<system.web>
<httpRuntime maxQueryStringLength="2097151"/>
</system.web>
And then:
<system.webServer>
<security>
<requestFiltering>
<requestLimits maxQueryString="2097151"/>
</requestFiltering>
</security>
</system.webServer>
When I pushed this version of my config to AppHarbor, all was well. Hope this helps.
Remember that HTTP.SYS has its own limits as well!
They're described here: http://support.microsoft.com/kb/820129
This is customErrors section from my web.config file
<customErrors mode="On">
<error statusCode="500" redirect="HTTP500.aspx" />
</customErrors>
HTTP500.aspx is the same as standard /Views/Shared/Error.aspx page.
When I get HTTP 500 error I see this page:
Server Error in '/' Application.
Runtime Error
Description: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed.
Details: To enable the details of this specific error message to be viewable on the local server machine, please create a tag within a "web.config" configuration file located in the root directory of the current web application. This tag should then have its "mode" attribute set to "RemoteOnly". To enable the details to be viewable on remote machines, please set "mode" to "Off".
Notes: The current error page you are seeing can be replaced by a custom error page by modifying the "defaultRedirect" attribute of the application's configuration tag to point to a custom error page URL.
But when I change the above customErrors section like this:
<customErrors mode="On">
<error statusCode="500" redirect="HTTP500.htm" />
</customErrors>
then HTTP500.htm page is displayed when HTTP 500 error occurs.
Why HTTP500.aspx page isn't displayed?
I suspect its a problem with your routes. You may be mapping HTTP500.aspx to a non-existant controller method.
Have you tried the following?
routes.IgnoreRoute("HTTP500.aspx");