ASP.NET MVC 3 Beta 1 Blocco Accesso alle visualizzazioni del rasoio

Question

C'è un modo per bloccare l'accesso (404) alle visualizzazioni del rasoio in MVC 3 beta 1? Quando creo un nuovo sito vuoto (IIS7) e quindi accedere /views/home/index.cshtml dal browser, al posto del 404 ottengo questo

[InvalidCastException: Unable to cast object of type 'ASP.Index_cshtml' to type 'System.Web.IHttpHandler'.] 
    System.Web.WebPages.WebPageHttpHandler.CreateFromVirtualPath(String virtualPath, VirtualPathFactoryManager virtualPathFactoryManager) +56 
    System.Web.WebPages.WebPageRoute.DoPostResolveRequestCache(HttpContextBase context) +253 
    System.Web.WebPages.WebPageHttpModule.OnApplicationPostResolveRequestCache(Object sender, EventArgs e) +89 
    System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +148 
    System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +75 

Di default il file web.config nelle viste la cartella è impostata per bloccare tutte le richieste di file, ma ovviamente questa richiesta è ancora in fase di completamento.

Procedura per riprodurre:
File -> Nuovo progetto
ASP.NET MVC 3 Web Application
Internet Application (Razor)
F5
Spostarsi /views/home/index.cshtml

Answer 1

Sono un vantaggio dev team di ASP.NET sul lavoro su sia ASP.NET MVC 3 e pagine Web ASP.NET e Razor.

Questo non è completamente risolto in ASP.NET MVC 3 RC, ma sarà completamente risolto in ASP.NET MVC 3 RTM.

Non

c'è nulla di "terribilmente male" che accade in ASP.NET MVC 3 RC o precedenti: La cosa peggiore che può succedere è che qualcuno in grado di rilevare se una visualizzazione esiste nel vostro app - ma non può farlo funzionare (a causa di quella strana eccezione). Questo è un leggero problema di sicurezza in quanto è una forma di divulgazione di informazioni, ma non è un problema molto grave.

In ASP.NET MVC 3 RTM tutte le visualizzazioni di Razor in ~/Views/... così come tutte le visualizzazioni di Razor all'interno di un'area MVC sono bloccate al 100% e non saranno eseguibili direttamente dal browser. Saranno eseguibili solo come pagine di visualizzazione MVC.

Answer 2

Probabilmente è possibile utilizzare alcune regole di riscrittura in web.config per reindirizzare l'utente dal file .cshtml direttamente collegato all'azione effettiva o semplicemente reindirizzare/riscriverlo su una pagina 404.

<system.webServer> 
    <rewrite> 
     <rules> 
      <rule name="rule1" patternSyntax="Wildcard" stopProcessing="true"> 
       <match url="*.cshtml" /> 
       <action type="Redirect" url="http://www.example.com/some404.html" /> 
      </rule> 
     </rules> 
    </rewrite> 
</system.webServer> 

Update: Una versione più complessa per Marius Schulz (che in basso ha votato questo Wasa thekaido anche difficile chiedere solo per 404s). Ciò richiederà un URL come views/home/index.cshtml?key=value e lo reindirizzerà a home/index?key=value. Si tratta di un reindirizzamento 301, ma può anche essere una riscrittura o qualche altro codice di stato HTTP - more here

<rule name="cshtml" stopProcessing="true"> 
    <match url="^views/([^/]+)/([^.]+)\.(?:cshtml|aspx)" /> 
    <action type="Redirect" url="{R:1}/{R:2}" /> 
</rule> 

Naturalmente questo funziona senza la stringa di query (la parte ?key=value). L'unico inconveniente è che web.config non conosce le rotte registrate (di solito in Global.asax.cs). E, per quanto ne so, ora è possibile. Per questo dovrai scrivere un codice personalizzato. Guarda this article di Phil Haack e il codice sorgente che lo accompagna.

(E per favore voto non verso il basso solo perché non si adatta alle tue esigenze, anche se sto rispondendo alla domanda di un'altra persona.)

Answer 3

Per coloro migrato da MVC3 RC in RTM, assicurarsi che si guarda in \ vista \ web.config, e aggiungere la seguente configurazione

<appSettings> 
    <add key="webpages:Enabled" value="false" /> 
    </appSettings> 

Questa è la volontà di assicurarsi che tutti i file di visualizzazione (*. cshtml) restituisce 404 non trovato.