locked
Custom error page not being displayed RRS feed

  • Question

  • User-1668220527 posted

    Hi folks, found a lot of posts about this but no answers :-)

    I have a error redirect:  <customErrors mode="RemoteOnly" defaultRedirect="~/Errors/index.htm"/>

    The URL which is being generated on an error is this..../Errors/index.htm?aspxerrorpath=/customer/order/reorder.aspx

    This I thought would be correct and the site displays index.htm if i access it directly but when an error occurs on the site it displays the standard .NET error page -

    If i set the setting to 'Off' it displays the exception trace as expected - *it seems to be treating the ?aspexrrorpath as part of the address which then overrides the index.htm address and so displays the standard error.

    I have added explicit permissions to the custom errors page for all users after reading other posts:

      <location path="Errors">
        <system.web>
          <authorization>
            <allow users="*"/>
          </authorization>
        </system.web>
      </location>


     Any suggestions as to why the defaultRedirect is not working?

     

    Cheers

    Monday, July 22, 2013 11:16 AM

Answers

  • User-1668220527 posted

    Thanks Ruchira, already been around the block with that one, i was testing the live site after getting .NET errors whilst testing it :-)

    Stumbled across the 90% solution after reading about a patched vulnerability in .NET back in 2010 using the asperrorpath that was attached by default to .NET errors.  It still dumps the page theme but at least displays the page.  I think displaying the error causes a loss of authentication context which is probably buried in the code somewhere but at least the page now displays:

    <customErrors mode="On" defaultRedirect="~/Errors/UnHandledError.aspx" redirectMode="ResponseRewrite"/>

    The redirectMode needs to be specified because the asperrorpath part of the query was exploited in the hack and an HTTP error is always raised instead.

    The 100% solution required an update the error page to an aspx page on the pilot site as well as the attribute and everything now seems to behave Smile

    Thanks for your response which was the only one!!

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Tuesday, July 23, 2013 7:03 AM

All replies

  • User71929859 posted

    Hello,

    mode="RemoteOnly"

    When you set the mode to RemoteOnly, it only works when you browser your website outside from your server. Try by setting it to On.

    <customErrors mode="On" defaultRedirect="~/Errors/index.htm"/>
    Monday, July 22, 2013 3:24 PM
  • User-1668220527 posted

    Thanks Ruchira, already been around the block with that one, i was testing the live site after getting .NET errors whilst testing it :-)

    Stumbled across the 90% solution after reading about a patched vulnerability in .NET back in 2010 using the asperrorpath that was attached by default to .NET errors.  It still dumps the page theme but at least displays the page.  I think displaying the error causes a loss of authentication context which is probably buried in the code somewhere but at least the page now displays:

    <customErrors mode="On" defaultRedirect="~/Errors/UnHandledError.aspx" redirectMode="ResponseRewrite"/>

    The redirectMode needs to be specified because the asperrorpath part of the query was exploited in the hack and an HTTP error is always raised instead.

    The 100% solution required an update the error page to an aspx page on the pilot site as well as the attribute and everything now seems to behave Smile

    Thanks for your response which was the only one!!

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Tuesday, July 23, 2013 7:03 AM
  • Tuesday, July 23, 2013 9:26 AM