Der WebShare Webserver („webshare.woa“) ist ein Java-Programm, welches auf einem Server mit Internetanbindung läuft, und kann auf demselben Host wie der WebShare File Server installiert werden. In diesem Fall spricht man von einer „Ein-Server-Lösung“. In Bezug auf die Datensicherheit sollte der WebShare Webserver jedoch auf einer separaten Maschine, als zweistufiger Serveraufbau, installiert werden.
Im Idealfall laufen auf dem WebShare Webserver keinen weiteren Anwendungen oder Dienste. Der Vorteil dieser eigenständigen Lösung ist, dass alle Ports und Dienste, die nicht von WebShare benötigt werden, abgeschaltet werden können (z. B. durch Soft- oder Hardware Firewalls).
Da keine Dateien auf dem WebShare Webserver gespeichert oder temporär abgelegt werden, ist ein Höchstmaß an Datensicherheit auf dem WebShare File Server gewährleistet. Der WebShare Webserver benutzt für alle Webclients einen TCP/IP Port (Standard: 2009).
Während der WebShare Installation wird die gepackte Datei „websharewoa.tar“ in das Verzeichnis „HELIOSDIR/etc/webshare“ installiert. Das Kommando „start-helios“ entpackt die Datei dann in das Verzeichnis „HELIOSDIR/var/run“ in das Paket „webshare.woa“.
WebShare als Produkt beinhaltet zwei Serverkomponenten: den WebShare File Server, der auf einem bestehenden HELIOS Server mit dessen Maschinen-ID (mach ID) lizensiert wird sowie den WebShare Webserver, der auf einem separaten Server installiert werden kann. Der WebShare Webserver benötigt als Komponente des WebShare Serverprodukts keinen separaten WebShare Aktivierungsschlüssel.
Sie müssen während der Installation die HELIOS Software-Lizenzbestimmungen akzeptieren. Diese finden Sie auf unserer Produkt-CD.
Im Ordner „HELIOSDIR/var/run/webshare.woa/Contents/Resources/“ befinden sich im Paket „Contents/Resources“ folgende Dateien:
HTML-Abrechnungskomponente
HTML-Seitenkomponente für detaillierte Abrechnungsinformationen
HTML-Seitenkomponente für die Verwaltung von Präferenzen
HTML-Seitenkomponente für die Verwaltung von Sharepoints
HTML-Seitenkomponente für die Verwaltung von Benutzern
HTML-Seitenkomponente für die Hauptverwaltung
HTML-Komponente zum Durchsuchen von Dateien und Verzeichnissen
HTML-Komponente für Voransichten von Dokumenten und Bildern
HTML-Vorgabekomponente für vergessene Kennwörter
HTML-Seitenkomponente für die Abmeldung vom Server
HTML-Seitenkomponente für die Anmeldung am Server
Begrüßungs- und Serverauswahl-Seitenkomponente
HTML-Komponente für detaillierte Proofs
HTML-Vorgabekomponente zum Registrieren neuer Benutzer
HTML-Seitenkomponente zum Erstellen von Sharepointlisten
HTML-Komponente zum Hochladen von Dateien
HTML-Seitenkomponente für Benutzereinstellungen
HTML-Komponente für den Branding Editor
Systeminterne Komponente
Systeminterne Komponente
Systeminterne Komponente
Systeminterne Komponente
Vorlage für Anmerkungsdialog
Systeminterne Komponente
Vorlage für Seite „Datei öffnen“
HTML-Komponente für die Menüleiste
Systeminterne Komponente
Systeminterne Komponente
Systeminterne Komponente
Systeminterne Komponente
Systeminterne Komponente
HTML-Seitenkomponente für die Serverstatistik
Systeminterne Komponente
Jedes einzelne „*.wo“-Verzeichnis enthält die Dateien „*.html“, „*.wod“ und „*.woo“.
Das Skript „sbin/start-websharewoa“ startet den WebShare Webserver. Normalerweise wird dieser jedoch mit dem Kommando „srvutil start websharewoa“ während des Aufrufs „start-helios“ gestartet. Für den Fall, dass es beim Start des Dienstes zu Problemen kommen sollte, kann dieser auch manuell aufgerufen werden. Etwaige Fehlermeldungen werden dann im Terminalfenster angezeigt:
# cd /usr/local/helios # sbin/start-websharewoa
Ergänzende Meldungen werden in die WebObjects-Logdateien geschrieben. Diese befinden sich im Verzeichnis „HELIOSDIR/var/adm/“ und haben den Dateinamen „websharewoa.log“. Sie bekommen „.0“ (gestern), bis „.6“ (vor sieben Tagen) an den Dateinamen angehängt. Alle internen WebObjects-Meldungen werden in die Datei „websharewoa.log“, die von HELIOS erzeugten WebShare Webserver-Meldungen in die Systemmeldungen geschrieben.
WebShare unterstützt Menüs, Meldungen, Administration, Dialogfelder usw. in mehreren Sprachen, die vom Benutzer ausgewählt werden können. Dieses Kapitel beschreibt, wie Sie eine bestehende Sprachversion anpassen können.
Dieser Abschnitt behandelt die benutzerdefinierte Anpassung des Pakets „webshare.woa“. Wollen Sie keine Anpassung vornehmen, so können Sie diesen Abschnitt überspringen
Um persönliche Anpassungen auf dem WebShare Webserver vorzunehmen, kopieren Sie bitte das Paket „webshare.woa“ von „HELIOSDIR/var/run“ nach „HELIOSDIR/var/webshare“.
Die Anpassungen sollen ausschließlich in „var/webshare“ vorgenommen werden, da WebShare nach jedem Start im Verzeichnis „var/webshare“ nach „webshare.woa“ sucht. Nur wenn „webshare.woa“ dort nicht gefunden werden kann, wird die Kopie aus „var/run“ verwendet. Die Idee dabei ist, dass z. B. bei einer Softwareaktualisierung „webshare.woa“ immer in „var/run“ ersetzt wird. Angepasste Dateien in „var/webshare“ werden nicht überschrieben.
Für neue WebShare Produktversionen oder Updates, die neue Funktionen einführen, müssen Sie jedoch „webshare.woa“ wieder von „var/run“ nach „var/webshare“ kopieren, was das alte Paket überschreibt, und dann die Anpassungen erneut vornehmen. Andernfallsbesteht die Gefahr, dass das Paket nicht mehr mit dem WebShare File Server kompatibel ist oder neue Funktionen nicht zur Verfügung stehen.
Mac OS X:
Verwenden Sie die Option Paketinhalt zeigen
um den Paketinhalt sichtbar zu
machen. Verfahren Sie mit den „.wo“-Dateien im Ordner „Contents > Resources“ genauso,
um die Dateien „.wod“, „.html“ und „.woo“ sichtbar zu machen.
Benutzen Sie beim Anpassen aller „*.html“-Dateien UTF-8-Zeichen. Sie können beispielsweise das Programm „WebObjects Builder“, welches auch das korrekte Layout anzeigt, verwenden. Sie können dafür aber auch jeden anderen HTML Editor benutzen. Damit Änderungen an den „*.html“-Dateien wirksam werden, muss der Dienst „websharewoa“ gestoppt und wieder neu gestartet werden.
Benutzen Sie beim Anpassen aller „*.wod“-Dateien UTF-8-Zeichen. Sie können dies mit jedem anderen UTF-8-kompatiblen Texteditor tun. Damit Änderungen an den „*.wod“-Dateien wirksam werden muss der Dienst „websharewoa“ gestoppt und wieder neu gestartet werden.
Eigene Aktionsskripte lassen sich anpassen, indem Sie den gewünschten Titel des Skripts
über den Ausdruck #Title=<UTF-8-Name>
innerhalb der ersten 5 Zeilen in das
Skript kopieren. Gleichermaßen können Sie in jedem Skript auch den Kommentar
#NameField=
bearbeiten. Wenn Sie nach der nächsten Anmeldung aus dem WebShare
Menüleisteneintrag „Aktionen“ das Skript ausgewählt haben, erscheint ein Textfeld, über
das sich dem Skript Werte übergeben lassen.
Detaillierte Informationen darüber, wie benutzerdefinierte oder Aktionsskripte angelegt oder verändert werden finden Sie in Kapitel 7.4 „WebShare Skripte“.
WebShare unterstützt Englisch, Deutsch, Französisch, Spanisch und Japanisch. Unterstützung für zusätzliche Sprachen wird ausschließlich von HELIOS bereitgestellt. Haben Sie den Wunsch, Unterstützung für weitere Sprachen zu erhalten, dann fragen Sie bitte Ihren HELIOS Partner.
Sollen Anpassungen auch für lokalisierten Ressourcen gelten, müssen die Ordner „<Sprache>.lproj“ auch angepasst werden.
Dieser Abschnitt umreißt kurz die Konfiguration Ihrer SSL Installation. Die HELIOS WebShare SSL Unterstützung wird durch standardmäßiges Java SSL realisiert. In dieser Dokumentation beschreiben wir die Benutzung der Standard JDK 1.5 Sicherheitswerkzeuge zur Einrichtung von SSL.
SSL (Secure Sockets Layer) SSL? ist ein Protokoll, welches von der Netscape Communications Corporation für die verschlüsselte Übertragung von Daten über das Internet entwickelt wurde. SSL liegt unter Anwendungsprotokollen wie HTTP, SMTP, FTP, Telnet, Gopher und NNTP, und setzt auf dem Verbindungsprotokoll TCP/IP auf. Es wird via HTTPS benutzt. SSL benutzt zur Verschlüsselung der via SSL zu übertragenden Daten einen geheimen Schlüssel. Die meisten aktuellen Browser unterstützen SSL und viele Webseiten verwenden dieses Protokoll beim Transfer persönlicher oder geheimer Daten, z. B. Kreditkartennummern. Die Konvention besagt, dass die URLs von Webseiten, auf denen die Verbindung per SSL aufgebaut wird, mit https: statt mit http: beginnen.
Ein Server mit SSL-Aktivierung verwendet gewöhnlich eine gesicherte Datei oder
Datenbank, eine so genannte Keystore-Datei zur Speicherung von Schlüsseln und
Zertifikaten. Diese Sicherheitszertifikate dienen dem Client als Beweis, dass
der Server tatsächlich zu einer bestimmten Domain gehört. Falls Ihr Server allein
eine Domain darstellt, benötigen Sie lediglich einen Schlüssel sowie ein Zertifikat
im Keystore. Schlüssel werden im Keystore als Alias gespeichert. Jedes Alias
entspricht einem Domainnamen, z. B.:
webshare.meinserver.com.
Zertifikate sollen ein Beleg dafür sein, dass eine bestimmte Domain auch die ist, für die sie sich ausgibt. Ob ein Zertifikat beglaubigt ist wird davon bestimmt, wer das Zertifikat signiert hat. Bei nur geringem Sicherheitsbedarf, z. B. innerhalb des Intranets, können Sie Eigenzertifikate (self-signed certificates) verwenden. Eigenzertifikate verschlüsseln den Kommunikationskanal zwischen Client und Server. Der Client muss jedoch die Legitimität der Eigenzertifikate auf demselben Kanal überprüfen. Die gebräuchlichste Reaktion eines Clients auf ein Eigenzertifikat ist die Frage, ob dem Zertifikat zu trauen ist oder ihm gleich stillschweigend zu vertrauen. Leider macht das blinde Vertrauen gegenüber Eigenzertifikaten das System anfällig für so genannte „Man-in-the-middle“-Angriffe.
Der Vorteil der Eigenzertifizierung liegt darin, dass sie gebührenfrei ist, was sich besonders für Testzwecke lohnt. Außerdem kann man einem Eigenzertifikat vertrauen, wenn das eigene Zertifikat seriös ist. Wenn also ein Systemadministrator ein Eigenzertifikat erstellt, es persönlich in einem so genannten „Truststore“ des Clients installiert (so dass es ein beglaubigtes Zertifikat darstellt) können Sie sicher sein, dass die SSL-Verbindung nur zwischen dem Client und dem richtigen Server funktioniert.
Für höhere Sicherheitsanforderungen sollten Sie Ihr Zertifikat von einer CA (Certificate Authority=Berechtigte Stelle zur Bestätigung digitaler Schlüssel) signieren lassen. Normalerweise beinhalten Client-Truststores Zertifikate der größeren CAs und können so prüfen, ob ein Zertifikat von einer CA signiert wurde. Durch diese Sicherheitskette können Clients auch Zertifikaten von Servern, mit denen sie bisher noch nicht verbunden waren, vertrauen. Das Signieren von Zertifikaten gleicht dem Gang zum Notar (Identitätsprüfung, Einträge und Kosten).
HELIOS WebShare wird mit einem eigensignierten Standardzertifikat ausgeliefert, welches dazu dient, Anfangstests durchzuführen.
Die folgenden Anweisungen dienen ausschließlich Demonstrationszwecken. Verwenden
Sie daher zum Sichern Ihres WebShare Servers niemals die Datei „adaptorssl.key“,
die der Software beiliegt, da dieser Schlüssel jedermann zugänglich ist!
Wir raten Ihnen dringend, sich Ihr eigenes Serverzertifikat zu erstellen
(siehe Kapitel 6.4.5 „Ein Serverzertifikat erstellen“)!
Auf dem WebShare Webserver ist es erforderlich den HTTPS/SSL Port konfigurieren. Ein geeigneter Port ist 443 (standardmäßig HTTPS). Zuerst muss der WebShare Webserver gestoppt und dann wiedergestartet werden um sicher zu stellen, dass auch die neueste Version nach „var/run/webshare.woa“ entpackt wird. Die Befehle sind:
# cd /usr/local/helios # bin/srvutil stop websharewoa # bin/srvutil start websharewoa # bin/prefvalue -k Programs/websharewoa/SSLPort -t int 443 # cp var/run/webshare.woa/Contents/Resources/adaptorssl.sample var/conf/adaptorssl.key # echo hellothere > var/conf/adaptorssl.pass
Die Präferenz SSLPort wird in Kapitel 6.5 „Präferenzen“ beschrieben.
Starten Sie den WebShare Webserver neu:
# bin/srvutil stop websharewoa # bin/srvutil start websharewoa
Der WebShare Webserver ist nun normal über HTTP wie auch über HTTPS erreichbar. Die HTTPS-Verbindungen können wie folgt aufgebaut werden: https://webshare.meinedomain.com
Der DNS Eintrag muss durch dem korrekten Namen Ihres WebShare Servers ersetzt werden.
Wenn der standardmäßige Port für SSL nicht 443 ist, muss die URL die richtige
Portnummer enthalten, für Port 2009 wäre das z. B.:
https://webshare.meinedomain.com:2009
Das Oracle SDK (Java Development Kit), ab Version 1.5, beinhaltet alle Sicherheitswerkzeuge, die Sie benötigen, um SSL auf dem WebShare Webserver zu konfigurieren. Das wichtigste ist das „keytool“, welches im Verzeichnis „JAVA_HOME/bin“ des Java Runtime Moduls liegt. JVMs (Java Virtual Machine) von Oracle behalten Keystores und Truststores im Dateisystem als verschlüsselte Dateien bei. „keytool“ wird benutzt um Einträge in diesen Dateien zu generieren, zu lesen, zu aktualisieren und zu löschen.
Zusätzliche Informationen über „keytool“ finden Sie unter:
docs.oracle.com/javase/1.5.0/docs/tooldocs/
Um SSL auf Ihrem Server zu konfigurieren, gehen Sie wie folgt vor:
Legen Sie die HELIOS WebShare Serverdomain fest.
Erstellen Sie ein SSL-Eigenzertifikat für Ihre Serverdomain.
(Optional) Lassen Sie sich von einer CA (Certification Authority)
das SSL Serverzertifikat signieren.
a) Erzeugen sie ein CSR (Certificate Signing Request).
b) Senden Sie Ihr CSR zum Signieren zu einer CA.
(Optional) Importieren Sie das von der CA erhaltene Serverzertifikat in die Keystore-Datei.
Detaillierte Anweisungen für jeden der oben aufgeführten Schritte:
1. Eine Serverdomain festlegen
Die WebShare Webserverdomain sollte dem Hostnamen des Servers entsprechen,
beispielsweise „webshare.meinedomain.com“.
2. Ein Eigenzertifikat erstellen
Um ein Eigenzertifikat zu erstellen, nutzen Sie das Kommando „keytool“ auf dem
WebShare Webserver:
# cd usr/local/helios/var/conf
Erstellen Sie mithilfe des Java „keytool“, welches im Java „/bin“-Verzeichnis liegt, einen Schlüssel.
# keytool -genkey -keystore adaptorssl.key -keyalg rsa -alias webshare.yourdomain.com
Sie müssen dazu die folgenden Fragen beantworten:
Enter the keystore password:
<Ihr persönliches Kennwort>
What is your first and last name?
webshare.yourdomain.com
(muss Ihrem Server DNS-Namen entsprechen)
What is the name of your organizational unit?
<Ihre Abteilung>
What is the name of your organization?
<Ihr Firmenname>
What is the name of your City or Locality?
<Ihr Wohnort>
What is the name of your State or Province?
<Ihr Bundesland oder Kanton>
What is the two-letter country code for this unit?
DE
(für „Germany“)
Bestätigen Sie die Richtigkeit Ihrer Angaben oder brechen Sie über „CRTL-C“ ab und beginnen Sie von vorn.
Enter key password for <webshare.meinedomain.com>
<Nur ENTER drücken; von WebShare nicht uterstützt>
Die Datei „adaptorssl.key“ wird nun erstellt.
Als nächstes tragen Sie das Keystore-Kennwort in die Konfigurationsdatei „adaptorssl.pass“ ein, welche vom WebShare Webserver benutzt wird um den Zugang zum Inhalt der Datei „adaptorssl.key“ zu bekommen.
Erzeugen Sie die Kennwort-Datei „adaptorssl.pass“:
# cd /usr/local/helios/var/conf # echo "yourpassword" > adaptorssl.pass
Um Ihr Keystore-Kennwort zu sichern kann die Datei „adaptorssl.pass“ dahingehend geändert werden, dass kein Benutzer Zugriff auf diese Datei hat, mit Ausnahme des Benutzers „root“, z. B.:
# chmod 600 adaptorssl.pass
Wenn Sie ohne Zertifikate von der CA planen, dann reichen auch eigensignierte HTTPS-Zertifikate. Die folgenden Schritte sind dann nicht mehr erforderlich.
3. Ein Zertifikat von der CA verwenden
Falls Sie ein Zertifikat von der CA benutzen möchten, müssen Sie das Zertifikat
zuerst in das Standardformat CSR exportieren. Dies können Sie mittels Java „keytool“
tun:
# keytool -certreq -keystore adaptorssl.key -alias webshare.yourdomain.com -file <CSR_filename>
Setzen Sie anstelle von „webshare.meinedomain.com“ Ihren Servernamen ein und geben Sie den Namen der Zertifizierungsdatei (CSR) ein, die Sie generieren möchten. Senden Sie die CSR zur CA und folgen Sie den weiteren Anweisungen bis zur Signatur.
4. Importieren von Serverzertifikaten
Wenn Sie ein von der CA signiertes Serverzertifikat verwenden müssen Sie es
mittels Java „keytool“ importieren:
# keytool -import -keystore adaptorssl.key -trustcacerts -alias webshare.yourdomain.com -file signed_certificate_file
Es ist wichtig, dass der Schlüssel mit dem Alias verknüpft ist, mit dem auch schon die CSR ereugt worden ist. Sollte dies nicht der Fall sein, erhalten sie eine Fehlermeldung.
Zusätzlich müssen Sie das Stammzertifikat installieren und – je nach Typ der CA und Zertifikat – ein oder mehrere Zwischenzertifikate. Details und Hilfe entnehmen Sie der Dokumentation Ihrer CA.
Beispiel für ein CA-Stammzertifikat:
# keytool -import -keystore adaptorssl.key -trustcacerts -alias root -file root_certificate_file
Beispiel für ein CA-Zwischenzertifikat:
# keytool -import -keystore adaptorssl.key -trustcacerts -alias intermediate -file intermediate_certificate_file
Die Begriffe „root“ und „intermediate“ sind nur für die interne Organisation der Keystore-Datei und können nach Ihren Wünschen geändert werden.
Es ist wichtig, dass die Keystore-Datei die vollständige Zertifikatskette enthält, von Ihrem Domain-Zertifikat bis zum CA-Stammzertifikat. Andernfalls startet der Dienst „websharewoa“ mit HTTPS nicht vernünftig.
Starten Sie den WebShare Webserver neu.
# srvutil stop websharewoa # srvutil start websharewoa
Das Einrichten der sicheren Serververbindung (SSL) ist nun abgeschlossen. WebShare kann jetzt sowohl über HTTP als auch über HTTPS erreicht werden.
Um ausschließlich den Zugriff über HTTPS und NICHT über HTTP zu erlauben,
muss die Präferenz WOPort auf 0
gesetzt werden (siehe Kapitel
6.5 „Präferenzen“).
Wie sieht ein „Certificate Request“ aus?
-----BEGIN NEW CERTIFICATE REQUEST----- MIIBxzCCATACAQAwgYYxCzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdHZXJt YW55MRAwDgYDVQQHEwdHYXJic2VuMR0wGwYDVQQKExRIRUxJT1MgU29m dHdhcmUgR21iSDEXMBUGA1UECxMOSEVMSU9TIFN1... -----END NEW CERTIFICATE REQUEST-----
Gewöhnlich muss dies mit den Zeilen „-----BEGIN...
“ und
„-----END...
“ Ihrer CA (Certificate Authority,
z. B. verisign.com) übermittelt werden.
Warum sagt mir mein Browser, dass das Zertifikat ungültig ist?
Dafür gibt es mehrere Möglichkeiten:
Die URL Ihrer Serverdomain stimmt nicht mit der im Zertifikat überein
Ihr Zertifikat wurde nicht von einer CA signiert
Ihr Zertifikat ist abgelaufen
Der von Ihnen verwendete Browser kennt die CA nicht, VeriSign ist beispielsweise bei führenden Browsern installiert
Nach unserer Erfahrung bieten Mozilla basierte Browser mehr Detailinformationen über Zertifikate als andere. Sollte ein Problem auftauchen, können diese Browser benutzt werden um zu sehen, wie das CA-Zertifikat aussehen würde.
-----BEGIN CERTIFICATE----- MIIDRzCCAvGgAwIBAgIQX6oiydIYfaEABAZyXsUOlDANBgkqhkiG9w0B AQUFADCBqTEWMBQGA1UEChMNVmVyaVNpZ24sIEluYzFHMEUGA1UECxM+ d3d3LnZlcmlzaWdu... -----END CERTIFICATE-----
Für den Fall, dass der „websharewoa“ während des Neustarts folgende Fehlermeldung ausgibt:
websharewoa: [2009-11-28 15:54:30 MEST] <main> Unable to establish an SSL connection to port 443 on this host
und sich dann beendet, stellen Sie sicher, dass der SSL Port nicht von einer anderen Anwendung benutzt wird. Beispielsweise sollte:
# netstat -an | grep 443
nicht die folgende Zeile ausgeben:
*.443 *.* 0 0 24576 0 LISTEN
Prüfen Sie auch die folgende Meldung:
websharewoa: [2009-11-28 15:54:30 MEST] <main> com.webob- jects.foundation.NSForwardException for com.webob- jects.foundation.NSForwardException for java.security.NoSuchAlgorithmException: Algorithm SunX509 not available "Algorithm SunX509 not available"
Diese zeigt an, dass die verwendete JVM SSL nicht unterstützt. Versuchen Sie diese JVM zu aktualisieren oder installieren Sie die Oracle JVM.
Microsofts Internet Explorer 6 kann für eine sichere „websharewoa“-Verbindung (über HTTPS) ausschließlich Port 443 verwenden.
Dieses Kapitel wurde nicht übersetzt, um die Eindeutigkeit der Beschreibung zu bewahren.
This section lists all the preference keys that are pertinent to the WebShare Webserver. Find a description of how to set, view, change or delete preferences, with the HELIOS “prefdump”, “prefvalue”, and “prefrestore” utility programs in “HELIOS utility programs” in the HELIOS Base manual.
Make sure that preference keys DO NOT start or end with a slash (“/”) character, and note that they are case-sensitive! Also, if any preference key or preference value includes spaces, that key or value must be enclosed in quotes.
Key: Programs/websharewoa/<preference>
Specifies the WebShare Webserver port number for HTTP access. If set to “0” (without quotes) any HTTP connection to the WebShare Webserver is denied, only HTTPS/SSL connections are accepted. In that case, make sure the preference SSLPort is set, otherwise no connection to the WebShare Webserver can be established.
In the event that hat you wish to use HTTP port 80, and Apache or another web server is also running on the WebShare Webserver, see 9.1.11 „WebShare Webserver für Port 80 konfigurieren“ for configuration details.
Specifies the port number of the mDNS proxy server that is used for mDNS (“Bonjour”) branding registrations. If more than one WebShare Webserver is used, all used ports must have the same number.
The value of this preference needs to be identical with
the mDNS proxy server TelnetPort
preference (see
HELIOS Base manual). If there should be the need to change a
value, then make sure that both preference keys are
assigned the same value!
Specifies the WebShare Webserver port number for HTTPS/SSL connections to the browser.
Specifies the host name or IP address of the WebShare Web Server. This is useful on machines with multiple IP addresses/host names. If this preference is not set, the WebShare Web Server can be reached via any IP address/host name on the machine. The preference can also be set to a comma-separated list of IP addresses/host names. In addition, this preference allows specifying a port or SSL port, meaning that, if a port or SSL port is specified, the default settings (given by WOPort and SSLPort) are overridden.
For “myDomain”, the default settings 2009 and 443 are overridden.
Access to the application:
http://myDomain:2035
and via SSL:
https://myDomain:2036
For “myDomain”, no individual port is specified so the standard settings apply.
Access to the application:
http://myDomain:2035
and via SSL:
https://myDomain:2009
Specifying the port “0” for “myDomain” means that there are no standard (i.e. unencrypted and therefore insecure) connections available.
Access via SSL only:
https://myDomain:2036
Specifies the WebShare File Server default host name
prompt for the login dialog. It corresponds to the WebShare
File Server
entry in the WebShare login page. This preference
can also be set to a comma-separated list of IP addresses or
host names. In this case a pop-up menu to choose a
WebShare File Server will be available at the login dialog.
Also aliases for IP addresses/host names can be defined:
prefvalue -k 'Programs/websharewoa/WSHostName' -t str "localhost,Server 1=fileserver,Server 2=172.16.2.222"
In this case, a pop-up menu will be available to choose a WebShare File Server showing the strings “localhost”, “Server 1” and “Server 2”.
It is also possible to specify a port number with the host name, e.g.
prefvalue -k 'Programs/websharewoa/WSHostName' -t str "localhost:2010,Server 1=fileserver,Server 2=172.16.2.222:2010"
However, specifying a port number requires that this port has also been
set, together with the host name, in the WSAllowedHostNames
preference, provided that WSAllowedHostNames
was specified.
If not, the connection is refused and an error message is issued.
If an “*” is found as a host name in the WSHostName
preference the user is allowed to enter a file server name
manually, in addition to choosing a file server from the pop-up
menu:
prefvalue -k Programs/websharewoa/WSHostName -t str "localhost:2010,Server 1=fileserver,Server 2=172.16.2.222,*"
However, if more than one host name or/and host alias are defined together with an “*”, JavaScript needs to be activated in the client application to get a pop-up menu displayed – otherwise a plain text field, showing the first defined hostname, is displayed.
If only one host name or alias is defined, the user can neither choose nor enter a file server name.
The following examples give an overview of the possible cases:
Preference value: "*"
Display on login page: an empty text field.
Preference value: "localhost:2010"
Display on login page: the string "localhost:2010"
.
Preference value: "Server 1=localhost"
Display on login page: the string “Server 1”.
Preference value: "localhost,*"
(default)
Display on login page: a text field with the value “localhost”.
Preference value: "Server 1=localhost,*"
Display on login page: a text field with the value “Server 1”.
Preference value: "Server 1=localhost,otherhost"
Display on login page: a pop-up menu with the values “Server 1” and “otherhost”.
Preference value: "Server 1=localhost,otherhost,*"
Display on login page: a pop-up menu with the values “Server 1” and “otherhost”,
and in addition the ability to enter a file server name manually.
If a list of file servers without an “*” is defined in the “WSHostName” preference, only file server names or file server aliases defined in this preference are accepted. However, if only one file server name or alias is defined – or an “*” is found as a host name – the file server name defined by the “wshost” parameter (see wshost) is used.
List of WebShare File Server host names or IP addresses which are allowed to be used on the WebShare Webserver. The string must be comma-separated if more than one “allowed” host name or IP address is specified. If not set, all host names are allowed.
Specifies the WebShare File Server port number. If more than one WebShare File Server is used, they all have to use the same port.
The value of this preference needs to be identical with the WebShare File Server preference TcpPort (7.5 „Präferenzen“). If there should be the need to change a value, then make sure that both preference keys are assigned the same value!
This preference allows specifying a password for a protected HTML page, which allows monitoring the WebShare Webserver and the events it is processing. By default, the page is unavailable until a password is set. For security reasons, this preference should not be used unless you are an WebObjects deployment specialist and you know how the WebShare Webserver and WebObjects work internally.
The default time-out value for uploads and downloads of the WebShare Webserver is 24 h (=86400 s). If more time is needed, e.g. due to a slow Internet connection, this preference may be set to a higher value.
Specifies that, after a user has been idle for a time, i.e. no web activity has occurred, the session will automatically be closed after one hour (=3600 s).
Modern browsers, e.g. Safari, Firefox, Internet Explorer
support “gzip” compressed HTML pages. If supported by
the browser, the WebShare Webserver generates “gzip”
compressed HTML pages. For slow connections, e.g. via
modem or ISDN lines this will increase the browsing
performance by a factor of 2-5, depending on the content.
In case of problems with compressed pages this feature can
be turned off by setting this preference to FALSE
.
If this preference is set to TRUE
, and an error occurs, a stack
trace (debugging information) is printed on the error page.
The values of this preference are passed through to the Java command when starting the “websharewoa” service. If specified, behavior, performance or debugging options can be set.
Use this preference with caution! Providing invalid arguments will preclude “websharewoa” from starting! Providing wrong argument values can cause considerable performance issues.
Specifies the interval in seconds in which the watchdog process checks the WebShare Webserver (“websharewoa”) for plausibility of its output to the web browser.
Specifies a list of strings that are mandatory in the WebShare Webserver response to the web browser if the behavior is normal. If just one of these strings is missing, the “websharewoa” service is restarted. An example for a mandatory string is: “<!DOCTYPE html PUBLIC”.
Specifies a list of strings that must not be contained in the WebShare Webserver response to the web browser. If just one of these strings is included, the “websharewoa” service is restarted.