New Post: XMLBasedSiteBackup gives 404 Page does not exist (MS URLScan / AllowDotInPath=0)

Hi Mawtex,

Thanks again for taking the time to respond, and for your helpful, frank and honest answers.

At least this thread is highlighting/recognising the problem and this may help anyone else who encounters issues caused by URLScan and AllowDotInPath settings, whether they are capable of changing the setting on owned servers, or simply rename path names (as I did) for instances were the machine level server settings are out of direct control.

I also tried a similar search to yours on Github, but for "CustomUrlAction", and combining both yours and my search this suggests a short list of the following C1 add-ons:-

• Composite.Forms.JotForm (dots in path to Report.aspx)
• Composite.Tools.PagePrintCommand (dots in path to Print.aspx)
• Composite.Tools.SqlServerDataProvider (dots in path to SqlServerDataProvider.aspx)
• Composite.Tools.XmlBasedSiteBackup (dots in path to XmlBasedSiteBackup.aspx)
• Composite.Tools.LegacyUrlHandler (~/FixBrokenLink.aspx - possibly not affected?)
• Composite.Tools.Linkchecker (references to package creator and install scripts plus dots in path to ListBrokenLinks.aspx - might be affected?)
• Composite.Tools.StaticDataTypeCreator (StaticDataTypeCreator.ashx - possibly not affected, unsure if URLScan monitors .ashx?)
• Composite.Tools.FormSubmitHandler (dots in path to GetData.aspx)
  

Difficult to say (apart from XmlBasedSiteBackup of course) which ones are affected without direct testing on a server setup with URLScan.
I don't have the time to investigate these further myself, so maybe the above is good enough to be useful to other users for the time being?

And it would be helpful if anyone who uses these Add-Ons successfully or not when URLScan and AllowDotInPath=0 are involved, please post an update to this thread.
I will do so if I install any of the above.

Thanks Microsoft/Netcetera for wasting so much of our time!