Teil 2: Unnötige HTTP Response-Header entfernen

Wenn wir im Internet surfen werden oft Informationen über uns ohne unser Zutun bei jedem Request an den Server übertragen. Dies geschieht über die HTTP-Header. So wird z.B. die Adresse der Seite auf der wir einen Link geklickt haben in dem Referrer-Header an den Server übertragen.

Aber auch die Server selbst sind in dieser Sache oft sehr gesprächig und verraten mehr über sich als wirklich nötig ist.

Eine Typische ASP.NET Serverantwort

In dem Bild sieht man (rot eingerahmt) Informationen die der Server über unsere Anwendung nach außen gibt, die eigentlich lieber geheim bleiben sollten.

Warum ist das gefährlich?

Die Informationen, die hier angezeigt werden verraten die Version des Servers, der Laufzeitumgebung und die Version des Frameworks, das wir benutzen. In diesem Fall ASP.NET MVC 3.

Falls nun bekannt wird, dass der Server oder ASP.NET in dieser Version eine Sicherheitslücke aufweist, sieht ein potentieller Angreifer sofort, dass unsere Seite für eine Attacke anfällig ist.

Es gibt sogar extra Tools, die das Web nach Webseiten durchsuchen, die eine Serverversion aufweisen, die als unsicher eingestuft wird oder für die es bekannte Lücken gibt. Diese Tools nutzen unter Anderem dann auch diese Informationen um zu prüfen ob es sich lohnt bei dieser Seite einen Angriff zu starten.

Was nun?

Im Grunde ist die Aufgabe sehr einfach, wir müssen diese unnötigen Serverheader ausblenden. Wenn die Webseite dann keine anderen Frameworkspezifischen Merkmale aufweist (wie z.B. einen Viewstate) ist es für einen Besucher praktisch unmöglich herauszufinden, welcher Server und welches Framework im Backend laufen.

Die Umsetzung

Leider ist ASP.NET in dieser Hinsicht noch nicht so richtig benutzerfreundlich, denn um all diese Header zu entfernen müssen wir an einigen verschiedenen Stellen Änderungen vornehmen. Gehen wir mal Schritt für Schritt alles durch.

1. ASP.NET &  MVC Header

Diesen Header können wir recht einfach entfernen, indem wir in der global.asax die nötige Property setzen:

protected void Application_Start()
{
    MvcHandler.DisableMvcResponseHeader = true; //<- Hier

    AreaRegistration.RegisterAllAreas();

    Database.SetInitializer(new F1DBInitializer());

    RegisterGlobalFilters(GlobalFilters.Filters);
    RegisterRoutes(RouteTable.Routes);
}

Dies hat schon eine Gute Wirkung auf unsere Response Header:

Verbliebene Response Header

Die Version von ASP.NET und des MVC Frameworks wird nun nicht mehr angezeigt. Nun zu den anderen.

2. X-Powered-By Header

Um diesen Header zu entfernen müssen wir unsere web.config ergänzen (Quelle):

<?xml version="1.0"?>
<configuration>

  <system.web>
    <httpRuntime enableVersionHeader="false" />
    ...
  </system.web>

  <system.webServer>
    ...
    <httpProtocol>
      <customHeaders>
        <remove name="X-Powered-By" />
      </customHeaders>
    </httpProtocol>
  </system.webServer>

 ...
</configuration>

Dann verabschiedet sich auch dieser Header.

Und auch X-Powered-By ist nun weg

3. Einer geht noch: Der Server-Header

Dies geht leider nicht so einfach durch das Setzen eines Configparameters, hier müssen wir selbst Hand anlegen und diesen Header aus der Response löschen. Dazu schreiben wir uns ein eigenes HttpModul (Quelle):

public class RemoveServerHeaderModule : IHttpModule
{
    public void Init(HttpApplication context)
    {
        context.PreSendRequestHeaders += OnPreSendRequestHeaders;
    }

    public void Dispose()
    { }

    void OnPreSendRequestHeaders(object sender, EventArgs e)
    {
        HttpContext.Current.Response.Headers.Remove("Server");
    }
}

Anschließend müssen wir das neue Modul über die web.config registrieren (Quelle):

<?xml version="1.0"?>
<configuration>
  ...
  <system.webServer>
    <validation validateIntegratedModeConfiguration="false"/>
    <modules runAllManagedModulesForAllRequests="true">
      <add name="RemoveServerHeaderModule" type="SecurityTipp.RemoveServerHeaderModule"/>
    </modules>
	...
  </system.webServer>

</configuration>

Das Ergebnis:

Alle unnötigen Header sind raus

Nun haben wir unser Ziel erreicht und alle Plaudertaschen aus der Response entfernt

Weitergedacht

Hier könnte man nun ansetzen und sogar versuchen den potentiellen Angreifer in die Irre zu führen, indem man einen modifizierten Server-Header zurückgibt der auf eine Ganz andere Serversoftware verweist, Apache oder sowas

Das Schöne hierbei ist weiterhin, dass wir alle diese Änderungen innerhalb unserer App machen können und nicht im IIS rumfummeln müssen. Einerseits weil man da viel kaputtkonfigurieren kann, andererseits weil man nicht immer Zugriff auf den IIS hat, wenn man z.B. nur ein Webspace hat.

Diese Schritte sollten bei jeder Anwendung durchgeführt werden, egal ob MVC, ASP.NET oder PHP, gebt den Besuchern nicht mehr Informationen als sie unbedingt benötigen!

Teil 1: Nutzen des AntiForgeryToken bei POST Requests

POST Requests sind gefährlich, da diese im Normalfall dafür verwendet werden dem Server Informationen mitzuteilen. Die Informationen sollte man natürlich prüfen, auf Form und Inhalt, aber noch wichtiger ist es, zu wissen wer uns diese Daten sendet. (Cross-Site-Attacken verhindern)

Wie funktioniert das?

Mit dem AntiForgeryToken können wir an dieser Stelle sichergehen, dass nur Formulare am Server angenommen werden, die der Server selbst erzeugt hat.
Dabei erzeugt der Server beim Generieren des Formulars einen Token und speichert diesen in einem versteckten Input-Feld (__RequestVerificationToken), des Weiteren wird auch ein Cookie namens "__RequestVerificationToken" mit dem gleichen Token angelegt, sodass beim Absenden des Formulars sowohl der Cookie als auch das versteckte Feld wieder zurück an den Server übertragen wird.

Wenn der Server diesen Request empfängt prüft er diesen Token aus dem versteckten Feld gegen das Token aus dem Cookie. Gibt es hier keine Übereinstimmung wird der Request abgewiesen.

Wie wird das implementiert?

Als Erstes muss das Token in das Formular gesetzt werden und das Cookie erzeugt werden. Diese Aufgabe übernimmt für und der kleine Html-Helper aus MVC.

<div class="myForm">
    @using (Html.BeginForm())
    {
        @Html.AntiForgeryToken()

        <!-- REST DES FORMULARS -->
    }
</div>

Das ging ja einfach, nun müssen wir dafür sorgen, dass dieses Token beim Verarbeiten des Requests auch geprüft wird.

[ValidateAntiForgeryToken]
public ActionResult UpdateStuff()
{
...
}

Mehr ist das nicht, ein einfaches Attribut genügt, und unsere MVC Anwendung ist mit nur zwei Zeilen sicherer geworden.

Wenn Ihr nun einen Blick in euer gerendertes Formular werft, werdet ihr etwas in der Art finden:

<input name="__RequestVerificationToken" type="hidden" value="4PhvBw7EO5I3O4zw2cdYkaEfSJycy1Ugi8AOT6glW6IqZNnVKXTzL52LgQGNMviOhYTxAOQH3iZRtehUoHKRprcHXa8YNel6RzVmKjGAEi0W0duRpnwJu9EpR7ybAoZX9yqeiP3Pyng/ma1t/k6QhM2bbcoBgkou5y0KXEj8Ut8=" />

Gibt es Einschränkungen?

• Da hier ein Cookie gesetzt wird müssen natürlich Cookies aktiviert sein da der Server sonst alle Requests abweisen wird.
• Das Ganze funktioniert nur mit POST Requests, was auch logisch ist, da GET Requests nur zum Abfragen von Informationen genutzt werden sollten.

Alternativen?

Wenn man keine Cookies nutzen will kann man ein ähnliches Verhalten hervorrufen, indem man prüft ob der eingehende Request ein Referrer-Header besitzt der auf unsere eigene Domain + URL verweist.
Dies ist natürlich nicht wirklich Sicher, da es leicht zu fälschen ist und außerdem haben manche Browser Anonymisierungsfunktionen die diese Header-Felder nicht mitsenden, also ist hier Vorsicht geboten.

ASP.NET MVC 3 bietet euch einen Helper der eine sehr ähnliche Funktionalität bietet und sehr einfach in eure MVC Anwendung zu integrieren ist.

Das Schöne ist, dass wenn ihr das aktuelle Visual Studio Tools update installiert habt, ihr diesen Helper bereits out of the box nutzen. Falls nicht könnt ihr es über das NuGet Paket bequem nachinstallieren.

Hier ein kleines Beispiel wie eine Action aussehen kann, die ein Chart erzeugen soll:

Beispiel 1

    public ActionResult CreateChart()
    {
        Chart bytes = new Chart(width: 400, height: 200)
            .AddSeries(
                chartType: "column",
                xValue: new[] { "Wert1", "Wert2", "Wert3", "Wert4" },
                yValues: new[] { "12", "3", "23", "11" })
            .AddSeries(
                chartType: "column",
                xValue: new[] { "Wert1", "Wert2", "Wert3", "Wert4" },
                yValues: new[] { "13", "32", "23", "5" });

            return File(bytes.GetBytes("png"), "image/png");
    }

Wie man sieht wird hier nachdem das Chart erstellt wurde eine Grafik daraus gemacht und diese dann an die View zur Anzeige gesendet. Der Aufruf in der View ist dementsprechend simpel:

<img src="@Url.Action("CreateChart")" alt="Beschreibung" />

Was vielleicht nicht auf den ersten Blick ersichtlich ist, ist wie man eine legende zu dem Chart anzeigen lassen kann. Dazu muss jede "Serie" einen namen erhalten und zum Schluss kann man dann die "AddLegend()" Methode ohne Parameter aufrufen:

Beispiel 2

    public ActionResult CreateChart()
    {
        Chart chart = new Chart(width: 400, height: 200)
            .AddSeries(
                chartType: "column",
                xValue: new[] { "Wert1", "Wert2", "Wert3", "Wert4" },
                name: "Serie 1",
                yValues: new[] { "12", "3", "23", "11" })
            .AddSeries(
                chartType: "column",
                xValue: new[] { "Wert1", "Wert2", "Wert3", "Wert4" },
                name: "Serie 2",
                yValues: new[] { "13", "32", "23", "5" });

        chart.AddLegend();

        return File(chart.GetBytes("png"), "image/png");
    }

Noch etwas umständlicher wird es, wenn man nun die legende an eine andere Stelle setzen will, denn hier muss ein eigenes Theme her. Dieses sollte dann auch nur die Felder enthalten die man ändern will. Wenn man z.B. die legende unten angezeigt haben möchte kann man so vorgehen:

Beispiel 3

        public ActionResult CreateChart()
        {
            string theme = @"<Chart BackColor=""WhiteSmoke"" >
                                    <ChartAreas>
                                        <ChartArea Name=""Default"" BackColor=""White"">
                                    </ChartAreas>
                                    <Legends>
                                        <Legend _Template_=""All"" BackColor=""Transparent"" Font=""Trebuchet MS, 9pt"" IsTextAutoFit=""False"" Docking=""Bottom"" />
                                    </Legends>
                                </Chart>";

            Chart chart = new Chart(width: 400, height: 200, theme: theme)
                .AddSeries(
                    chartType: "column",
                    xValue: new[] { "Wert1", "Wert2", "Wert3", "Wert4" },
                    name: "Serie 1",
                    yValues: new[] { "12", "3", "23", "11" })
                .AddSeries(
                    chartType: "column",
                    xValue: new[] { "Wert1", "Wert2", "Wert3", "Wert4" },
                    name: "Serie 2",
                    yValues: new[] { "13", "32", "23", "5" });

            chart.AddLegend();

            return File(chart.GetBytes("png"), "image/png");
        }

Man beachte hier dass dem Chart-Konstruktor ein weiterer Parameter "theme" übergeben wird.

Im Grunde wars das auch schon. An der Handhabung ändert sich nicht viel. Falls ihr euch irgendwo vertippt wird übrigens einfach kein Bild erzeugt, also vorsicht beim Tippen

Konfigurationsfehler

Beschreibung: Fehler beim Verarbeiten einer Konfigurationsdatei, die für diese Anforderung erforderlich ist. Überprüfen Sie die unten angegebenen Fehlerinformationen, und ändern Sie die Konfigurationsdatei entsprechend.

Parserfehlermeldung: Der Verbindungsname LocalSqlServer wurde in der Anwendungskonfiguration nicht gefunden, oder die Verbindungszeichenfolge war leer.

Das Problem ist hier, dass das ASP.NET Membership per Default in der root web.config so konfiguriert ist, dass es den Connectionstring "LocalSqlServer" nutzen soll. Dieser Connectionstring zeigt dann (meistens) auf eine SQL Datenbank die auf dem Hostingsystem (noch) nicht verfügbar ist. An dieser Stelle knallt es dann.

Die einfachste Lösung für dieses Problem ist es den Connectionstring neu zusetzen. Dazu entfernt man erst den Defaulteintrag und setzt den neuen dann auf eine gültige Datenbankverbindung:

	<remove name="LocalSqlServer" />
	<add name="LocalSqlServer"
		connectionString="[EUER CONNECTIONSTRING]"
		providerName="System.Data.SqlClient" />

Dies hat das Problem behoben, sodass die Anwendung wieder wie gewohnt lief.

Was mir noch ein wenig Kopfschmerzen bereitet, ist dass ich das ASP.NET Membership gar nicht nutze und auch keinen "LocalSqlServer" Connectionstring habe. Des Weiteren lief die Anwendung erst wochenlang und plötzlich kam dann dieser Fehler.

Wenn ihr diesen Fehler vielleicht schon kennt oder euch noch was dazu einfällt würde ich mich über einen Kommentar mit einem Tipp freuen.

Das Ganze kann in allen Kommandozeilenfenstern, egal ob Unix oder Windows implementiert werden. Der Schlüssel hierzu ist das Sonderzeichen \b - welches das Drücken der Backspace Taste simuliert. Ähnliche Vertreter sind \t für Tab und \n für Zeilenumbruch.

Solange ihr noch keinen Zeilenumbruch abgesetzt habt könnt ihr jede Ausgabe in der aktuellen Zeile widerrufen durch das ausgeben von \b dabei müsst ihr jedes Zeichen einzeln widerrufen. Wenn wir nun also unser Spinner-beispiel betrachten kann man das sehr einfach in .NET umsetzen:

        static void Main(string[] args) {
            string[] states = { "\\", "|", "/", "-" };
            int cur_state = 0;

            while (true) {
                Thread.Sleep(100);

                Console.Write("\b");
                Console.Write(states[cur_state]);
                cur_state++;
                if (cur_state == 4) {
                    cur_state = 0;
                }
            }
        }

Genauso einfach geht das Ganze dann auch in Java:

        public static void Main(string[] args) {

            string[] states = { "\\", "|", "/", "-" };
            int cur_state = 0;

            while (true) {
                try {
                    Thread.sleep(100);
                } catch (InterruptedException ex) {}

                System.out.print("\b");
                System.out.print(states[cur_state]);
                cur_state++;
                if (cur_state == 4) {
                    cur_state = 0;
                }
            }
        }

Ist in jedem Fall ein nettes Gimmick Beachten sollte man noch, dass man hier print() bzw. Write() benutzen muss und nicht println() oder WriteLine() da hier sonst automatisch ein \n mit an das Ende der Zeile gepackt wird!

Ihr werdet sicher mitbekommen haben, dass HTML5 auf dem Vormarsch ist und auch wenn es immer noch nicht offiziell fertig ist findet man immer häufiger den HTML5-Header <!DOCTYPE html> auf diversen Seiten.

Eins der meiner Meinung nach nützlichsten Features die wir mit HTML5 erhalten sind die neuen Input-Typen. Denn bisher hatten wir keine Wahl und mussten type="text" benutzen!

Die Eingabefelder vom Typ Text konnten natürlich alles enthalten, sind aber nicht gerade Benutzerfreundlich wenn man etwas komplexere Daten eingeben soll wie zum Beispiel ein Datum.

In HTML5 wurden deswegen spezifische Typen für solche immer wieder einkehrende Eingaben eingeführt. Eine von ihnen ist &quot;Date&quot;:

Birthday: <input type="date" name="bday" />

Der große Vorteil hier ist, dass die Browser nun eine eigene Implementierung für diesen Typ von Eingabefeldern machen können. Falls der Browser nun also diesen neuen Eingabe Typ unterstützt blendet er automatisch einem (mehr oder weniger) schönen Date-Picker ein in dem man bequem das Datum wählen kann:

Ansicht des neuen Typen in verschiedenen Browsern

Ein weiterer großer Vorteil ist, dass auch die mobilen Browser wie z.B. auf dem iPhone diese neuen Elemente ebenfalls unterstützen und einen passenden Picker einblenden:

Date-Picker auf dem iPhone

Wie ihr in dem ersten Screenshot sehen könnt unterstützt der FireFox (zumindest zum Zeitpunkt des Screenshots) den neuen Typ nicht. In diesem Fall blendet er ein gewöhnliches Textfeld ein wo wir nun gezwungen sind das Datum auf die gewohnte (unbequeme) Weise einzutragen.

Übrigens, ich glaube ich muss euch nicht sagen warum der Internet Explorer hier nicht mit aufgeführt ist oder?

Und genau das ist das Problem um das es in diesem Blogpost geht. Wenn wir die tollen neuen Elemente nutzen gehen wir das Risiko ein, dass Nutzer die einen älteren Browser nutzen nicht in den Genuss einer bequemen Eingabe kommen.

jQuery Date-Picker

Wir könnten auch komplett auf das HTML5 Element verzichten und direkt alles mit jQuery machen, welches auch einen Date-Picker bietet, aber das ist auch nicht das gelbe vom Ei, denn dann wären die Mobilen Nutzer in Nachteil, da dort die Browser diese Elemente für gewöhnlich unterstützen und eine gewohnte Oberfläche für die Eingabe bieten.

Die Optimale Lösung ist offensichtlich eine Mischung beider Welten. Wenn der Benutzer die Seite mit einem kompatiblen Browser aufruft soll der Date-Picker des Browsers genutzt werden, wenn der Browser aber veraltet ist soll stattdessen der jQuery Fallback greifen und der JavaScript Date-Picker (siehe links) genutzt werden.

Zu unserem Glück macht uns ASP.NET MVC die Umsetzung dieses Plans sehr leicht, da es an den nötigen Stellen sehr einfach erweitert werden kann.

Schauen wir uns mal ein kleines Beispiel an. Wir haben eine Klasse Person, und wollen auch dessen Geburtstag speichern, hier wollen wir die tolle neue Funktionalität nutzen. Implementieren wir das Ganze jedoch erstmal wie gewohnt:

    public class Person
    {
        public int ID { get; set; }
        public String Name { get; set; }
        public DateTime Geburtstag { get; set; }
    }

Wenn wir die Model-Klasse haben können wir das MVC Scaffolding nutzen um für uns eine View zum Erstellen neuer Personen anzulegen:

MVC Scaffolding kommt uns zu Hilfe

Schauen wir uns nun doch mal an was da für uns tolles generiert wurde:

    <div class="editor-field">
        @Html.EditorFor(model => model.Geburtstag)
        @Html.ValidationMessageFor(model => model.Geburtstag)
    </div>

Auffällig hierbei ist, dass hier @Html.EditorFor genutzt wird und nicht etwa @Html.TextBoxFor! Der Hintergrund ist der, dass MVC bei der Generierung versuchen wird ein passendes Element für den angegebenen Datentyp (DateTime) zu bestimmen, aber da MVC standardmäßig nur den Typ Text kennt wird hier eigentlich immer ein Input-Element vom Typ text generiert.

Hier kommt uns die Erweiterbarkeit von MVC zu gute, denn wir können ganz einfach NuGet nutzen um uns die nötige Funktionalität zu verschaffen. Wir installieren das Packet MvcHtml5Templates.

Installation über NuGet

Neue Templates

Nachdem NuGet alles erledigt hat werdet ihr feststellen, dass ihr ein paar neue Dateien in eurem Views/Shared Verzeichnis habt (siehe Bild links). Und wie ihr schon an dem Namen erkennen könnt sind das die neuen Input-Typen aus HTML5.

Diese Templates machen im Grunde nichts anderes als die MVC-Eigenen zu überschreiben und versehen die mit dem passendem Type-Attribut.

Hier sind euch keine Grenzen gesetzt ihr könnt natürlich auch eire eigenen Templates definieren mit euren eigenen Typen. (Auch wenn man das eher selten benötigt)

Das Tolle: mehr müssen wir nicht machen. MVC wird nun zur Laufzeit statt einem Text ein Date Input-Element für uns anlegen. Beachtet, dass das nur geht wenn wir in der View die allgemeine Funktion @Html.EditorFor nutzen und keinen Spezifischen Typ angeben.

Schauen wir mal in den Sourcecode der zur Laufzeit für das Geburtstagsfeld generiert wird:

<input class="text-box single-line"
data-val="true"
data-val-required="Das Feld 'Geburtstag' ist erforderlich"
id="Geburtstag"
name="Geburtstag"
type="datetime"
value=""; />

Wie ihr seht wird nun der Korrekte Typ, nämlich datetime verwendet. Wenn wir die Seite nun also mit einem kompatiblen Browser aufrufen können wir ganz bequem das Datum wählen.

Leider ist der Opera Browser momentan wohl der einzige Desktop Browser der uns hier einen Benutzerfreundlichen Dialog einblendet (siehe erstes Bild oben), somit müssen wir dafür sorgen, dass die Benutzer mit anderen oder alten Browsern nicht benachteiligt werden.

JavaScript Magie

Auch für diese Problematik bringt MVC bereits alles mit was nötig ist sie zu lösen. Werfen wir doch mal einen Blick in unseren Scripts Ordner finden wir alle nötigen jQuery und jQuery UI Skripte, dazu kommt noch die modernizr Bibliothek die uns auch zu Gute kommen wird.

Die jQuery Bibliotheken liefern und die nötige Funktionalität die wir benötigen um diesen hübschen Date-Picker einzublenden.

Die modernizr Bibliothek dagegen hilft uns herauszufinden ob der Browser, den der Benutzer momentan verwendet die gewünschten HTML5 Features unterstützt.

Nun müssen wir also bei unseren Formularen prüfen, ob der Browser die nötigen Funktionen kennt und bei Bedarf die jQuery Klassen einbinden. Das Ganze ist dank der Einfachheit von Modernizr und jQuery ziemlich simpel.

Wechseln wir zu unserer View und fügen die Referenzen auf die nötigen Skripte und CSS Dateien ein:

<script src="@Url.Content("~/Scripts/jquery-1.5.1.js")" type="text/javascript"></script>
<script src="@Url.Content("~/Scripts/jquery-ui-1.8.11.js")" type="text/javascript"></script>
<script src="@Url.Content("~/Scripts/modernizr-1.7.js")" type="text/javascript"></script>
<link href="@Url.Content("~/Content/themes/base/jquery.ui.all.css")" rel="stylesheet" type="text/css" />

Unten in der View fügen wir nun eine Modernizr Abfrage ein und prüfen, ob der Browser das DateTime-Feld unterstützt, und wenn nicht lassen wir jQuery das Ganze für uns regeln:

<script type="text/javascript">
    $(function () {
        if (!Modernizr.inputtypes.date) {
            $("input[type='datetime']").datepicker();
        }
    });
</script>

Mit dem Befehl $("input[type='datetime']").datepicker(); werden alle Input-Felder vom Typ DateTime durch den jQuery Picker ersetzt. Coole Sache!

Unser Browser kennt den Typ nicht

Kleiner Hinweis am Rande: Das ist nicht wirklich best practice da die Skripte auch geladen werden wenn sie gar nicht benötigt werden (der Browser kennt das HTML5 Feld) ich habe das hier der Einfachheit geopfert.

Und das wars auch schon! Alle Browser die das Feld unterstützen blenden nun ihren Picker ein, ansonsten wird der jQuery Fallback genutzt.

Wir müssen uns auch nicht mit irgendwelchen UserAgent-Prüfungen herumschlagen und lassen das alles Modernizr erledigen, der das intern über JavaScript prüft und somit immer aktuell ist. Das heißt dass wenn irgendwann der IE plötzlich die neuen Typen kennt werden diese auch funktionieren!

Genauso könnt ihr auch bei all den anderen neuen HTML5 Typen vorgehen und euren Usern ein bestmögliches Bedienerlebnis bereiten

Doch warum ist das so? Das ist ganz einfach und liegt daran, dass das Konsolenfenster, das unser Programm startet zu einem anderem Prozess gehört, nämlich cmd.exe und somit nicht verbunden ist.

Was wir also tun müssen ist, unsere Ausgabe an das Konsolenfenster zu heften, das unsere Anwendung gestartet hat. Dafür kann man die Win32-Methode AttachConsole nutzen.

Diese ist sehr einfach aufgebaut und sollte vor der ersten Ausgabe an die Konsole aufgerufen werden:

Definition des Win32-Aufrufs: (Beispiele in VB.NET)

    <DllImport("kernel32.dll")> _
    Private Shared Function AttachConsole(dwProcessId As Integer) As Boolean
    End Function

Um die Ausgabe an den Prozess zu geben der uns aufgerufen hat (Parent-Process) kann man hier als Wert -1 übergeben:

    Private Const ATTACH_PARENT_PROCESS As Integer = -1

Was nun noch bleibt ist es die Methode aufzurufen, zum Beispiel in der Main-Methode der Applikation:

    Private Sub frmMain_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
        AttachConsole(ATTACH_PARENT_PROCESS)
        //[...]

Das wars auch schon, nun werden eure Ausgaben an das Konsolenfester umgeleitet. Um die Konsole wieder von eurem Prozess zu lösen kann die paremeterlose Methode FreeConsole genutzt werden.

Es lohnt sich hier natürlich dann auch eine Unterscheidung zu machen wie die App gestartet wurde, also ob über Konsole oder über Doppelklick wie immer. Wenn sie über die Konsole gestartet wird, sollte man vielleicht die Oberfläche nicht mehr anzeigen. Das kann man dann zB. daran erkennen, dass Environment.GetCommandLineArgs.Length > 1 ist.

Probleme

Leider gibts ein paar Nebeneffekte die nicht unbeachtlich sind.

Ein Problem ist, dass Konsolenfuntionen die die Ausgabe von Programmen umleiten zB. so: "myapp.exe -test >test.txt" nicht funktionieren, die Ausgabe erfolgt weiterhin auf der Konsole. Hierfür konnte ich leider keine Lösung finden, wenn euch was einfällt einfach kommentieren.

Das zweite ist nur eine Schönheitssache, nämlich wenn das Programm beendet wird wird erst nicht die gewohnte Konsoleneingabezeile angezeigt, sondern nur der blinkende Cursor, so dass es aussieht als ob das Programm noch laufen würde, was es aber nicht mehr tut. (Wie gesagt Schönheitssache) Das kann man zB. dadurch umgehen, dass man vor dem Beenden des Programms noch ein [Enter] auf der Konsole ausgibt.

Weitere Infos und auch eine kleine Diskussion gibts hier und hier.

Dieses Verhalten kann man in ASP.NET MVC über verschiedene Wege erreichen. Eine beliebte Möglichkeit ist es

die Dateien über einen Controller zu verteilen.

Hierbei erstellt man einen Controller der eine Action hat in der die gewünschte Datei geladen und an den Browser zurückgegeben wird. Hier hat man dann die Bequemlichkeit, dass man problemlos prüfen kann ob der User eingeloggt ist und über die nötigen Rechte für das Bild verfügt. Das geht zum Beispiel mit dem Authorized-Attribut für die Actions.

Implementiert würde so eine Action dann wohl ca so aussehen:

public ActionResult Image(string id)
{
    var dir = Server.MapPath("/Private/Images");
    var path = Path.Combine(dir, id + ".jpg");
    return base.File(path, "image/jpeg");
}

Das Bild kann man dann so abrufen:

<img src="@Html.Content("~/Content/Image/" + model.pictureID)" />

Dieser Ansatz funktioniert problemlos hat aber den kleinen Nachteil, dass er nicht so performant ist wie der direkte Zugriff auf die Ressource.

Eine weitere (und auch meine bevorzugte) Möglichkeit eine solche Zugriffskontrolle zu implementieren ist es durch

einen eigenen RouteHandler.

Eine Beispielimplementierung wie man auf diese Weise Hotlinking verhindern kann habe ich in Mike Brinds Blog gefunden.

Hier sind im Grunde drei kleine Schritte nötig um einen eigenen RouteHandler zum Laufen zu bekommen. (Code von Mikes Blog)

Zunächst müssen wir die RouteHandler Klasse anlegen, die das IRouteHandler Interface und dessen einzige Methode GetHttpHandler implementiert:

public class ImageRouteHandler : IRouteHandler
{
  public IHttpHandler GetHttpHandler(RequestContext requestContext)
  {
    return new ImageHandler(requestContext);
  }
}

Als nächstes erstellen wir die oben genutzte ImageHandler Klasse in der wir das das IHttpHandler Interface implementieren:

public class ImageHandler : IHttpHandler
{
  public ImageHandler(RequestContext context)
  {
    ProcessRequest(context);
  }

  private static void ProcessRequest(RequestContext requestContext)
  {
    var response = requestContext.HttpContext.Response;
    var request = requestContext.HttpContext.Request;
    var server = requestContext.HttpContext.Server;

    var validRequestFile = requestContext.RouteData.Values["filename"].ToString();
    const string invalidRequestFile = "thief.gif";
    var path = server.MapPath("~/graphics/");

    response.Clear();
    response.ContentType = GetContentType(request.Url.ToString());

    if (request.ServerVariables["HTTP_REFERER"] != null &&
        request.ServerVariables["HTTP_REFERER"].Contains("yourdomain.com"))
    {
      response.TransmitFile(path + validRequestFile);
    }
    else
    {
      response.TransmitFile(path + invalidRequestFile);
    }
    response.End();
  }

  private static string GetContentType(string url)
  {
    switch (Path.GetExtension(url))
    {
      case ".gif":
        return "Image/gif";
      case ".jpg":
        return "Image/jpeg";
      case ".png":
        return "Image/png";
      default:
        break;
    }
    return null;
  }

  public bool IsReusable
  {
    get { return false; }
  }
}

Zu Schluss müssen wir diesen neuen Handler mit einer Route in der Global.asax registrieren:

routes.Add("ImagesRoute",
                 new Route("images/{filename}", new ImageRouteHandler()));

Hierbei ist noch wichtig, dass ihr die Route an der passenden Stelle registriert, sodass diese nicht ungewollt von einer anderen Route blockiert wird weil diese auch auf dieses Pattern matcht.

Nun werden alle Requests die auf die Route "images/{filename}" gehen und von einer anderen Domain stammen als eurer eigenen auf eine andere Grafik umgeleitet.

Nun bleibt noch ein kleines Problem, denn wenn das Verzeichnis mit den Bildern in eurem Content Verzeichnis liegt kann immer noch darauf verlinkt werden wenn man den vollen Pfad nimmt, also statt dem virtuellem Pfad

http://localhost/images/myimg.jpg

die URL benutzt unter der tatsächlich alle Bilder liegen:

http://localhost/Content/graphics/myimg.jpg

Dies liegt daran, dass der neue RouteHandler in diesem Fall nicht greift und die Default Route genutzt wird. Am einfachsten kann man dies verhindern wenn man den Zugriff für Unbefugte über die web.config sperrt:

  <location path="Content/graphics">
    <system.web>
      <authorization>
        <allow roles="admin" />
        <deny users="*" />
      </authorization>
    </system.web>
  </location>

Das war dann auch schon, ich nutze gern den zweiten Weg, da dieser mir einfacher und sauberer erscheint. Wenn euch noch andere Möglichkeiten einfallen wie man das anstellen kann dann immer her damit!

Das Ganze funktioniert sehr einfach mit nur einer kleinen rekursiven Funktion:

   ''' <summary>
    ''' Diese Funktion durchläuft den ganzen Treenode bis ein Eintrag gefunden wird der dem Suchbegriff
    ''' gleicht. Danach wird der Pfad der zu diesem TreeNode führt (zur Visualisierung) aufgeklappt
    ''' </summary>
    ''' <param name="tn">Der zu durchsuchende Treenode
    ''' <param name="name">Der Suchbegriff
    Public Sub findNode(ByVal tn As TreeNode, ByVal name As String)
        For Each tnn As TreeNode In tn.Nodes
            If tnn.Text = name Then
                Dim t As TreeNode = tnn
                For i As Integer = tnn.Level To i = 0 Step -1
                    Try
                        t = t.Parent
                        t.Expand()
                    Catch ex As Exception
                    End Try
                Next
                tnn.Parent.Expand()
                Exit Sub
            End If
            findNode(tnn, name)
        Next
    End Sub

Hier laufen wir alle Nodes der TreeView durch bis wir auf einen Node stoßen der unserem Suchbegriff entspricht. Ab hier durchlaufen wir den ganzen Weg rückwärts und klappen alle übergeordneten Nodes auf, sodass wir unseren gesuchten Node zu Gesicht bekommen.

Diese Funktion kann man auch ganz gut als Extension Method umschreiben, sodass diese bequemer aufgerufen werden kann, aber das ist dann natürlich jedem selbst überlassen.

Demoapp in Aktion

Hier noch ein Demoprojekt zum testen: Download [VS 2010]

Da wäre es doch eigentlich cool wenn wir die Routen direct in unseren Controllern definieren könnten. Genau das können wir mit der Erweiterung AttributeRouting machen.

Installation über NuGet

Dank NuGet ist die Installation in wenigen Sekunden abgeschlossen und wir können unsere Actions mit Routing-Attributen dekorieren.

Die Attribute sind hierbei sehr einfach gestaltet und bieten uns alles was wir benötigen.

    public class DemoController : Controller
    {
        [GET("Ist/Das/Cool/Oder/Was")]
        public ActionResult Start()
        {
            return View();
        }
    }

Nun muss man nur noch die Attribut-basierten Routen registrieren:

    public static void RegisterRoutes(RouteCollection routes) {
        routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

        routes.MapAttributeRoutes(); //--- das wars!

        routes.MapRoute(
            "Default", // Route name
            "{controller}/{action}/{id}", // URL with parameters
            new { controller = "Home", action = "Start",
                id = UrlParameter.Optional } // Parameter defaults
        );
    }

Und fertig! Nun können wir die Seite starten und unsere Route testen:

Das Ergebnis

Die Routen die wir definieren können, beschränken sich nicht darauf, so können diese auch problemlos parametrisiert werden, inklusive Defaultparameter:

    public class DemoController : Controller
    {
        [GET("Artikel/{artikelid}/{version?}")]
        [RouteDefault("artikelid", "120")]
        public ActionResult Start(int artikelid, string version)
        {
            ViewBag.ArtikelId = artikelid;
            ViewBag.Version = version;

            return View();
        }
    }

Hier wird der Parameter artikelid mit einem Defaultwert ausgestattet und der zweite optional gemacht. Das Ergebnis kann sich sehen lasen:

Läuft!

Hier hört das Framework nicht auf, so könnt ihr auch Regular Expressions in die Routen integrieren und auch mehrere Routen an eine Action heften. Die Möglichkeiten sind grenzenlos

Für weitere Infos schaut einfach auf der Projekthomepage vorbei, es lohnt sich!