Letzte Änderung: 2005-04-08
Das ccWAP-Gateway ermöglicht es Mobilgeräten, auf Inhalte des lokalen Rechners, des Intranets oder dem Internet zuzugreifen. Das Gateway nimmt dabei Anfragen von WAP-fähigen Geräten entgegen und kontaktiert andere Server, um die angeforderten Inhalte wie WML-Dokumente und Graphiken zu beschaffen. Anschließend werden die Antworten gegebenenfalls in ein für das Mobilgerät geeignetes Format umgewandelt und schließlich an das Endgerät abgeliefert. Für sicherheitsrelevante Anwendungen (e-Commerce, m-Commerce) kann die Übertragung zur Sicherung verschlüsselt werden und eine Authentisierung des Servers mittels elektronischer Zertifikate erfolgen.
Aufgrund seines weitgehend Plattform unabhängigen Entwurfs ist das ccWAP-Gateway auf einer großen Anzahl von Systemen lauffähig, sofern diese netzwerkfähig sind. Es werden folgende Plattformen unterstützt:
libssl.so.0
und libcrypto.so.0)Das Gateway verwendet nur (sehr) grundlegende Systemfunktionen und ist nicht auf eventuell vorhandene Erweiterungen angewiesen. Auch die Anforderungen an den Rest des Systems sind recht moderat: Ca. 400 KByte Plattenplatz werden für das Programm selbst benötigt und ca. 2-5 MByte freier Hauptspeicher sind notwendig, um das Gateway zu betreiben. Der Prozessor des Serverrechners sollte aber relativ schnell sein, weil einige Komponenten recht rechenintensiv sein können, z.B. wenn WTLS zur Anwendung kommt. Da das Gateway eine reine Single-Thread-Anwendung ist, kann es die Vorteile, die sich aus dem Vorhandensein mehrerer Prozessoren ergeben, selbst nicht nutzen.
Das ccWAP-Gateway besteht aus den im folgenden beschriebenen Dateien und Verzeichnissen, die teilweise plattformabhängig sind und deshalb separat aufgeführt werden.
wapgwsrv/bin/ksh das Programm main aufruftmaingethostwapgwsrv.shWenn auf dem Zielsystem die Shell /bin/ksh nicht verfügbar oder deren
Benutzung nicht gewünscht ist, kann der Aufruf von wapgwsrv auch
folgendermaßen erfolgen:
/PFAD/ZU/main -a /PFAD/ZU/wapgwsrv ...
Es ist auch möglich und wenn die Lizenz dies zuläßt, die beiden Dateien
main und wapgwsrv in eine zu kombinieren und die resultierende
Datei wiederum wapgwsrv zu nennen, z.B. durch:
cat main wapgwsrv > wapgwsrv.new chmod +x wapgwsrv.new mv wapgwsrv.new wapgwsrv rm main
Alle weiteren Kommandozeilenoptionen sind im Abschnitt "Starten und Stoppen" beschrieben.
Es wird nicht empfohlen, das Gateway unter der User-ID von root zu
betreiben. Um dem Gateway gegebenenfalls dennoch das Binden an
privilegierte Ports, d.h. Ports kleiner als 1024, zu ermöglichen, kann
das Programm main (oder ein kombiniertes wapgwsrv) mit
suid-root-Rechten versehen werden. Dieses Recht wird ausschließlich
zum Binden von Sockets an Ports verwendet, alle anderen Aktivitäten
finden mit den normalen Rechten statt.
wapgwsrv.exegethost.exewapgwsrv.exe integriert)Die Versionen des Gateways für MS-Windows unterstützen z.Z. kein SSL/TLS. WTLS ist unabhängig davon immer verfügbar.
wapgwsrv.licwapgwsrv bzw. wapgwsrv.exe befindetwapgwsrv.cfgwml-docs/cgi-bin/log/ccwap.wucwml-docs/checkcom.wcc und kann in Endgeräte geladen
werden, die dies unterstützenccwap.keycheckcom.pemEs ist nicht möglich, das ccWAP-Gateway ohne eine gültige Lizenzdatei, die, wie auch die Programmdatei selbst, für das Programm lesbar sein muß, zu betreiben.
Das Verhalten des ccWAP-Gateways kann über eine Reihe von Parametern gesteuert werden. Die Parameter können entweder direkt auf der Kommandozeile angegeben werden, oder sie können in einer Konfigurationsdatei gespeichert und diese dann als Argument auf der Kommandozeile übergeben werden. Beide Arten der Übergabe können auch gleichzeitig bzw. gemischt angewendet werden.
Komponenten in Pfaden zu Dateien und Verzeichnissen, wie sie von
einigen Parametern erwartet werden, müssen immer, unabhängig von der
zugrundeliegenden Plattform, durch / getrennt werden. Die Verwendung
von \ kann zu unerwartetem Verhalten führen. Laufwerksbezeichnungen,
wie sie unter MS-Windows üblich sind (z.B. c:), müssen als erste
Komponente eines Pfades angegeben werden, z.B. /c:/programs/wapgwsrv.
Ein Parameter besteht aus einem Namen und einem Wert. Beide Teile
werden durch ein = voneinander getrennt. Die folgenden Parameter sind
verfügbar und werden hier mit Beispielwerten angegeben, die aber nicht
unbedingt den jeweiligen Vorgabewerten entsprechen:
host=localhost:9200Definiert die Basisadresse, unter der das Gateway angesprochen
werden soll. Der erste Teil (vor dem :) gibt den DNS-Namen oder
die IP-Adresse des Serverrechners an, während der zweite Teil die
zu verwendende Basisportnummer festlegt. Es werden insgesamt vier
UDP-Ports (BasisPort+0, BasisPort+1, BasisPort+2 und BasisPort+3)
belegt. Default: host=localhost:9200
bindhost=0.0.0.0Legt die IP-Adresse fest, an der das Gateway ausschließlich auf
eingehende UDP-Pakete warten soll. Bei fehlender oder leerer
Angabe oder bei Angabe von bindhost=0.0.0.0 werden alle
IP-Adressen zugelassen. Eine Angabe wie z.B. bindhost=127.0.0.1
würde dagegen nur lokale Verbindungen zulassen.
proxy=proxy:8080Falls das Gateway einen Proxy-Server benutzen soll, um
WML-Dokumente und Graphiken von anderen Servern zu holen, dann
kann dieser hier spezifiziert werden durch Angabe entweder des
DNS-Namens des Proxys oder dessen IP-Adresse und durch dessen
Portnummer. Eine eventuell vom Proxy-Server geforderte
Authentisierung kann durch das Voranstellen des Präfixes
userid:passord@ in der Adressangabe mit entsprechenden
Werten für userid und password befriedigt werden.
Es ist ebenfalls möglich, die Verbindung zu einem Proxy-Server
mittels SSL/TLS abzusichern. Bei der Angabe wird dies durch den
zusätzlichen Präfix https:// bewirkt, z.B.:
proxy=https://sslproxy:8081
allowuas=allowuas.lstDieser Parameter legt den Namen einer Datei fest, die die Präfixe
von User-Agent:-Headern enthält, denen ausschließlich Zugriff
auf das Gateway gewährt werden soll, alle anderen Geräte werden
mit der Fehlermeldung "502" (Bad Gateway) abgewiesen. Jede Zeile
der angegebenen Datei definiert den Präfix eines zulässigen
User-Agent:-Headers, wobei zwischen Groß- und Kleinschreibung
unterschieden wird, wobei aber Kommentare und Leerzeilen nicht als
solche erkannt werden. Wenn der Parameter allowuas= nicht
angegeben wird oder leer ist, oder wenn die Datei leer oder nicht
lesbar ist, dann wird keine Überprüfung von User-Agent:-Headern
vorgenommen und dadurch werden alle Endgeräte zugelassen.
wmldocs=~dat/wml-docs/Definiert den Pfad zu einem Verzeichnis mit WML-Dokumenten und Graphiken, die die lokale Homepage des Gateways bilden sollen. Diese Site ist unter der URL
http://local/
über das Gateway ansprechbar. Wenn die Angabe wmldocs= nicht
vorhanden oder leer ist, dann ist die WML-Homepage deaktiviert.
indexlist=index.wml i.wmlDefiniert eine durch Leerzeichen getrennte Liste von Dateien, die
als index im Verzeichnis von wmldocs= und dessen
Unterverzeichnissen benutzt werden sollen. Eine fehlende Angabe
entspricht dem Wert indexlist=index.wml i.wml, während eine
leere Angabe diese Funktion unterbindet.
cgidir=~dat/cgi-bin/Legt ein Verzeichnis fest, in dem nur CGI-Programme liegen und ausgeführt werden sollen. Dieses Verzeichnis erscheint unter der URL
http://local/cgi-bin/
im Gateway. Eine fehlende oder leere Angabe unterbindet diese Funktion.
error404=/error404.wmlDieser Parameter definiert die URL eines Dokuments, welches im
Falle eines Fehlers mit dem Statuscode "404" (Not Found) anstatt
der eingebauten Fehlerseite an das Endgerät ausgeliefert werden
soll. Dies geschieht nur, wenn ein solcher Fehler beim Zugriff auf
die lokale Homepage auftritt, also nur für URLs, die mit
http://local/ beginnen. Eine durch error404= spezifizierte URL
wird relativ zu http://local/ ausgewertet und darf auch auf ein
externes Dokument verweisen, welches auf die übliche Weise
beschafft wird.
Hinweise: Ein Fehlerdokument wird immer mit dem ursprünglichen Fehlercode, also "404", ausgeliefert! Wenn die interne Bearbeitung eines Fehlerdokuments zu einem anderen Statuscode als "200" (OK) führt, dann wird stattdessen die eingebaute Fehlerseite abgeliefert. Relative Links sollten in Fehlerdokumenten vermieden werden, da deren Kontext im Allgemeinen nicht mit dem des Fehlerdokuments übereinstimmt.
logdir=log/Definiert ein Verzeichnis, im dem Log-Dateien angelegt werden
sollen. Sie haben den Namen access_NNNN.log, wobei NNNN
für die Nummer des Ports steht, auf dem eingehende Zugriffe auf
das Gateway im Extended-Common-Logfile-Format (mit Referer: und
User-Agent:) aufgezeichnet werden. Es werden keine Logdaten
erzeugt, wenn die Angabe logdir= fehlt oder leer ist.
logopts=dnsDie Option logopts=dns aktiviert die Auflösung von
Client-IP-Adressen in DNS-Namen. Dieser Vorgang kann viel Zeit
in Anspruch nehmen und setzt einen (guten) Name-Server voraus.
Eine fehlende oder leere Angabe deaktiviert diese Funktion, d.h.
es werden nur die IP-Adressen von Clients aufgezeichnet.
udplogdir=udplogdir/Definiert ein Verzeichnis, in dem zu jeder Portnummer ein
Unterverzeichnis angelegt und dazu benutzt wird, um alle
eingehenden (.req) und ausgehenden (.res) UDP-Pakete auf den
entsprechenden Port in jeweils einer separaten Datei, benannt
mittels eines Timestamps in hexadezimaler Form, abzuspeichern.
Eine fehlende oder leere Angabe deaktiviert diese Funktion.
wtls.cert=ccwap.wucDefiniert eine durch Leerzeichen getrennte Liste von Dateien mit WTLS-Server-Zertifikaten, die vom Gateway verwenden werden sollen, um sich gegenüber WAP-Clients nach WTLS Klasse 2 zu authentisieren. Das erste Zertifikat einer solchen Kette definiert das eigentliche Server-Zertifikat, während die restlichen Zertifikate, wenn angegeben, die Kette zum Root-Zertifikat in der angegebenen Reihenfolge vervollständigen. Nicht alle Endgeräte unterstützen solche Ketten mit Zwischenzertifikaten.
Ein WTLS-Zertifikat kann entweder direkt als solches oder im DER-kodierten ASN.1-Format vorliegen. Jedes dieser binären Formate kann weiterhin entweder direkt oder in PEM-kodierter Form verwendet werden. Im letzten Fall können mehrere Zertifikate (einer Kette) in einer Datei gespeichert werden, außerdem ist es möglich, den privaten RSA-Schlüssel ebenfalls in die gleiche Datei zu packen.
Die angegebenen Zertifikate werden nur geladen, wenn ein privater
RSA-Schlüssel durch den Parameter wtls.key= spezifiziert wird
und dieser erfolgreich geladen werden kann.
wtls.key=ccwap.key passwordDefiniert eine Datei, die den privaten RSA-Schlüssel, der zum eigentlichen WTLS-Server-Zertifikat gehört, enthält. Optional kann zusätzlich noch, nach genau einem Leerzeichen, ein Base64-kodiertes Paßwort angegeben werden, mit dem der private RSA-Schlüssel verschlüsselt wurde.
Der private RSA-Schlüssel kann entweder in einem speziellen Format oder im DER-kodierten ASN.1-Format vorliegen. Beide Formate erlauben auch eine Verschlüsselung der Daten. Jedes dieser binären Formate kann weiterhin entweder direkt oder in PEM-kodierter Form verwendet werden. Im letzten Fall kann der RSA-Schlüssel in der gleichen Datei wie das zugehörige WTLS-Zertifikat enthalten sein, deren Name hier aber trotzdem angegeben werden muß. Es wird immer nur der erste private RSA-Schlüssel einer solchen Datei verwendet.
Es ist möglich, nur einen privaten RSA-Schlüssel ohne ein entsprechendes WTLS-Zertifikat anzugeben. In diesem Fall werden nur anonyme Verbindungen nach WTLS Klasse 1 durchgeführt. Dieser Fall tritt auch ein und es wird ein in das Gateway eingebauter privater Schlüssel verwendet, wenn überhaupt kein Schlüssel angegeben wird.
tls.cacerts=checkcom.pemDefiniert eine Datei mit ein oder mehreren PEM-kodierten SSL/TLS-CA-Zertifikaten, die zur Authentisierung von Servern benutzt werden sollen, wenn SSL/TLS zur Sicherung von Verbindungen mit anderen Web-Servern zum Einsatz kommt.
admin.host=localhost:8920Dieser Parameter, wenn angegeben, startet zusätzlich einen Administrationsserver auf dem definierten Port. Dieser Server ermöglicht die Verwaltung der WML-Dokumente und sonstigen Dateien, die die Homepage des Gateways darstellen. Unter der URL
http://localhost:8920/?frameset
kann eine zweigeteilte Startseite des Servers angesprochen werden, die auf der linken Seite die Struktur der Homepage als Baum darstellt und im rechten Teil die Anzeige und Bearbeitung der Dateien ermöglicht.
admin.binding=0.0.0.0Ermöglicht es den Socket, an dem der Administrationsserver auf
eingehende Verbindungen wartet, an eine bestimmte IP-Adresse zu
binden, wobei die Angabe 0.0.0.0 für alle Adressen steht.
Wenn admin.binding= leer ist oder nicht angegeben wird, wird
0.0.0.0 benutzt, d.h. der Socket wird an alle IP-Adressen
gebunden. Eine Angabe wie z.B. admin.binding=127.0.0.1 würde
dagegen nur lokale Verbindungen zulassen.
admin.realm=WML-DocsDefiniert den Text, der als Aufforderung zur Eingabe der User-ID und des Paßwortes beim Zugriff auf den Administrationsserver vom Web-Browser angezeigt werden soll. Wenn der Parameter leer ist oder nicht angegeben wird, dann erfolgt keine Authentisierung!
admin.authinfo=admin:adminDefiniert die User-ID und das Paßwort, getrennt durch einen
Doppelpunkt (:), welche zur Authentisierung beim Zugriff auf den
Administrationsserver benutzt werden sollen.
Eine Konfigurationsdatei ist eine gewöhnliche Textdatei, die mit einem
beliebigen Editor bearbeitet werden kann. Jede Zeile kann wahlweise mit
LF, CRLF oder CR terminiert werden und enthält jeweils einen Parameter.
Leerzeilen oder Zeilen, die mit # beginnen oder kein = enthalten,
werden vom Gateway ignoriert.
Eine Konfigurationsdatei, die üblicherweise den Namen wapgwsrv.cfg
hat und alle bekannten Parameter, wenn auch teilweise auskommentiert,
aufführt, könnte folgendermaßen aussehen:
# wapgwsrv.cfg host=localhost:9200 #bindhost=127.0.0.1 #proxy=localhost:8080 #allowuas=allowuas.lst wmldocs=~dat/wml-docs/ indexlist=index.wml i.wml cgidir=~dat/cgi-bin/ #error404=/error404.wml logdir=log/ #logopts=dns #udplogdir=udplog/ wtls.cert=ccwap.wuc wtls.key=ccwap.key tls.cacerts=checkcom.pem admin.host=localhost:8920 #admin.binding=127.0.0.1 admin.realm=WML-Docs admin.authinfo=admin:admin
Der allgemeine Aufruf zum Starten des ccWAP-Gateways geschieht wie folgt:
/PFAD/ZU/wapgwsrv [[-d] [-m5] --] { Parameter | @KonfigDatei }
LW:\PFAD\ZU\wapgwsrv.exe [[-m5] --] { Parameter | @KonfigDatei }
Das Gateway muß immer mit seinem vollständigen Programmnamen aufgerufen werden, sonst werden notwendige Programmteile möglicherweise nicht gefunden. Unter MS-Windows ist das normalerweise kein Problem, ein Doppelklick auf das Programmsymbol oder eine ähnliche Aktion ist ausreichend.
Das Gateway kann durch die üblichen Methoden, die das entsprechende Betriebssystem dafür bietet, beendet werden.
Die Option -d veranlaßt das Gateway dazu (nur unter UNIX/Linux), sich
als Dämon in den Hintergrund zu begeben und sich von seinem
Kontrollterminal zu lösen. Die Standardfehlerausgabe sollte in diesem
Fall auf /dev/null oder eine Datei umgeleitet werden, z.B. durch
Anhängen von 2>/dev/null an die Befehlszeile.
Die Option -m5 legt die Speicherbelegung fest und reserviert ca. 5 MByte, was für Serveranwendungen empfohlen wird. Andernfalls werden nur ca. 2 MByte reserviert.
Die Option -- kennzeichnet in Zweifelsfällen eindeutig den nachfolgenden Teil der Befehlszeilenargumente als anwendungsspezifisch.
Die nachfolgenden Argumente auf der Befehlszeile definieren jeweils
entweder einen Parameter (Parameter) oder eine Datei, die mehrere
Parameter enthält (KonfigDatei), siehe auch den Abschnitt
"Konfiguration". Bei mehrfacher Definition eines
Parameters gewinnt die jeweils zuletzt ausgeführte. Auf diese Weise
können Vorgaben aus einer Konfigurationsdatei auf der Befehlszeile
geändert werden. Bei den Angaben auf der Befehlszeile ist wie immer zu
beachten, daß die Angaben gegebenenfalls vor der Auswertung durch den
Befehlsinterpreter (Shell) zu schützen sind, z.B. durch die Verwendung
von "Parameter". Eine Konfigurationsdatei wird relativ zum
Installationsverzeichnis (mit dem symbolischen Namen ~dat/) des
Gateways gesucht, wenn deren Name nicht mit einem vollständigen Pfad
angegeben wird.
Für UNIX/Linux ist alternativ auch ein ksh-Skript namens wapgwsrv.sh
verfügbar, welches zum Starten und Stoppen des ccWAP-Gateways
eingesetzt werden kann:
wapgwsrv.sh start {Parameter}Startet das Gateway. Die Parameter für das Gateway werden der
Datei wapgwsrv.cfg entnommen. Weitere Parameter können auf der
Befehlszeile angegeben werden, z.B.
wapgwsrv.sh start "bindhost=192.168.1.50"
Das Skript prüft nicht, ob das Gateway danach wirklich läuft.
wapgwsrv.sh stopStoppt das Gateway, wenn es läuft, andernfalls wird eine entsprechende Meldung ausgegeben.
wapgwsrv.sh statusListet die Prozesse auf, die zum Gateway gehören. Wenn das Gateway nicht läuft, erfolgt keine Ausgabe.
Das ccWAP-Gateway unterstützt alle für WAP 1.x über UDP/IP spezifizierten Übertragungsprotokolle, diese sind:
Bei den verbindungsorientierten Protokollen (WSTP, WSTPS) unterstützt das Gateway auch SAR (Segmentation and Reassembly), aber z.Z. nur in Richtung zum WAP-Client, d.h. in Antworten. Die theoretische Maximalgröße solcher Transaktionen beträgt 358400 Byte (256*1400 Byte), praktisch sollte aber eine Größe von ca. 32 KByte nicht überschritten werden. Anfragen von WAP-Clients, die zwar SAR verwenden aber üblicherweise dennoch aus nur einem Paket bestehen, werden auf jeden Fall akzeptiert. Die maximale Paketgröße beträgt 1400 Byte.
Mit WTLS können Übertragungen gesichert, d.h. verschlüsselt und das Gateway mittels elektronischer Zertifikate authentisiert werden. Das ccWAP-Gateway unterstützt dazu WTLS Klasse 1 (Anonym ohne Server-Authentisierung) und WTLS Klasse 2 (mit Server-Authentisierung). Das Gateway läßt nur starke Kryptographie zu: RSA mit mindestens 1024 Bit für den Schlüsselaustausch, RC5 mit 128 Bit für die Blockverschlüsselung und SHA-1 für das Hashing und den MAC.
Um Dokumente von anderen Servern zu beschaffen, kann das ccWAP-Gateway einen Proxy-Server verwenden, falls erforderlich. Eine Authentisierung durch den Proxy-Server wird auch unterstützt.
Die Kommunikation mit anderen Servern, auch mit Proxy-Servern, kann mittels SSL/TLS gesichert, d.h. verschlüsselt und mittels elektronischer Zertifikate authentisiert werden. Das ccWAP-Gateway unterstützt SSL 3.0 und TLS 1.0, es läßt dabei aber nur starke Kryptographie zu. Zertifikate von anderen Servern werden z.Z. nicht überprüft.
Das ccWAP-Gateway leitet angeforderte Inhalte nur dann an einen
WAP-Client weiter, wenn dieser den entsprechenden Inhaltstyp
(MIME-Type) eines Dokuments im Accept:-Header der Anfrage
ausdrücklich freigegeben hat. Andernfalls erhält er eine Fehlermeldung
als Antwort.
Bei der Konversion von WML in die entsprechende binäre Form führt das ccWAP-Gateway diverse Optimierungen durch, die regen Gebrauch von der im Binärformat vorgesehenen Tabelle mit Zeichenketten machen. Dadurch wird eine gewisse zusätzliche Komprimierung erreicht, wenn mehrere Zeichenketten mit dem gleichen Präfix oder Suffix in einem WML-Deck vorkommen. Sämtliche Zeichen werden immer nach UTF-8 transkodiert, viele andere Kodierungen von WML-Quelltexten wie UTF-16, ISO-8859-*, Windows-125[0-8], KOI8-R, GB2312, BIG5, SHIFT_JIS, EUC-JP, KSC5601 und EUC-KR werden unterstützt.
Das ccWAP-Gateway bietet weiterhin die Möglichkeit, eine lokale Homepage zur Verfügung zu stellen. Ein Vorteil besteht in einer kürzeren Antwortzeit, da nicht erst ein anderer Web-Server kontaktiert werden muß, um eine Anfrage zu bearbeiten. Die WML-Homepage kann aus WML-Dokumenten, Graphiken, CGI-Programmen und anderen Komponenten bestehen. Wenn der Administrationsserver des ccWAP-Gateways gestartet wurde (siehe auch den Abschnitt "Konfiguration"), kann die WML-Homepage auch von anderen Rechnern aus mittels einer HTML-Oberfläche verwaltet werden. Der Server bietet außerdem die Möglichkeit, WML-Dokumente zu erzeugen, ohne tiefergehende Kenntnisse über WML vorauszusetzen.
Das ccWAP-Gateway besitzt eine weitere spezielle Funktion: Dateien der
WML-Homepage, die die Erweiterung .csv haben, werden automagisch
wie eine Datenbank behandelt. Dabei wird zunächst eine Suchmaske
angeboten, in der maximal zwei Suchbegriffe und die Felder, die
angezeigt und in denen gesucht werden soll, angegeben werden können.
Anschließend wird eine Suche durchgeführt und die Resultate
präsentiert, außerdem kann in der Trefferliste geblättert werden. Die
Anzeigetexte stehen in den Sprachen Deutsch und Englisch zur Verfügung
und werden abhängig vom Accept-Language:-Header der Anfrage
ausgewählt. Die .csv-Datei muß eine Kopfzeile mit Spaltennamen
besitzen, als Trennzeichen für die Spalten werden TAB
(Tabulatorzeichen), Komma (,) und Semikolon (;) unterstützt, aber
die Spalteninhalte dürfen das gewählte Trennzeichen nicht enthalten.
Als Zeilentrenner sind LF, CRLF und CR erlaubt. .csv-Dateien können
mit Hilfe des Administrationsservers, MS-Excel oder einem beliebigen
Texteditor erzeugt und bearbeitet werden.
Copyright (C) 2001-2005 CheckCom Inc. <info@checkcom.com>