Enhancements to PageParserPath element in the SharePoint web.config – PhysicalPath

September 2020 public update for SharePoint included a security fix which broke lots of existing customized ghosted pages in SharePoint installations.

The security fix requires administrators to manually enable certain customized pages by adding a PageParserPath entry in the SharePoint/SafeMode section of the web.config containing a VirtualPath attribute which includes the virtual path to the affected page. The virtual path here represents the path part of the Url as it is requested from the server. E.g.:

<SafeMode MaxControls="200" CallStack="false" DirectFileDependencies="15" TotalFileDependencies="250" AllowPageLevelTrace="false">
    <PageParserPaths>
        <PageParserPath VirtualPath="/relativepath/page.aspx" CompilationMode="Always" AllowUnsafeControls="true" AllowServerSideScript="true" />
    </PageParserPaths>
</SafeMode>

Although wildcards are allowed for these PageParserPath entries for security reasons it is recommended to add VirtualPath as specific as possible. The VirtualPath should include site collection path which may require to add many entries even for one blocked ghosted page if it is used in multiple site collections.
In some scenarios hundreds of PageParserPath entries have to be added to unblock a single blocked ghosted page which is used in multiple site collections.

As a relief for this the implementation of the PageParserPath element has been enhanced by adding a PhysicalPath attribute to it.
In this scenario customers only have to enter a single PageParserPath element unblocking the specific ghosted page on the file system rather than multiple entries for each virtual path.

PhysicalPath is more secure than VirtualPath: while PageParserPath with VirtualPath attribute unblocks as well ghosted and unghosted pages (means pages which have been modified from the version on the file system and which are stored as modified version in the content database) the PhysicalPath attribute only unblocks ghosted pages. Means pages which have not been modified from the version on the file system. This guarantees that SharePoint administrators have full control over the code and controls referenced in the unblocked pages which is not always the case for pages that were modified by users with sufficient rights in a site collection.

Syntax:

Example 1

<SafeMode MaxControls="200" CallStack="false" DirectFileDependencies="15" TotalFileDependencies="250" AllowPageLevelTrace="false">
    <PageParserPaths>
        <PageParserPath 
             PhysicalPath="C:\Program Files\Common Files\microsoft shared\Web Server Extensions\16\TEMPLATE\GLOBAL\seattle.master" 
             CompilationMode="Always" 
             AllowUnsafeControls="false" 
             AllowServerSideScript="true" />
    </PageParserPaths>
</SafeMode>

Note:

  • PhysicalPath is real full physical path of the seattle.master file in the file system.
  • The same additional attributes (e.g. CompliationMode, AllowServerSideScript) can be used as with VirtualPath

 

Example 2

<SafeMode MaxControls="200" CallStack="false" DirectFileDependencies="15" TotalFileDependencies="250" AllowPageLevelTrace="false"> 
    <PageParserPaths>
        <PageParserPath 
             PhysicalPath="C:\Program Files\Common Files\microsoft shared\Web Server Extensions\16\TEMPLATE\LAYOUTS\solutiondir\*" 
             CompilationMode="Always" 
             AllowServerSideScript="true" 
             AllowUnsafeControls="false" 
             IncludeSubFolders="true"/>
        <PageParserPath VirtualPath="/<anySubPath>" ... />
    </PageParserPaths>
</SafeMode>

Note:

  • PhysicalPath also support suffix wildcard, same as VirtualPath.
  • IncludeSubFolder attribute is also supported with PhysicalPath.

Example 3

<SafeMode MaxControls="200" CallStack="false" DirectFileDependencies="15" TotalFileDependencies="250" AllowPageLevelTrace="false"> 
    <PageParserPaths> 
        <PageParserPath 
            PhysicalPath="C:\anyPhysicalPath\*" 
            VirtualPath="/anyVirtualPath/*" 
            CompilationMode="Always" 
            AllowServerSideScript="true" 
            AllowUnsafeControls="false"/>
    </PageParserPaths> 
</SafeMode>

Note:

  • If PhysicalPath is specified together with VirtualPath, the PhysicalPath will be ignored and only the VirtualPath attribute is used.

 

Conflict management

It is possible to have multipled PageParserPath elements (some with VirtualPath while some with PhysicalPath). A single page could matched by more than one entry.
In this case the following logic will be applied to determine which element is being used:

  • If the page is matched by multiple PhysicalPath rules the most specific one will be used
  • If the page is matched by multiple VirtualPath rules the most specific one will be used
  • If the page is exactly matched by a PhysicalPath and exactly matched by a VirtualPath rule the VirtualPath rule will be used
  • If the page is exactly matched by a PhysicalPath rule and by a directoy matched VirtualPath rule the PhysicalPath rule will be used
  • If the page is directoy matched by a PhysicalPath rule and directoy matched by a VirtualPath rule the VirtualPath rule will be used

 

How can the physical path be identified if a page does not render?

An ULS log entry has been added to record the physicalPath for each accessed page. You can search ‘84lu6’ in ULS log and will find the PhysicalPath.

Here is example of from the ULS log:

w3wp.exe (0x0144) 0x1870 SharePoint Foundation Runtime 84lu6 Medium Get Page Parser Setting by virtualPath=/anysubpath/seattle.master and physicalPath=C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\Template\global\seattle.master

Which SharePoint version benefit from the improvement?

Currently (February 2021 CU) SharePoint Server 2016 and 2019 can make use of the new PhysicalPath attribute for PageParserPath.

 

13 Comments


  1. Any tip on how to handle customized masterpages for onedrive in SP2013?
    Wildcard virutalpath only seems to apply at the end of the path, i.e
    /personal/myusername/_catalog/masterpage/* fixes it, but I can’t do
    /personal/*/_catalog/masterpage/custom.master to whitelist all users onedrives.

    With physicalpath not available for sp2013 it seems only manageble option is to revert back to default masterpage

    Reply

    1. Hi Marcus,
      till now we did not receive any support cases from customers requesting physicalPath for SharePoint 2013.
      If you need physicalPath for SharePoint 2013 you should open a support case with Microsoft to ensure that we can forward that request to the product group.
      Cheers,
      Stefan

      Reply

  2. Hi Stefan,

    Virtual path doesnt work for me with Host-Named site collections. How to make it working in such scenario?

    Reply

    1. Hi Kamil,

      the preferred way to configure this is the physicalPath as it guarantees that it only gets active for ghosted pages which reside on the file system.

      About virtual path: the virtual path does not include the domain name just the server relative path. That should work in the same way for host named site collections.
      If there is a problem you should open a support case with Microsoft to get this investigated.

      Cheers,
      Stefan

      Reply

  3. Hi Stefan,
    For the issue reported above the only way to have these resolved is add PageParserPath – We have done the same and works when we specify the Virtual Path – No issues
    To control the same more effectively followed above one include PhysicalPath but get the error – The attribute ‘autoeventwireup’ is not allowed in this page.

    #1 – We have modified master page to custom master page
    #2 – Visual Webcontrols on the Custom Master Page

    Any direction on this

    Reply

    1. Hi Babu,
      you mean the issue can be resolved using VirtualPath but not using PhysicalPath?
      Please verify if the page has been unghosted (e.g. edited using SharePoint designer so that a copy was stored in the content database).
      PhysicalPath only works for ghosted files.
      You can check if the file was unghosted by checking the CustomizedPageStatus property of the SPFile object of the relevant (master-)page (e.g. using Powershell)
      Cheers,
      Stefan

      Reply

      1. Thanks for the Update – I would check the status of the file if it was unghosted vs ghosted
        Just to confirm
        #1 – Physical path only works for ghosted files
        #2 – When using physical path the attribute – AllowUnsafeControls=”false” where as when using the same attribute for VirtualPath this attribute has to be AllowUnsafeControls=”true”

        Is that right

        Reply

        1. Hi Babu,
          #2 this should be the same for physical and virtual path – depending on your needs.
          Cheers,
          Stefan

          Reply

  4. From your original post I saw a comments conversation (btwn Loic Wendel and you) that relates to an issue I’m having. I can’t open the PowerPivot service application (ServiceAppDashboard.aspx). I get “The attribute ‘autoeventwireup’ is not allowed in this page.” How can I find the path to where this .aspx lives to configure a PageParserPath and will I have to add SafeControl elements?

    Reply

    1. Hi Trish,
      for virtual path you can see it from the Url in the browser.
      For physical path please check the ULS log by checking the 84lu6 tag. If SafeControl elements are required depends on the controls on the relevant page.
      Cheers,
      Stefan

      Reply

    2. Trish, did you find what fixed this issue? I am having the same thing.

      Reply

  5. Hi Stefan, I am getting the the error – The attribute ‘autoeventwireup’ is not allowed in this page. I have tried the VirtualPath fix suggested but this does not work. I have customised the new and edit forms of a list and this is where I am getting the error I am using SharePoint 2013 onprem.

    Reply

Leave a Reply to Umr Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.