Für einen Response-Filter, der den HTML-Code vor der Ausgabe noch einmal gezielt verändern kann, habe ich eine Lösung gesucht, die dafür notwendigen Informationen zentral abzulegen. Nahe liegend ist da natürlich die Verwendung der ASP.NET-eigenen web.config. In diesem Fall genügten mir aber die einfachen Key/Value-Paarungen des Abschnittes AppSettings nicht, da ich mindestens 4 Konfigurationswerte unterbringen wollte, und dies auch noch mehrfach:

• pageName
• findString
• newString
• type

Die Lösung liegt in der Verwendung der Klasse ConfigurationSection, mit der man relativ einfach eigene Konfigurationsabschnittstypen implementieren kann. In einer Klasse, die von ConfigurationSection ableitet, werden im Grunde die einzelnen Eigenschaften (Properties) definiert, die später in der web.config konfigurierbar sind und per Code über den ConfigurationManager abrufbar werden.

Trackbacks, also das Senden von Rückverweisen von einem Blog zu einem Artikel eines anderen, wurde vor ein paar Jahren von Six Apart für das Weblog-System Movable Type eingeführt und erfreut sich recht großer Beliebtheit, auch wenn der große Hype inzwischen wieder vorbei ist. Grund hierfür sind auch die Möglichkeiten, die sich Spammern bieten das Web auf diesem Wege mit nutzlosen Angeboten zu überschwemmen. In der Regel dauert es nur ein paar Tage und in einem neuen Blog tauchen die ersten Spam-Trackbacks auf, wenn der Webmaster dies nicht entsprechend zu verhindern weiß.

Fast alle Blog-System bieten inzwischen Mechanismen, um Trackback-Spam zu verhindern, allerdings basieren diese entweder auf externen Black-Listen wie Akismet oder sie bedürfen einer manuellen Nachsorge der meist als Kommentare eingestellten Trackbacks. Ad absurdum geführt wird das Ganze allerdings oftmals wieder durch den Einsatz von Pingbacks, der automatischen Trackback-Variante.

In diesem Artikel möchte ich eine Implementierung für ASP.NET und Javascript vorstellen, die ich für zerbit.de entwickelt habe und die meines Erachtens einen größmöglichen Schutz gegen Trackback-Spam bietet, da hier gleich mehrere Schutzmechanismen dafür sorgen, es den Spammern möglichst schwer zu machen. In den 12 Wochen, die das neue zerbit.de-Web online ist, hat es bislang noch keiner geschafft mir ein Viagra-Angebot oder eine Penis-Verlängerung unterzuschieben.

Ja, ich gebe es zu, ich mag News-Portale mit Voting-Funktionen wie digg, yigg oder Ähnliche. Im deutschsprachigen Raum, und in dieser Sprache schreibe ich nun mal, sieht es in diesem Bereich aber eher mau aus. Einen echten Ableger von digg wird es hierzulande wohl nicht geben und den anderen Diensten ist der Durchbruch noch nicht recht gelungen.

Ein wie ich finde interessanter Vertreter dieser Gattung ist wikio.de aus Luxemburg, die mit dem Portal unter anderem in Frankreich, Italien, Spanien und Großbritannien vertreten sind. In der letzten Zeit gab es über wikio immer wieder mal rege Diskussionen bis hin zu Vorwürfen des Content-Klaus, aber sehe das etwas gelassener, denn schließlich schreiben wir ja für die Leser "da draußen" und so ist es durchaus legitim, dass Content-Aggregatoren die Artikel verwerten und verbreiten, auch wenn echte Backlinks fehlen. Dafür habe ich meinen Content ja schließlich auch unter die Creative-Common-Lizenz gestellt und die wird eingehalten.

So sauber und stylish wie die wikio-Web-Seite sind auch die Voting-Buttons, die man auf der eigenen Seite einbinden kann. Nichts erinnert in das HTML- und CSS-Chaos der Yigg-Buttons, die ich inzwischen wieder von der Seite genommen habe, weil noch nicht mal der IE7 sie korrekt darstellen konnte. Der einzige Wermutstropfen bei der Implementierung der wikio-Buttons ist, dass wikio für den geneigten Webmaster lediglich etwas Code für Wordpress-, Blogger- und DotClear-Systeme bereitstellt. Wieder einmal Fehlanzeige in Sachen ASP.NET.

Da der PHP-Code des Wordpress-Plugins recht simpel ist, habe ich mich entschlossen Abhilfe zu schaffen und ein Web-Server-Control zu entwickeln, das ASP.NET 2.0-Webmaster leicht in Ihre Seiten einbinden können. Herausgekommen ist WikioButton. Den Download, inklusive Source-Code, findet ihr am Ende dieses Artikels

Das Image-Control aus System.Web.UI.WebControls kann hat, wie ich finde, einen kleinen Schönheitsfehler: es setzt beim Rendern der angegebenen ImageUrl das src-Attribut nicht so, wie man die URL angegeben hat. Aus

wird

Ein kleiner, aber feiner Unterschied. Grund für diese Auflösung des Ampersand, scheint der Aufruf der Funktion ResolveClientUrl in der Image-Control-Methode AddAttributesToRender zu sein.

Nun rendern die gängigen Browser das Bild zwar richtig und ansonsten kann man dem mit einer URLEncode-Methode begegnen, aber wer es korrekt haben mag, dem bleibt nichts anderes übrig, als ein eigenes Server-Control von Image abzuleiten und darin diese Methode zu überschreiben.

Webmaster, wie ich, die auf Ihrer Web-Site selbstentwickelte Tools zur Verfügung stellen, haben stets das gleiche Problem, wenn sie eine neue Version veröffentlichen wollen: neben der Erstellung des Downloads-Pakets, muss man auch noch den neuen Download über einen angepassten Link in die Seiten einbinden, sofern aus dem Dateinamen ersichtlich werden soll, um welche Version es sich handelt.

Mit etwas Code lässt sich das Deployment solcher Pakete aber auf den reinen FTP-Upload beschränken. Soll sich die Seite doch selbst den aktuellen Download heraussuchen...

In ASP.NET lässt sich das Ganze wunderbar in ein UserControl verpacken, sodaß man beim Entwickeln der Web-Seiten schnell einen neuen Download deklarieren kann, ohne erneut viel Code zu schreiben.