# Friday, September 28, 2007

Wir testen gerade, ob für uns Windows Live Custom Domains WLCD eine Alternative zum eigenen Mail-Server sein kann. Inzwischen hat sich der Outlook Connector entschlossen, nicht mehr mit dem Server reden zu wollen.

Vorher:

Outlook Connector - Server Status

Nachher:

WLCD - Outlook Connector - Server Error

Zur Zeit möchte er sich nicht anmelden. Gestern wollte er mir erklären, dass ich für den Dienst bezahlen soll. Ich denke, ich verwende die aktuelle Version: 12.0.4518.1063

Andere haben das Problem auch: Technical Support - Domain Live Account and OUTLOOK CONNECTOR. Es scheint nur den Connector und die Custom Domain Accounts zu betreffen. Das Web Interface geht.

Windows Live Help Community - Beta

Google hat es vorgemacht: Alles ist Beta, bis es eingestellt oder durch den Nachfolger abgelöst wird. Die Beta Hemmschwelle ist sehr niedrig geworden. Sogar die Seite, die gemeinschaftliche Hilfe anbietet ist Beta.

Das ganze holpert im Moment also noch. Unsere Haupt Domain werden wir definitiv nicht so schnell umziehen.

Wir wollen aber auch den mobilen Zugriff testen. Der ursprüngliche Auslöser für unsere Aktivitäten war der Abwesenheits-Assistent. Wieso sollen wir allen Spammern während einer Dienstreise unsere E-Mail-Adresse bestätigen? Besser als eine "Out of Office" Nachricht ist doch ein Push-Mail Dienst und eine entsprechende Reaktion des Empfängers.

Für eine Übergangsfrist werden wir das vielleicht so lösen, dass nicht der Abwesenheits-Assistent, sondern eine Weiterleitung auf das sekundäre Hotmail Konto vor einer Dienstreise aktiviert wird.

Nur welches Windows Mobile 6 Handy sollen wir testen?

Update: Der Outlook Connector verbindet sich jetzt wieder erfolgreich.

Friday, September 28, 2007 11:32:14 AM (W. Europe Daylight Time, UTC+02:00)  #
  Disclaimer  |  Comments [2]  | 
# Friday, September 21, 2007

 For those who aren’t familiar with Custom Domains, we provide free hosted e-mail for your domain.  Let’s say you own the domain name, “wingtiptoys.com.”   With Custom Domains, you get unlimited, free e-mail accounts at that domain.  You can open accounts for sales@wingtiptoys.com, owner@wingtiptoys.com, etc.  Oh wait, did we mention that it’s free?  This isn’t one of those “free during beta” trial offers.  This is free for life. 

Das konnte man letztes Jahr im Custom Domains Blog lesen. Inzwischen gibt schon Version 2.0.

E-Mail gibt es ja schon länger als kostenlose, webbasierte Lösung. Gmx, Hotmail, Gmail und viele andere. Die Postfächer sind dabei immer größer geworden. Als Google Gmail startete, waren die 1GB Platz schon sehr beachtlich. Unter 2GB braucht man inzwischen nicht mehr antreten.

Jetzt gehen die Großen einen Schritt weiter: Man kann jetzt seine eigene Domain in der Adresse verwenden. Also nicht user@hotmail.com, sondern in unserem Fall, user@cptec.org. Bei Google heißt es Google Apps und bei Microsoft wieder mal ein bisschen länger, aber dafür inzwischen mit Abkürzung Windows Live Custom Domains WLCD. Bei Microsoft kriegt man dabei 500 Benutzer mit je 5GB großen Postfächern. Umsonst!

Dazu verändert man ein paar DNS Einträge seiner Domain. Unter anderem zeigt der MX Record jetzt auf einen Hotmail Server. Die nötigen Einträge werden bei den Einstellungen schön angezeigt und auch überwacht. Windows Live überprüft die DNS Einstellung und schaltet die weiteren Funktionen frei, wenn alles passt.

Windows Live Custom Domains - Add Domain

Eine grüne Active Lampe! Microsoft ist mit meinen DNS Einträgen zufrieden. Jetzt kann man die einzelnen Postfächer anlegen. Wir werden die 500 Benutzer so schnell nicht brauchen.

Windows Live Custom Domains - Member Accounts

Als kleinen Bonus kann man noch eine Subdomain einrichten, die direkt auf das E-Mail Web Interface verweist. Dann braucht man sich nur mail.cptec.de merken.

Windows Live Custom Domains - Custom Addresses

Das ganze ist bis dahin derart unkompliziert, dass man die längste Zeit damit verbringt, zu warten, bis die DNS Einträge propagiert sind.

Was der Anwender jetzt zur Verfügung hat, ist das aktuelle mail.live.com Web Interface. Natürlich mit allen AJAX - Web 2.0 Wassern und Ladezeiten gewaschen. Viele sagen, dass es Gmail um Längen schlagen würde. Da sage ich nichts dazu. Für eine E-Mail zwischendurch taugen sie alle.

Interessant wird es dann sicher, wenn man sich noch für ein Windows Mobile Device in Version 6 entscheidet. Dann hat man auch noch Push E-Mail gratis dabei: Windows Live for Windows Mobile. Unser Reisender Geschäftsführer wird sich freuen.

Für den Desktop kann ich aber meiner Vorliebe für echte Desktop Applikationen treu bleiben. Ich kann weiter Outlook verwenden. Microsoft hat vor kurzem die finale Version des Microsoft Outlook Connector für Outlook 2003/2007 veröffentlicht. Dieser Connector synchronisiert die Windows Live Mail Informationen. Man erhält in Outlook ein weiteres Postfach, dessen Daten über ein neues Protokoll mit dem  Microsoft Server abgeglichen werden. Dieses neue Protokoll Delta Sync soll besonders effizient Informationen übertragen.

Outlook Connector - Postfach

Synchronisiert werden dabei die Mails selbst und Kontakte. Kalender-Synchronisation ist im Moment nur für zahlende Kunden möglich. Ich denke aber, das wird sich noch ändern.

Outlook Connector - Server Status

Bis dahin bin ich sehr zufrieden mit dieser interessanten Alternative zum eigenen Mail Server. Leider sind dann aber auch schnell ein paar gravierende Nachteile aufgefallen:

Keine externe E-Mail Weiterleitung. Der entsprechende Dialog lässt nur interne Adressen zu.

You can forward your mail to one other e-mail address that ends in hotmail.com, msn.com, live.com, or custom domains.

Wenn man voll auf Custom Domains setzt, ist die Einschränkung nicht so schlimm. Gerade in einer Test- über Übergangsphase ist aber eine externe Weiterleitung schon sehr praktisch.

Keine E-Mail Verteiler. Im Moment wird jede E-Mail Adresse einem echten Account zugeordnet. Ich möchte aber innerhalb einer Domain Aliase einrichten. Und diese Aliase möchte ich bereits auf der Administrator Ebene definieren können. Also ohne den Umweg über Accounts mit Passwörtern und anschließenden Regeln in den Profilen.

Ich denke, man wird auf diese Wünschen reagieren. Sonst macht es der Konkurrent. Es ist nur eine Frage der Zeit. Wenn diese Dienste jetzt noch nicht unseren internen Mail Server ersetzen können, dann sicher in naher Zukunft.

Wir werden mit unseren sekundären Adressen jetzt einige Zeit dieses System testen. Über weitere Erfahrungen werde ich hier berichten.

Friday, September 21, 2007 5:01:14 PM (W. Europe Daylight Time, UTC+02:00)  #
  Disclaimer  |  Comments [0]  | 
# Tuesday, September 18, 2007

FTP ist grausam. Das Protokoll ist so unglaublich anders und unhandlicher als neuere Internet Protokolle, dass es einen schaudert.

Beim Active Mode öffnet der Client einen zufälligen Port und übermittelt die Information an den Server, der darauf versucht sich mit diesem Port zu verbinden. Da wird kein NAT oder Firewall auf der Client Seite mitspielen.

Beim Passive Mode läuft das Spiel anders herum. Der Server öffnet fröhlich Ports, auf die sich der Client verbinden soll. Also ist es schwierig den Server hinter einer Firewall in Sicherheit zu bringen.

Passwörter werden im Klartext übertragen. Die Daten auch.

Eine schönes Gemotze ist da angesagt: FTP Must Die

FTP is an outdated, insecure, slow, unfriendly pig of a protocol. It's got no business being on the Internet in the 21st century.

Ich habe bereits die administrative Verantwortung für unseren FTP Server abgegeben. Für dieses Protokoll stehe ich nicht mehr ein.

Grundsätzlich steigen wir auf http basierte Übertragungen um. Das aktuelle Projekt mit WebDAV über https benötigt nur noch ein gültiges Zertifikat :).

Update: Wir haben ein Zertifikat. Sogar ein gültiges ;)

Tuesday, September 18, 2007 11:26:33 AM (W. Europe Daylight Time, UTC+02:00)  #
  Disclaimer  |  Comments [0]  | 
# Monday, September 17, 2007

Ich bin ein JavaScript Anfänger. Vor dem aktuellen Projekt gab es nur ein bisschen Html mit JavaScript als DOM Manipulator dazwischen. Echte Profis werden sicher nichts lernen können.

Ein Problem bei JavaScript ist, dass das Web voller kleiner Snippets ist, die tolle Sachen im Browser anstellen. Man findet nicht sehr viel zu den Konzepten der Sprache. JavaScript ist eine gute Ergänzung zu Html, weil es ebenso tolerant ist. Kein Compiler achtet auf die Typisierung, implizite Typkonvertierung überall.

Natürlich kann eine Sprache, die sehr schnell zu "es funktioniert" führt, auch zu unsauberem Code verleiten. Wer die Sprache konzeptionell missbraucht gerät in Gefahr, über unangenehme Randbedingungen zu stolpern, die nicht mehr funktionieren.

Ein Beispiel sind zwei sehr häufig benötigte Konstruktionen, das Array und die Hashtable.

JavaScript verfügt über ein Array Objekt das sich wie erwartet verhält. Nur ein bisschen dynamischer. So passt sich die Länge zum Beispiel automatisch an:

var testArray = new Array();
testArray[0] = "Test0";
testArray[99] = "Test99";
// Der Test liefert true:
if (testArray.length = 100)
    result = "Array Länge: 100";

Für die Hashtable gibt es aber kein entsprechendes Objekt. Aber dafür gibt es eine sehr interessante Eigenschaft von JavaScript. Alle Eigenschaften (und Methoden) eines Objekt sind, wie für eine dynamische Sprache zu erwarten, dynamisch. Können also zu jeder Zeit verändert werden. Der JavaScript Interpreter verwaltet diese Eigenschaften offensichtlich in einer Hashtable. Diese Objekt-Hashtable steht auch dem Entwickler zur Verfügung. Eine Einschränkung hat diese Objekt-Hashtable aber: Nachdem Objekt Eigenschaften benannt sind, können die Keys der Hashtable auch entsprechend nur Namen oder allgemeiner Zeichenketten sein. Genauso können natürlich als Hash Key keine Schlüsselworte des Core Objects verwendet werden (z. B: "toString").

var hashObject = new Object();
// Werte zuweisen
hashObject["key1"] = "Wert1";
hashObject["key2"] = 1234;
// Werte auslesen über Hashtable
var test = hashObject["key1"];
// Werte auslesen über Eigenschaft
var test2 = hashObject.key2
// Test, ob ein Wert vorhanden ist
if (hashObject.hasOwnProperty("key1"))
    result = "vorhanden";

Mit der for...in und der for each...in Schleife kann man ganz einfach über die Schlüsselworte oder Schlüsselwerte der Objekt-Hashtable iterieren.

for (key in hashObject)
    allKeys += key;

Bis dahin kann man das alles ganz einfach aus der JavaScript Referenz lernen. Leider liest man nicht immer die komplette Dokumentation, bevor man sich in einer neuen Sprache austobt. Google liefert zu jeder Frage sehr viele kleine Lösungen. Leider kann Google die Qualität des Codes nicht beurteilen. Schlechter Code prominent platziert führt zu neuen Programmierern mit schlechtem Stil.

Der häufigste Fehler in diesem Zusammenhang ist, dass man das Array als Hashtable verwendet:

var newHashObject = new Array();

JavaScript ist eine objektbasiert Skriptsprache und damit ist auch das Array ein Objekt. Damit funktioniert zunächst alles wie bisher. Trotzdem sollte man das so nicht machen.

Erstens leidet die Lesbarkeit. Wenn man Array definiert, erwartet man ein Array. Wenn der Zugriff dann über Variablen erfolgt, ahnt man vielleicht nicht, dass gar keine Array Indizes, sondern Hashtable Keys verwandt werden:

var result = hashObject[item];

Ist item ein Integer, mit dem auf das Array zugegriffen wird? Oder ist item ein String, mit dem auf eine Objekt Eigenschaft zugegriffen wird?

Auch der Entwickler kann sich selbst verwirren. Die Länge des Arrays wird über length abgefragt. Missbraucht man das Array als Objekt-Hashtable liefert length natürlich den falschen Wert (0).

Richtig ärgerlich wird es aber dann bei dem in Operator, der unter anderem in den Schleifen zum Einsatz kommt. Eigenschaften der vordefinierten Core Objekte werden dabei nicht ausgegeben. Nur per Code definierte Eigenschaften werden berücksichtigt, dafür aber über die ganze Prototypen Hierarchie (JavaScripts quasi Vererbung).

Ich wollte zum Beispiel das Array per Prototype um eine contains Methode erweitern.

Array.prototype.contains = function(element) 
{
    for (var i = 0; i < this.length; i++) 
    {
        if (this[i] == element) 
        {
            return true;
        }
    }
    return false;
};

Diese Erweiterung funktioniert toll. Nur jedes Array hat jetzt ein weiteres Hash Element mit dem Key contains. Bei einer Schleife wird dieses Element mit ausgegeben. Und zwar bei jeder Objekt-Hashtable, die fälschlicherweise mit "new Array" statt "new Object()" definiert wurde.

Merke: Kein Array verwenden, wenn eigentlich nur ein Object gebraucht wird!

Monday, September 17, 2007 1:21:25 PM (W. Europe Daylight Time, UTC+02:00)  #
  Disclaimer  |  Comments [0]  | 
# Friday, September 14, 2007

Die Strichmännchen leben weiter gefährlich!

Wie ich inzwischen erfahren habe, ist die englische Übersetzung von Strichmännchen nicht notwendig Stickmann, auch Stick Figure ist möglich. Mit diesem neuen Wissen konnte ich weitere Abenteuer der kleinen Kerle aufspüren: Stick Figures in Peril auf Flickr.

Zum Zeitpunkt dieses Eintrags waren dort bereits unglaubliche 10.308 Bilder abgelegt! Da müssen wir mit unseren paar Varianten richtig bescheiden bleiben. Alleine auf diesem Bild finden sich unglaubliche Gefahren:

stick_figure_in_peril

Und als Abschluss diesen gefährlichen Hechtsprung in Untiefen. "Es hat sich bereits ein Krater gebildet, von all den Strichmännchen die an der gleichen Stelle aufprallen."

submerged_rocks

Blah | TD
Friday, September 14, 2007 8:48:12 AM (W. Europe Daylight Time, UTC+02:00)  #
  Disclaimer  |  Comments [0]  | 
# Tuesday, September 11, 2007

Ich radle fast täglich am Münchner Olympiastadium vorbei. Das Stadium wurde anlässlich der Olympischen Sommerspiele 1972 erbaut. Was man vielleicht nicht weiß, dass mit dieser Olympiade die jedem bekannte Zeichensprache der modernen Piktogramme entstand:

Fussball piktogramm

Otl Aicher hat alle vertretenen Sportarten und das komplette Leitsystem dieser Olympiade entworfen. Bei Erco liegen die Rechte und wenn die Webseite funktionieren würde, könnte man sich auch über den heutigen Stand der Bildersammlung informieren.

Im Rahmen der Gestaltungsarbeit für das visuelle Erscheinungsbild der XX. Olympischen Spiele in München im Jahre 1972 entwickelte der Grafiker Otl Aicher, einer der Mitbegründer der Ulmer "hochschule für gestaltung", erstmals eine systematisch aufgebaute Zeichensprache. Ein umfassendes und komplexes Repertoire von Bildzeichen diente dazu, ein internationales und vielsprachiges Publikum zu den diversen Veranstaltungsorten zu leiten und mit relevanten Informationen zu versorgen.

Am weitesten hat es das in den damaligen Piktogrammen verwandte, Strichmännchen gebracht. 1972 durfte es sich noch bei diversen sportlichen Aktivitäten stärken. Heute begegnet es uns eher in vielen gefährlichen Situationen. Manchmal zeigt es uns auch, wie wir uns richtig verhalten sollen.

Im Rahmen der Technischen Dokumentation schicken wir von CPTec das Strichmännchen regelmäßig von einem gefährlichen Abenteuer zum nächsten:

falling hazard fork lift hazard bruising hazard

Die Erholungsphasen sind kurz und dringend benötigt:

Shower mandatory

Inzwischen gibt es sogar eine Sammlung seiner wichtigsten Einsätze!

Das deutsche Strichmännchen gibt es auch als englischen Stickman, dem es aber auch nicht besser ergeht. Überall lauert die Gefahr. Jetzt auch als reflektierende Aufkleber:

 stickman_in_peril

stickman_in_officeland

 

Gefunden über Rick Strahl - Stickman in Peril :)
Blah | TD
Tuesday, September 11, 2007 1:46:52 PM (W. Europe Daylight Time, UTC+02:00)  #
  Disclaimer  |  Comments [0]  | 
# Thursday, September 06, 2007

Ein Spruch, der sich immer wieder bewahrheitet:

Daten leben länger als die Programme, die die Daten erzeugen

Mein Fall ist nicht so drastisch, das Programm, das die Daten erzeugen kann, lebt noch. Eine Visual Foxpro Applikation hat die Daten erzeugt, eine .NET Applikation soll jetzt damit weiter arbeiten.

Über den Visual FoxPro OLE DB Provider kann man direkt auf die VFP Daten zugreifen. Die restliche Logik kann in der inzwischen eher vertrauten Visual Studio Umgebung programmiert werden:

            string connectionString = "Provider=vfpoledb.1;Data Source=c:\\data.dbc";
            OleDbConnection connection = new OleDbConnection(connectionString);
            connection.Open();
            string selectCmd = "SELECT * FROM table";
            OleDbCommand command = new OleDbCommand(selectCmd, connection);
            OleDbDataReader reader = command.ExecuteReader();
            while (reader.Read())
            {
                // Daten verarbeiten
            }
            reader.Close();
            connection.Close();

Wenn die VFP Anwendung bereits eine saubere Business Schicht implementiert hätte, wäre es besser, auf dieser Ebene die Informationen auszutauschen und nicht auf die rohen Daten zuzugreifen. Ist aber hier nicht der Fall.

Wenn kein Visual Foxpro installiert ist, sollte obiger Download genügen um den OLE DB Provider zu installieren. Unter Vista x64 klappt die Installation zwar problemlos. Nur der Treiber ist eine reine 32Bit Anwendung und Visual Studio erzeugt normalerweise Code für Any CPU. Dieser Code läuft auf einem 64Bit OS, dann entsprechend als 64Bit Anwendung. Der Versuch auf vfpoledb zuzugreifen scheitert:

The 'vfpoledb.1' provider is not registered on the local machine.

Die einzige Lösung, die ich kenne, ist die komplette Solution auf Platform target x86 zu schalten:

VS Build Configuration Manager

Jetzt funktioniert der Zugriff auf die VFP Daten einwandfrei.

Wieder holt einen die Vergangenheit ein und das tolle neue System kann nicht so agieren wie es möchte. Aber das ist der Preis, wenn man nicht alles immer neu erfinden will.

Thursday, September 06, 2007 2:16:56 PM (W. Europe Daylight Time, UTC+02:00)  #
  Disclaimer  |  Comments [0]  | 
# Wednesday, September 05, 2007

Gehört hatte ich schon öfters von dem Foxit Reader: Einem kleinen, schnellen Ersatz für den Adobe Acrobat Reader. Aber in einigen Applikation verwende ich den Acrobat Reader als Komponente zur PDF Darstellung. Das heißt der Acrobat Reader ist ohnehin notwendig auf meinem Rechner installiert. Auch selbst erzeugte PDFs sollen in erster Linie im Acrobat Reader funktionieren. Da hilft Foxit nicht viel.

Und so schlimm empfand ich das Original von Adobe dann auch nicht, dass der mentale Aufwand für einen weiteren PDF Reader gerechtfertigt war. Jetzt beschäftige ich mich bei einem aktuellen Projekt intensiver mit der Adobe Acrobat Linie und der zugehörigen SDK. Auf einmal benötige ich einen zusätzlichen PDF Reader. Wieso kann man nicht mit den Adobe Tools alleine die Aufgabe lösen?

Das Problem liegt in der Architektur von Adobe Acrobat Professional und dem Adobe Reader. Es ist vielleicht schon aufgefallen, dass wenn man einmal ein PDF mit einem der beiden geöffnet hat, das andere Tool nicht mehr funktioniert. War der Reader offen, geht kein Acrobat Professional mehr und umgekehrt. Klemmt irgendwie eine (scheinbare) Instanz der Tools, geht gar nichts mehr. Auch wenn mehrere Acrobat Fenster offen sind und eines einen modalen Dialog darstellt, geht im anderen Fenster nichts mehr.

Das fällt vielleicht normalerweise nicht auf, aber wer die SDK Dokumentation noch nicht auswendig kann, wird sich wundern: Man öffnet den JavaScript Editor in Acrobat und möchte seinen Code bearbeiten. Natürlich ließt man parallel die API Dokumentation. Nur was macht der arme Entwickler mit einer PDF Dokumentation, während er in einem PDF arbeitet? Gar nichts, zumindest nicht mit Adobe-Mitteln. Erst wenn man den Editor beendet, erwacht Acrobat wieder und die Dokumentation steht zur Verfügung. Nur wer vorher die richtige Seite in der SDK geöffnet hat, kann Code und Erklärung gleichzeitig studieren.

Die einfachste Lösung war für mich, den Foxit Reader für die Adobe Acrobat SDK zu verwenden. Ironie des großen Softwarehauses.

  Foxit Reader
Wednesday, September 05, 2007 1:18:51 PM (W. Europe Daylight Time, UTC+02:00)  #
  Disclaimer  |  Comments [0]  | 
# Monday, August 27, 2007

JavaScript ist eine dynamische Sprache. Der Code wird nicht kompiliert sondern zur Laufzeit interpretiert. Dadurch wird unter anderem die eval Funktion ermöglicht, die innerhalb eines Skripts einfach JavaScript Code als Parameter entgegen nimmt und ausführt.

Im .NET Framework gibt (gab) es eine Variante von JavaScript: JScript. Damit sollte es möglich sein, aus einem C# Programm heraus diese JScript Funktion aufzurufen. Und tatsächlich ist dies sogar sehr einfach möglich. Man muss sich nur darüber im klaren sein, dass das nur eine Übergangslösung ist.

Aus MSDN VsaEngine:

Use of this type is not recommended because it is being deprecated in Visual Studio 2005; there will be no replacement for this feature. Please see the ICodeCompiler documentation for additional help.

In .NET 3.0 ist es damit bereits Schluss. In Zukunft wird wohl eher die Dynamic Language Runtime DLR dafür verwendet.

Das hilft mir aber jetzt nichts. Die einfachste Lösung habe ich in einem Kommentar zu einem Blog-Eintrag von Rick Strahl gefunden: Evaluating JavaScript code from C#

Man erzeugt sich eine JScript Dll:

  1. Mit Notepad eine Datei mit folgendem Text erzeugen:
    class EvalClass { function Evaluate(expression: String) { return eval(expression, "unsafe"); } }
  2. Die Datei als C:\MyEval.js speichern.
  3. Einen VS2005 Command Prompt (Start, Programs, VS2005, VS2005 Tools) öffnen.
  4. Auf C:\ wechseln.
  5. Folgenden Befehl absetzen:
    jsc /t:library C:\MyEval.js
  6. Es wird eine neue Datei mit dem Namen MyEval.dll erzeugt.
  7. MyEval.dll in das gewünschte C# Projekt kopieren und referenzieren. Zusätzlich muss noch Microsoft.Jscript.dll referenziert werden.
  8. So kann jetzt die JavaScript Eval Funktion aufgerufen werden:
    EvalClass evalClass = new EvalClass();
    object result = evalClass.Evaluate("2+3");

 

Das  funktioniert wirklich so einfach und gut. Was ich später noch ändern musste, war der zusätzlich String Parameter "unsafe" bei der JScript eval Funktion. Ohne diesen Parameter gibt es eine Security Exception, wenn der übergebene JavaScript Code eine neue Funktion deklariert.

Monday, August 27, 2007 10:57:25 PM (W. Europe Daylight Time, UTC+02:00)  #
  Disclaimer  |  Comments [0]  | 
# Wednesday, August 22, 2007

Früher waren Webseiten in HTML codiert und animierte Gifs haben für ein bisschen Bewegung gesorgt. Ein paar besonders tolle Entwickler konnten per JavaScript Bilder austauschen, wenn sich der Mauszeiger darüber bewegt hat. Daten wurden in ein Formular eingegeben und per Submit an den Server übertragen. Damals war alles aus heutiger Sicht überschaubar.

Das Web 2.0 hat uns AJAX und damit den nach Hause telefonierenden, per JavaScript programmierten Browser gebracht. Damit erstellte Webanwendungen stehen in ihrer Funktionalität in manchen Bereichen Desktop Applikationen in nicht mehr nach. Aber ohne JavaScript geht auf diesen Seiten gar nichts mehr.

Gleichzeitig können fast alle neueren Browser-Schwachstellen mit deaktiviertem JavaScript umgangen werden. Also ohne JavaScript ist man sicherer, aber es funktioniert nicht mehr sehr viel. Was tun?

noscript_logo

NoScript ist ein Firefox Add-on, dass es ermöglicht JavaScript in Abhängigkeit der besuchten Webseite an- und abzuschalten. Bei der ersten Installation ist JavaScript auf allen Webseiten verboten. Besucht man vertrauenswürdige Seite, die JavaScript benötigt, kann man die Ausführung von JavaScript erlauben und NoScript merkt sich diese Einstellung. Im Laufe der Zeit erstellt man sich damit eine eigene Whitelist der erlaubten Seiten und bemerkt NoScript dann eigentlich nicht mehr.

NoScript ermöglicht es auch, JavaScript generell wieder zu aktivieren. Dieser Versuchung sollte man aber widerstehen.

Inzwischen sind noch ein paar weitere Funktionen für ein sichereres Browsen in NoScript implementiert worden. Es können Java, Flash und andere Plug-ins von nicht vertrauenswürdigen Seiten blockiert werden. Auch gegen Cross-Site Scripting (XSS) Angriffe versucht NoScript zu schützen.

Ich selbst verwende seit einiger Zeit NoScript und würde nicht mehr ohne diese zusätzliche Sicherheit surfen. Diese Woche hat hier bei CPTec ein Kollege einen Virus in Quarantäne geschickt. In den eher dubiosen Ecken des WWW hat unser Virenscanner in seinem HTTP Traffic den Bösewicht entdeckt. Noch mal Glück gehabt. Aber selbst bei täglichen Updates der Patterns ist die Scan Engine potentiell immer zu langsam für den jeweils neuesten Schädling. Jetzt wird bei uns NoScript zur Pflichtinstallation.

Wednesday, August 22, 2007 10:26:45 AM (W. Europe Daylight Time, UTC+02:00)  #
  Disclaimer  |  Comments [0]  |