locked
SharePoint 2007 RRS feed

  • Question

  • User194134951 posted

    From what I understand (on a high level) we're displaying the same "error' page regardless of the error (404, 500, etc). How can we do this with SharePoint 2007?  

    Currently to set a custom 404 error page with SharePoint 2007 we have to write a console application to point the web application to a custom 404 page.

     

    / The following code assumes that a reference is made to Microsoft.SharePoint.
    
    Microsoft.SharePoint.Administration.SPWebApplication webapp = 
    Microsoft.SharePoint.Administration.SPWebApplication.Lookup(new Uri("http://<serverurl>"));
                webapp.FileNotFoundPage = "<Custom404.htm>";
                webapp.Update();
     
    reference: http://support.microsoft.com/kb/941329
     
    How can we set all errors on the sharepoint 2007 web application to point to the custom page?
    
    Monday, September 20, 2010 3:31 PM

Answers

  • User-619846739 posted

    You don't need to worry about non-Managed code, so http://yourdomain.com/non-existent-page.txt isn't a concern.  The concern is with /non-existent-page.aspx.  I haven't tested but I believe you can follow the standard instructions to edit <customErrors> in web.config.  You can test by visiting http://yourdomain.com/non-existent-page.aspx and confirm that it redirects to your custom error page.  If so, you should be good. 

    To be extra sure, you can test a 500 error by adding a page called test.aspx and add the following to it, save and run:

    <% something wrong %>

    That should throw a 500 error, which should look identical to the 404 page.

     

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, September 20, 2010 5:46 PM
  • User-2030726170 posted

    The SharePoint team's blog post shows some instructions for SharePoint 2010:

    http://blogs.msdn.com/b/sharepoint/archive/2010/09/21/security-advisory-2416728-vulnerability-in-asp-net-and-sharepoint.aspx

    However, some SharePoint 2007 (and 2010?) virtual directories already have

    <customErrors mode=”On” />

    and the SharePoint http handler redirects to /_layouts/error.aspx in these instances.  By default this page does display different content for different error types though, so an attack could still be successful.

    As such, instead of setting up an alternate error2.aspx, I'd recommend backing up your current error.aspx and replacing the file directly with its original name.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Tuesday, September 21, 2010 4:04 AM

All replies

  • User-619846739 posted

    You don't need to worry about non-Managed code, so http://yourdomain.com/non-existent-page.txt isn't a concern.  The concern is with /non-existent-page.aspx.  I haven't tested but I believe you can follow the standard instructions to edit <customErrors> in web.config.  You can test by visiting http://yourdomain.com/non-existent-page.aspx and confirm that it redirects to your custom error page.  If so, you should be good. 

    To be extra sure, you can test a 500 error by adding a page called test.aspx and add the following to it, save and run:

    <% something wrong %>

    That should throw a 500 error, which should look identical to the 404 page.

     

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, September 20, 2010 5:46 PM
  • User-2030726170 posted

    The SharePoint team's blog post shows some instructions for SharePoint 2010:

    http://blogs.msdn.com/b/sharepoint/archive/2010/09/21/security-advisory-2416728-vulnerability-in-asp-net-and-sharepoint.aspx

    However, some SharePoint 2007 (and 2010?) virtual directories already have

    <customErrors mode=”On” />

    and the SharePoint http handler redirects to /_layouts/error.aspx in these instances.  By default this page does display different content for different error types though, so an attack could still be successful.

    As such, instead of setting up an alternate error2.aspx, I'd recommend backing up your current error.aspx and replacing the file directly with its original name.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Tuesday, September 21, 2010 4:04 AM