404 errors with RJP.MultiUrlPicker in Umbraco Backoffice
The other day I ran in to an issue where after installing RJP.MultiUrlPicker on an Umbraco 7.9.2 website. Every time I tried to use the url picker within a Document Type I got the following error - Request error: The Url returned a 404 (not found) /App_Plugins/RJP.MultiUrlPicker/MultiUrlPicker.html
Initially I thought I had a failed install so I uninstalled and reinstalled RJP.MultiUrlPicker. I still got the error message.
I was searching the web, chatting with people on Slack and still I had no answer.
It was suggested that it might be a a permission issue so I checked all the folders within the site to make sure the permissions were set correctly, everything looked fine.
The thing that was really confusing me was the implementation worked on my Development Environment but now I was deploying it on a staging server, I was running in to this error. I then noticed within the browser console that I was also getting 404 errors for
This just didn't make any sense.
Why was this working locally but not on the server. Time to investigate further!
I logged in to the server and tried to see a more meaningful error by viewing the website on the server via the ip address but I found I was being redirected to the live site - maybe that was the problem. Is there some weird redirects going on which is messing with the paths? Nope. This was a seperate issue and it was caused by the wesbite IP address not being added to allowed IP address range. In the office we tend to IP restrict /umbraco and for our staging websites we IP restrict the entire site. Because we hadn't added the correct IP address to staging we were just being redirected to the live site.
Then a penny dropped. It was working on Development but was it working on LIVE?
I had a look and no, it was also broken on the LIVE site, this then lead me away from it being an Umbraco issue and pointed me at looking at IIS as a server issue.
On the server, we have an ISAPI filter called UrlScan installed. Within the settings for this filter there is a setting that looks like this:
;If 1, allow dots that are not file
; extensions. The default is 0. Note that
; setting this property to 1 will make checks
; based on extensions unreliable and is
; therefore not recommended other than for
You can access the settings by going to the Executable path and editing the urlscan.ini file in notepad.
All I had to do was change the 0 to a 1 for the AllowDotInPath option and everything was working again! When you look at the items that had issues, they both have dots in the path.
A simple change which took me almost 3 hours to troubleshoot! It took 5 seconds to fix!
Where to find Owain