ASP.NET MVC RC1, ValidateInput, A potential dangerous request and the Pitfall

In the latest release of ASP.NET MVC, a new attribute ValidateInput is introduced which is same as Web Forms ValidateRequest page directive, certainly a good choice. Phil Haack blogged it, so as Steven Smith and also Nick Berarrdi. But it starts to break when you want to accept html tags from your user and using RenderAction of MVC Future to render different parts of your page. Consider the following screenshot DotNetShoutout story submit page:

Submit

  1. Rendered by Html.RenderAction<MembershipController>(c => c.Menu()) in Master Page.
  2. Rendered by Html.RenderAction<CategoryController>(c => c.Menu()) in Master Page.
  3. This is original request StoryController.Submit.
  4. Rendered by Html.RenderAction<TagController>(c => c.Tabs()) in Master Page.
  5. Rendered by Html.RenderAction<CategoryController>(c => c.RadioButtonList()) in Content Page.

The story description box will allow few known html tags and for this I have to decorate all of the above controllers method with ValidateInput(false) which is bit of annoying. I think the problem is mainly in MVC Future as it takes the same HttpContext but does not mark it as child/worker request (which I think it should) so when the ControllerActionInvoker.InvokeAction() comes into the action it does not takes the original attribute decoration into consideration. This is not a big deal for a small app like KiGG, but is definitely going to be if I am planning to develop DotNetNuke like CMS with ASP.NET MVC.

I think I need to take a look at the MVCContrib, how they have handled this situation with SubController.

Shout it

2 Comments

Comments have been disabled for this content.