In Teil 1 ging es darum, wie die ASP.NET 3.5 Routing Engine in einer WebForms Applikation genutzt werden kann. Angeschaut wurde die Konfiguration der Applikation für die Engine, und das Definieren und Auswerten eigener Routen.
In diesem zweiten Teil werden nun die Security Aspekte angeschaut.

Das Routing Modul verarbeitet die Events in der Request Pipeline nachdem die Authentisierung und Autorisierung bereits stattgefunden hat. Das bedeutet, dass die Benutzer anhand der sichtbaren URL autorisiert werden und nicht über den virtuellen Pfad zum WebForm.

Wenn also der Zugriff auf unsere Beispiel URL “customer/” nur authentisierten Benutzern gestattet sein soll, kann dies über einen Eintrag im Root web.config erreicht werden:

<location path="customer">
  <system.web>
    <authorization>
      <deny users="?" />
    </authorization>
  </system.web>
</location>

Anonyme Benutzer der Applikation können nun nicht mehr auf Adressen wie “customer” oder “customer/42″ zugreifen, sondern werden auf eine Login Seite umgeleitet. Diese enthält sogar den Pfad unserer Route:

Login mit Return URL

Nun muss noch sichergestellt werden, dass die Authorisation Prüfung über den virtuellen Pfad erfolgt, den der RouteHandler verwendet. Die Methode GetHttpHandler sieht also wie folgt aus:

public IHttpHandler GetHttpHandler(RequestContext requestContext)
{
    if (!UrlAuthorizationModule.CheckUrlAccessForPrincipal(_virtualPath, requestContext.HttpContext.User, requestContext.HttpContext.Request.HttpMethod))
    {
        requestContext.HttpContext.Response.StatusCode = (int)HttpStatusCode.Unauthorized;
        requestContext.HttpContext.Response.End();
    }

    var page = BuildManager.CreateInstanceFromVirtualPath(_virtualPath, typeof(Page));

    var queryString = new StringBuilder("?");
    foreach (var rdv in requestContext.RouteData.Values)
    {
        queryString.Append(requestContext.HttpContext.Server.UrlEncode(rdv.Key));
        queryString.Append("=");
        queryString.Append(requestContext.HttpContext.Server.UrlEncode(rdv.Value.ToString()));
        queryString.Append("&");
    }
    queryString.Remove(queryString.Length - 1, 1);

    HttpContext.Current.RewritePath(string.Concat(_virtualPath, queryString));

    return (IHttpHandler)page;
}

Eine letzte Einstellung ist noch nötig. Anonyme Benutzer können immer noch direkt über den physikalischen Pfad (z.B. ~/Customers/CustomerDetail.aspx) auf die WebForms zugreifen. Dies kann verhindert werden, indem eine web.config Datei im entsprechenden Verzeichnis angelegt wird:

<configuration>
  <system.web>
    <authorization>
      <deny users="?" />
    </authorization>
  </system.web>
</configuration>

Ich habe ein Beispielprojekt zusammengestellt, welches alle besprochenen Elemente zeigt: RoutingWebApplication.zip

Einer der Gründe, weshalb ich das ASP.NET MVC Framework mag, ist die durchgehende Verwendung der sehr flexiblen Routing Engine. In einem MVC Projekt ist das Addressierungsschema komplett vom physikalischen Filesystem getrennt. So lassen sich einfach Applikationen im REST Stil bauen. Adressen wie “http://applikation/Kunde/42″ oder “http://applikation/Kunde/42/Bestellungen” sind auch deutlich SEO freundlicher als die direkte Adressierung auf ein physikalisch vorhandenes File.

Die Routing Engine ist jedoch nicht Bestandteil des MVC Frameworks, sondern wurde mit .NET 3.5 SP1 eingeführt. Somit kann sie auch in einem WebForm Projekt verwendet werden. Der Aufwand hält sich dabei in Grenzen, das ganze ist recht schnell umgesetzt.

Teil 1 dieses Artikels zeigt die Konfiguration der Routing Engine in einer WebForms Applikation und das Anlegen eigener Routen. In einem zweiten Teil werden dann die Security Einstellungen betrachtet.

Konfiguration der WebForms Applikation

Um die Routing Engine nutzen zu können, müssen im Projekt zwei Verweise gesetzt werden: System.Web.Routing und System.Web.Abstractions sind beide im GAC installiert, sie können einfach über “Add Reference” hinzugefügt werden.

Danach muss das Routing Modul im web.config in die Request Pipeline konfiguriert werden. Unter IIS 6 geschieht dies wie folgt:

<httpModules>
  ...
  <add name="RoutingModule"
       type="System.Web.Routing.UrlRoutingModule, System.Web.Routing, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

Wenn IIS 7 verwendet wird, müssen die folgenden Einträge gemacht werden:

<system.webServer>
  <modules runAllManagedModulesForAllRequests="true">
    ...
    <add name="UrlRoutingModule"
         type="System.Web.Routing.UrlRoutingModule, System.Web.Routing, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35&" />
    ...
  </modules>

  <handlers>
    ...
    <add name="UrlRoutingHandler"
         preCondition="integratedMode"
         verb="*" path="UrlRouting.axd"
         type="System.Web.HttpForbiddenHandler, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
    ...
  </handlers>
</system.webServer>

Wenn die Zielumgebung bekannt ist, kann auf die eine Variante verzichtet werden, Einträge für IIS 6 werden allerdings vom IIS 7 ignoriert, und umgekehrt auch, so dass getrost beide Varianten eingetragen werden können.

Konfiguration der Routen

Falls nicht bereits vorhanden, wird eine global.asax Datei zum Projekt hinzugefügt. In dessen Application_Start Event können die Routen eingetragen werden. Eine Route hat immer einen eindeutigen Namen, definiert ein Adressenmuster und legt fest, von welchem Handler Anfragen an diese Adresse bearbeitet werden:

RouteTable.Routes.Add("Customers", new Route("customer/", new PageRouteHandler("~/Customers/Customers.aspx")));
RouteTable.Routes.Add("CustomerDetails", new Route("customer/{id}", new PageRouteHandler("~/Customers/CustomerDetails.aspx")));

Dies erstellt zwei Einträge in der Routing Tabelle. Der zweite Eintrag verwendet einen Parameter “id”, wenn also ein Request in der Form “customer/42″ eintrifft, wird dieser Eintrag verwendet.

Zu beachten ist, dass beim Eintreffen eines Requests diese Routing Tabelle von oben nach unten abgearbeitet wird, und der erste zur Request Adresse passende Eintrag verwendet wird. Nachfolgende Einträge werden ignoriert.

Nun muss der PageRouteHandler angelegt werden, welcher diese Anfragen bearbeiten kann. Dies ist eine Klasse, welche das IRouteHandler Interface implementiert:

public class PageRouteHandler : IRouteHandler
{
    private readonly string _virtualPath;

    public PageRouteHandler(string virtualPath)
    {
        _virtualPath = virtualPath;
    }

    public IHttpHandler GetHttpHandler(RequestContext requestContext)
    {
       var page = BuildManager.CreateInstanceFromVirtualPath(_virtualPath, typeof(Page));
       return (IHttpHandler)page;
    }
}

Dies ist bereits alles, was benötigt wird, um eigene Routen zu definieren und an Webforms weiterzuleiten. Jedoch gelangt im zweiten Fall, wenn eine ID übergeben wird, diese nicht bis zum Webform. Dies kann gelöst werden, indem innerhalb des Routing Handlers die Routing Daten des RequestContext an das Webform weitergeleitet werden. Die Methode GetHttpHandler sieht also wie folgt aus:

public IHttpHandler GetHttpHandler(RequestContext requestContext)
{
    var page = BuildManager.CreateInstanceFromVirtualPath(_virtualPath, typeof(Page));

    var queryString = new StringBuilder("?");
    foreach (var rdv in requestContext.RouteData.Values)
    {
        queryString.Append(requestContext.HttpContext.Server.UrlEncode(rdv.Key));
        queryString.Append("=");
        queryString.Append(requestContext.HttpContext.Server.UrlEncode(rdv.Value.ToString()));
        queryString.Append("&");
    }
    queryString.Remove(queryString.Length - 1, 1);

    HttpContext.Current.RewritePath(string.Concat(_virtualPath, queryString));

    return (IHttpHandler)page;
}

Einer der grossen Pluspunkte des ASP.NET MVC Frameworks ist, dass viel von der bestehenden ASP.NET Infrastruktur weiterverwendet werden kann. In einigen wenigen Fällen lassen sich auch die WebForm Server Controls sinnvoll einsetzen. Dies ist möglich, solange die Standard WebFormViewEngine verwendet wird.

Ein sehr praktisches Feature der klassischen Webforms ist das Security Trimming, also das Anzeigen von rollenbasierten Inhalten. Je nach Rolle, welche der eingeloggte Benutzer zugewiesen hat, werden ihm nur für diese Rolle passende Inhalte angezeigt. Das ganze Membership System der Webforms wird vom MVC Framework unterstützt. Auch das LoginView Control lässt sich im MVC Framework verwenden, da es keinen ViewState benötigt:

<asp:LoginView ID="LoginView1" runat="server">
  <AnonymousTemplate>I can be seen when the user is Anonymous.</AnonymousTemplate>
  <LoggedInTemplate>I can only be seen when a user without group membership is logged in.</LoggedInTemplate>
  <RoleGroups>
    <asp:RoleGroup Roles="Admin,User">
      <ContentTemplate>Only users with the "Admin" and "User" role can see this.</ContentTemplate>
    </asp:RoleGroup>
    <asp:RoleGroup Roles="Admin">
      <ContentTemplate>Only users with the "Admin" role can see this.</ContentTemplate>
    </asp:RoleGroup>
    <asp:RoleGroup Roles="User">
      <ContentTemplate>Only users with the "User" role can see this.</ContentTemplate>
    </asp:RoleGroup>
  </RoleGroups>
</asp:LoginView>

Zu beachten ist, dass die RoleGroups Templates der Reihe nach ausgewertet werden. Nur das erste zu einer Benutzerrolle passende Template wird angezeigt, die anderen nicht. Wenn sich also im Beispielprojekt ein Benutzer mit einer “User” Rolle einloggt, wird er nur das erste RoleGroup Template sehen.
Das LoggedInTemplate wird nur dann angezeigt, wenn kein RoleGroup Template zur Benutzerrolle passt.

Ich habe ein Beispielprojekt zusammengestellt, welches das LoginView Control im Einsatz zeigt. Das Projekt verwendet eine SQLite Datenbank und die SQLite Membership Provider von Roger Martin.

Download des Beispielprojekts: SecurityTrimming.zip

Ich schreibe mal wieder nur ab: Microsoft veröffentlich endlich auch ein eigenes Chart Control. Das ganze wird im Blog von Scott Guthrie als ASP.NET Charting Control angepriesen. Gerüchten zufolge werkelt unter der Haube Technologie von Dundas, dies ist schon mal ein Garant für gut designte Controls und durchdachte APIs. Der Komponenten Pionier lieferte bereits die Charting Technologie für die Reporting Services von SQL Server 2008.
Bislang musste man ja entweder auf das Angebot eines Drittherstellers zurückgreifen, oder eben selber in die Tasten greifen, wenn man Charts oder ganz allgemein dynamische Grafiken serverseitig erzeugen wollte. Mit GDI+ war das grundsätzlich auch recht einfach machbar, aber eben von Microsoft nicht unterstützt.
Die offizielle MSDN Dokumentation des System.Drawing Namespaces ist zu diesem Punkt nicht allzu ausführlich:

Classes within the System.Drawing namespace are not supported for use within a Windows or ASP.NET service. Attempting to use these classes from within one of these application types may produce unexpected problems, such as diminished service performance and run-time exceptions.

Obwohl es nahezu nie Probleme gab, alles immer auch performant funktionierte, hatte ich immer ein ungutes Gefühl während der Entwicklung solcher .NET Komponenten.
Wenn mal was schiefgehen sollte, hat man keine Hilfe zu erwarten. Die sehr komplexe und aufwändige Entwicklung von GDI COM Komponenten kommt kaum als Alternative in Frage.

Während sich nun die ganze .NET Entwickler Welt über das längst fällige Control für die Webentwicklung freut, nehme ich zufrieden zur Kenntnis, dass das ganze auch für die in letzter Zeit von Microsoft stark vernachlässigten WinForms funktioniert. Schade ist nur, dass die Controls .NET 3.5 SP1 voraussetzen.