Blocking Direct Access To Views in ASP.NET MVC

Feb 12, 2008 aspnet aspnetmvc code suggest edit

UPDATE: I improved this based on some feedback in my comments.

With ASP.NET MVC it is possible for someone to try and navigate directly to a .aspx view. In general, this only leaves them with an ugly error message as Views typically need ViewData in order to work.

However, one approach that I think will easily work is to create a Web.config file in the root of your Views directory that contains the following.

We need to do more testing on our side to make sure there’s no pathological case in doing this, but so far in my personal testing, it seems to work.

<?xml version="1.0"?>
<configuration>
  <system.web>
    <httpHandlers>
      <remove verb="*" path="*.aspx"/>
      <add path="*.aspx" verb="*" 
          type="System.Web.HttpNotFoundHandler"/>
    </httpHandlers>
  </system.web>

  <system.webServer>
    <validation validateIntegratedModeConfiguration="false"/>
    <handlers>
      <remove name="PageHandlerFactory-ISAPI-2.0"/>
      <remove name="PageHandlerFactory-ISAPI-1.1"/>
      <remove name="PageHandlerFactory-Integrated"/>
      <add name="BlockViewHandler" path="*.aspx" verb="*" 
        preCondition="integratedMode" 
        type="System.Web.HttpNotFoundHandler"/>
    </handlers>
  </system.webServer>
</configuration>

Let me know if you run into problems with this.

Found a typo or mistake in the post? suggest edit

Comments

22 responses

Garry Shutler • February 11th, 2008
I've had problems with common files such as style sheets not being retrieved when denying all users. Might be worth checking.
Chris Ortman • February 11th, 2008
I think you will also need to be using an IIS wildcard mapping or make sure that whatever extension your views use is mapped to the ASP.Net ISAPI dll.
Scott Bellware • February 11th, 2008
Why not just make it part of the convention of the framework? If your routing engine is on-line, then it could simply deny access to the conventional path where the views live.
Mike Bosch • February 11th, 2008
If we're using Membership, wouldn't this redirect the user to the login url?
Chris Ortman • February 12th, 2008
Probably the better way to do this is to map these files to the ASP.Net forbidden handler.
@Scott: I have no problem with the out of the box behaviour being that requests to those resources are denied, but I think you'd be giving responsibilities to the RoutingEngine that it ought not to have. The RoutingEngine's job is to turn a URL into :controller, :action, :params not authorize access to resources.
Damien Guard • February 12th, 2008
You might also want to consider:
<httpHandlers> <remove verb="*" path="*.asmx"/> <add path="*.aspx" verb="*" type="System.Web.HttpForbiddenHandler"/> </httpHandlers>
Damien Guard • February 12th, 2008
Actually, even better don't even reveal their existance:
<httpHandlers>
<remove verb="*" path="*.aspx"/>
<add path="*.aspx" verb="*" type="System.Web.HttpNotFoundHandler"/>
</httpHandlers>
Haacked • February 12th, 2008
Thanks for the feedback Damien et all! I'll make those changes.
Scott Bellware • February 12th, 2008
Chris,
I'm really not talking about authorization, I'm talking about what makes sense for requests processed by the MVC framework, or the request handlers in ASP.
The routing engine exposes a meaningful, higher-level API for configuring request handling. That means that it has the ability to treat requests for internal, framework-specific resources as requests for resources that don't exist.
So, if you've got the MVC framework in-play in your app, then the framework's code should be responsible for default behaviors for request routing for resources that are its concern.
Matt • February 12th, 2008
One selling point for those who like WebForms is that you don't have to give them up to incorporate MVC. Isn't this in conflict with that point?
Aaron Jensen • February 12th, 2008
I'll revert again to my longstanding assertion that you should strongly consider changing the extension of the views. The views are *not* aspx pages and the proof is here and everywhere else you look. I've heard the argument that you want to reuse stuff from aspx, which I can understand, but I don't think that's a good thing either. It gives functionality to the aspx view engine that other view engines must emulate or be left behind. I'm excited to see the next release, but I really think a rename/refactor of the view needs to happen.
Justice~! • February 12th, 2008
Matt - but who really likes WebForms anyway? In the end, you need to make the right choice. The choice for your CHILDREN.
Chris Ortman • February 12th, 2008
@Scott: Even in rails the RoutingEngine doesn't have any 'default' behavior. The generator does however setup the conventional controller/action routes.
Think about how you would build it. Would you have the routing engine automatically redirect anything requested from /views ? What if I have a views controller or area? So now you got to add complexity to the routing engine to control the behavior anyway.
When it really is as simple as having the MVC project template generate a web.config file with the proper handler mappings.
That said, I don't think either solution is ideal. I would much rather have a 'public' folder that is setup in IIS with the rest of my app code in a level above.
@Aaron: +1
I like the Rails 2.0 naming convention of viewname.viewengine.responseformat. So something more like View.aspx.html
Joe Chung • February 13th, 2008
It's looking. You'll need this:
<configuration>
<system.webServer>
<validation validateIntegratedModeConfiguration="false"/>
</system.webServer>
</configuration>
to have both styles of HTTP handler configuration work properly on an IIS 7 box that has II6 compatibility mode enabled.
Joe Chung • February 13th, 2008
Err, it's looking good, that is.
Haacked • February 13th, 2008
Thanks Joe!
Troy Cox • February 14th, 2008
What would this do to public sites where search engine bots are important for traffic?
Haacked • February 14th, 2008
@Troy Nothing. You're blocking access to the view templates, not to the site itself.
Dan P • March 7th, 2008
I tried this out, but it seems to ignore a 404 errorpage specified in web.config. All I get is the default asp.net 404 page. Has anyone else run into this problem?
Dan P • March 7th, 2008
Nevermind, it does work as I expected, I'm just an idiot. Next time I need to remember that I set RemoteOnly for the error pages.
snighda • November 12th, 2010
casinos online
Why not just make it part of the convention of the framework? If your routing engine is on-line, then it could simply deny access to the conventional path where the views live.Thanks a lot for this article. I've implemented your code in my project a it saved my deathline. Thanks again
Khalid • September 30th, 2012
if anyone has solution