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:
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.
Permalink
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
Permalink
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
Permalink
Hi Stefan,
Virtual path doesnt work for me with Host-Named site collections. How to make it working in such scenario?
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
Hi Babu,
#2 this should be the same for physical and virtual path – depending on your needs.
Cheers,
Stefan
Permalink
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?
Permalink
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
Permalink
Trish, did you find what fixed this issue? I am having the same thing.
Permalink
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.
Permalink
Hi Stefan,
Any performance related issues with the solution recommended here i.e. adding PageParserPath
Using PageParserPath directive can cause performance problems
https://docs.microsoft.com/en-us/sharepoint/troubleshoot/sites/using-pageparserpath-directive
Thanks.
Permalink
Hi Stefan,
I am getting the below error.
The control type ‘Microsoft.PerformancePoint.Scorecards.TransformerConfigurationRecord’ is not allowed on this page. The type Microsoft.PerformancePoint.Scorecards.TransformerConfigurationRecord, Microsoft.PerformancePoint.Scorecards.Client, Version=15.0.0.0, Culture=neutral, PublicKeyToken=7XXXXXXXX could not be found or it is not registered as safe.
I have applied all the scripts that you suggested in your blog. Still getting same error.
Please suggest me any idea how to resolve this issue.
Thanks
Nagaraju
Permalink
Hi Nagaruju,
if you need assistance to get this resolved I would recommend to open a support case with Microsoft.
Cheers,
Stefan