Vulnerability in EPiServer.Forms
A site recently upgraded to CMS 6 does not allow me to access the search settings in admin mode's config tab. This one tool is an MVC view while all other tools in admin are using Webforms. I'm thinking that the cause might be in there somewhere. However the dashboard and gadgets (using MVC) are working fine.
I get an error from IIS: 401.0 Unauthorized, but I can see that it is looking for a physical path that it shouldn't look for (and which doesn't exist). Instead of going to program files as the virtual path mapping says it just appends the path ([UI URL]/Shell/Search/Settings) to the physical path of the website root. This is apparently not the case with the "root" of that mapping ([UI URL]) - the path of the dashboard which is working. Somehow something interferes in this virtual path mapping and MVC routing mess.
I have tried to reduce the modules and handler sections of web.config but I'm unable to put it exactly as in a new fresh install (in which the search settings are working, on the same server) since the website in question uses a WIF-based sign-in process that uses a few modules. Without those modules the code doesn't run (the resulting Principal is heavily used) so I can't remove them without a lot of work. Could they have anything to do with this problem, or does anyone have any other suggestions what to look for?
Thanks in advance!Magnus
Look in episerver.config if you have a virtual role CmsAdmins, that one will map up which roles are allowed to access the admin controllers such as search settings.
Thanks for the suggestion. CmsAdmins was OK though. CMSEditors on the other hand was wrong but correcting it does not seem to help (I didn't expect it to). OnlineCenter worked anyway, but I guess it's because that does not require editor access (should be available for all users).
Any other suggestions?
Not really, that page basically checks IsInRole("CmsAdmins"), or actually an [Authorize(Roles = "CmsAdmins")] attribute in MVC.
Maybe it's not access rights att all. It doesn't seem to understand that the path is an MVC route or even that it's a path handled by the VPP rather than a relative physical path. The 401 should really be a 404, but perhaps 401 is the correct for non-existing directories (which it interprets the route as).