7 WebShare Web Server

The WebShare Web Server (“webshare.woa”) is a Java program running on a server with an internet connection. It can be installed on the same machine where the WebShare File Server is installed, in which case it is called a “single server solution”. To increase the level of file system security, the WebShare Web Server should be installed on a separate server, in a “two-tier server solution”.

Ideally no other applications or services would be running on the WebShare Web Server. This allows the blocking of all ports and services (by software and/or hardware firewalls), except for those required by WebShare.

Due to the fact that no data files are stored or cached on the WebShare Web Server, a high level of WebShare File Server security is ensured. The WebShare Web Server uses one dedicated TCP/IP port for all web clients, by default 2009.

During the installation of HELIOS WebShare the packed file “websharewoa.tar” is installed in the directory “HELIOSDIR/etc/webshare”. The “start-helios” command then extracts the file in the directory “HELIOSDIR/var/run” to the “webshare.woa” package.

7.1 WebShare license information

The WebShare product includes two server components. The WebShare File Server which is licensed on a given HELIOS machine ID (mach ID) and a WebShare Web Server which may run on a separate server machine. The WebShare Web Server belongs to the WebShare server product and will not require a separate WebShare activation key.

The complete HELIOS software license terms must be accepted during the installation and can be found on the product CD.

7.2 WebShare Web Server files

The “HELIOSDIR/var/run/webshare.woa/Contents/Resources/” folder contains the following files:

Accounting.wo/: Accounting HTML page component
AccountingDetails.wo/: HTML page component for detailed accounting information
AdmPrefs.wo/: Preferences administration HTML page component
AdmShares.wo/: Sharepoint administration HTML page component
AdmUsers.wo/: User administration HTML page component
Admin.wo/: Main administration HTML page component
FileBrowser.wo/: HTML component for browsing files and directories
FilePreview.wo/: HTML component for document and image previews
ForgotPassword.wo/: Template HTML component for forgotten passwords
Goodbye.wo/: Logout HTML page component
Login.wo/: Login HTML page component
Main.wo/: Welcome and select server page component
PagePreview.wo/: HTML component for image proofs
RegisterNewUser.wo/: Template HTML component for registering new users
Sharepoints.wo/: Sharepoint listing HTML page component
Upload.wo/: HTML component for uploading files
UserPrefs.wo/: User preferences HTML page component
WSBrandingEditor.wo/: HTML Branding Editor component
WSCSSComponent.wo/: System internal component
WSExceptionPage.wo/: System internal component
WSFileAnnotationsContent.wo/: System internal component
WSFileAnnotationsEntryContent.wo/: System internal component
WSFileAnnotationsTemplate.wo/: Template for annotations dialog
WSFileListingMenu.wo/: System internal component
WSOpenFile.wo/: Template for open file page
WSToolbar.wo/: HTML toolbar component
WSToolbarButton.wo/: System internal component
WSToolbarLink.wo/: System internal component
WSUploadForm.wo/: System internal component
WSUploadReport.wo/: System internal component
WSUploadStatus.wo/: System internal component
WebShareStats.wo/: Server statistics HTML page component
ZipDownload.wo/: System internal component

Each “*.wo” directory contains the “*.html”, “*.wod” and “*.woo” files for the corresponding web page.

The script “sbin/start-websharewoa” starts the WebShare Web Server daemon. Usually, it is started by the “srvutil start websharewoa” command during “start-helios”. In case of startup problems, it can be started manually to monitor the error messages in a terminal window via:

# cd /usr/local/helios 
# sbin/start-websharewoa

Additional logging is reported to the WebObjects log files. They are located in “HELIOSDIR/var/adm/” and are called “websharewoa.log”, with the appendices “.0” (yesterday), to “.6” (seven days ago). All internal WebObjects messages are reported to “websharewoa.log”. All HELIOS generated WebShare Web Server messages are reported to the system messages file.

7.3 Customization/Localization

WebShare includes user selectable localized language support for its user interface. This chapter describes how to customize an existing language version.

Note:: This section is about customizing the “webshare.woa” package. If no customizing is done, then this section can be ignored.

: To customize the WebShare Web Server, first copy the “webshare.woa” package from “HELIOSDIR/var/run” to “HELIOSDIR/var/webshare”.

All customization must be done in “var/webshare”. This is because whenever WebShare is started it looks for “webshare.woa” in “var/webshare”. Only if it cannot be retrieved from there, is it taken from “var/run”. The idea is that “webshare.woa” is always replaced in “var/run” in case of software updates. Being in “var/webshare”, localizations and other adjustments are preserved.

Note:: However, for new WebShare product versions or updates that incorporate new features, you must copy the “webshare.woa” package anew from “var/run” to “var/webshare”, overwriting the older package, and apply the customization/localization again. Otherwise it might be incompatible with the used WebShare File Server or new features might not be available.

7.3.1 Customizing “*.html” files

Customize all “*.html” files, using UTF-8 characters. Before changes in “*.html” files become valid, the “websharewoa” service must be stopped and restarted.

7.3.2 Customizing “*.wod” files

Customize all “*.wod” files, using UTF-8 strings. You may customize the strings with any UTF-8 compatible text editor. Before changes in “*.wod” files become valid, the “websharewoa” service must be stopped and restarted.

7.3.3 Customizing action scripts

Custom action scripts are customized by putting #Title=UTFname into the script within the first 5 lines.

Likewise, the #NameField= comment in any script can be edited. The next time you log in and select a script from the WebShare “Actions” toolbar item, a field becomes available, allowing you to submit values to the script.

Refer to 8.4 “WebShare scripts” for details on creating or customizing WebShare custom scripts and action scripts.

7.3.4 Adding additional language localizations

WebShare includes support for English, German, Japanese, Spanish, and French. Additional language localizations can only be done directly by HELIOS. Please contact your HELIOS partner for such requests.

Note:: If customizations should also be valid in localized resources, then the “<language>.lproj” folders must also be customized.

7.4 HTTP/SSL support

7.4.1 Introduction

This section outlines how to configure your SSL setup. We will describe how to use the HELIOS “wskeytool” utility to accomplish this task.

What does SSL mean?

SSL (Secure Sockets Layer) is a protocol designed by Netscape Communications Corporation to provide encrypted communications on the internet. SSL is layered beneath application protocols such as HTTP, SMTP, FTP, Telnet, Gopher, and NNTP and above the connection protocol TCP/IP. It is used by the HTTPS access method. SSL works by using a secret key to encrypt data that is transferred. Modern browsers support SSL, and many websites use the protocol to obtain confidential user information, such as credit card numbers. By convention, URLs that require an SSL connection start with https: instead of http:.

7.4.2 Background

An SSL-enabled server usually uses a secured file or database called keystore to store the keys and certificates for the server. These security credentials are used to prove to clients that the server is legitimately operating on behalf of a particular domain. If your server will only need to act as one domain, you only need one key entry and certificate in the keystore. Keys are stored in the keystore under aliases. Each alias corresponds to a domain name, e.g.
webshare.yourserver.com.

Certificates attempt to guarantee that a particular party is who they claim to be. Certificates are trusted based on who signed the certificate. If you only require light security, e.g. for internal use on trusted networks, etc. you can use “self-signed” certificates. Self-signed certificates encrypt the communication channel between client and server. However the client must verify the legitimacy of the self-signed certificate through some other channel as all current browsers reject self-signed certificates by default. Unfortunately, blindly accepting self-signed certificates opens up the system to “man-in-the-middle” attacks.

The advantage of self-signed certificates is that you can create them for free or for testing and evaluation. But as “LetsEncrypt” certificates are also free of charge, it is not worth using self-signed certificates ¹. In addition, you can safely use a self-signed certificate if you can verify that the certificate you are using is legitimate. So if a system administrator creates a self-signed certificate, then personally installs it on a client’s truststore (so that the certificate is trusted) you can be assured that the SSL connection will only work between the client and the correct server.

For higher security deployments, you should get your certificate signed by a CA (Certificate Authority). Clients truststores will usually contain certificates of the major CAs and can verify that a CA has signed a certificate. This chain of trust allows clients to trust certificates from servers they have never interacted with before. Certificate signing is similar to a public notary (with equivalent amounts of verification of identity, record keeping, and costs).

7.4.3 Import an exiting certificate

The “wskeytool" utility (see 7.5 “wskeytool”) allows importing certificates into the WebShare Web Server:

wskeytool -import -keyfile <private key> -file <public key> -trustcacerts

Example:

wskeytool -import -keyfile
          /etc/letsencrypt/live/example.com/privkey.pem
          -file /etc/letsencrypt/live/example.com/fullchain.pem
          -trustcacerts

If the private key file is encrypted, the -keyfilepass option must be specified. If private key and public key are stored in one file, the -file option must be omitted.

A documentation of all options is available using the following command:
wskeytool -import -h -v

Check the import:
wskeytool -list

The certificate should now be listed as “PrivateKeyEntry”.

7.4.4 Request and import a new certificate from a CA

In order to configure SSL on your server you need to complete the following tasks:

Decide on your HELIOS WebShare Web Server domain
Create a key pair for your server domain certificate
Have a CA certify the SSL server certificate
a) Generate a CSR (Certificate Signing Request)
b) Submit your CSR to a CA for signing
Import the server certificate obtained from the CA into the keystore

Detailed instructions for each of the above steps:

1. Decide on your HELIOS WebShare Web Server domain
The WebShare Web Server domain should match the server hostname, e.g. “webshare.yourdomain.com”, the WebShare Web Server must be accessible under this domain name.

2. Create a key pair for your server domain certificate
In order to create a server certificate key pair, use the HELIOS “wskeytool” utility on the WebShare Web Server:
# cd /usr/local/helios/bin

Generate a key:
wskeytool -genkey -alias <WebShare Web Server domain>

Note:: If you plan to change the CA for an existing certificate, just start with the following section. WebShare uses the existing certificate unless -importcert is called.

3. Have a CA certify the SSL server certificate
To get a CA signed certificate, you must first export the certificate to a file in the standard CSR format.

a) Generate a CSR:
wskeytool -certreq -file <CSR_filename>

b) Submit your CSR to a CA for signing.

4. Import the server certificate obtained from the CA into the keystore
If you had a CA sign your server certificate you must import it into your existing keystore:
wskeytool -importcert -file <signed_certificate_file> -trustcacerts

Important:: The keystore must contain the complete certificate chain, from your domain certificate to the CA root certificate. Otherwise, the “websharewoa” service will not start up properly with HTTPS.

7.4.5 Create a self-signed certificate

wskeytool -genkey -alias <WebShare Web Server domain>

Note:: Will not be accepted by Internet browsers unless an an exception rule is defined.

7.5 wskeytool

“wskeytool” is a key and certificate management utility. Its purpose is to support the user in administration of the “HELIOS WebShare Web Server” keystore, required for HTTP/SSL support.

All command and option names are preceded by a minus sign (-). The options for each command can be provided in any order.

Commands:

-certreq

Generates a CSR using the PKCS#10 format. A CSR is intended to be sent to a CA. The CA authenticates the certificate requestor (usually off-line) and will return a certificate or certificate chain, used to replace the existing certificate chain (which initially consists of a self-signed certificate) in the keystore. The private key associated with -alias is used to create the PKCS#10 certificate request. If -dname is provided, then it is used as the subject in the CSR. Otherwise, the X.500 distinguished name associated with -alias is used. If -ext is provided, the extentions from the alias were replaced. The CSR is stored in the file “<file>”. If no file is specified, the CSR is output to “stdout”.

Note:: Use the -importcert command to import the response from the CA.

Options:

-alias <alias>: Alias name of the entry to process
-sigalg <alg>: Signature algorithm name
-file <file>: Output file name
-keypass <arg>: Key password
-dname <name>: Distinguished name
-ext <name{:critical}{=value}>: X.509 extension
-keystore <keystore>: Keystore name
-storepass <arg>: Keystore password
-storetype <type>: Keystore type
-v: Verbose output
-q: Suppress console output
-h: Help output

-changealias

Move an existing keystore entry from the specified -alias to a new alias, -destalias. If no destination alias is provided, the command prompts for one. If no key password is provided, the storepass is attempted first. If this attempt fails, the user is prompted for a password.

Options:

-alias <alias>: Alias name of the entry to process
-destalias <alias>: Destination alias
-keypass <arg>: Key password
-cacerts: Access the CAcert keystore
-keystore <keystore>: Keystore name
-storepass <arg>: Keystore password
-storetype <type>: Keystore type
-v: Verbose output
-q: Suppress console output
-h: Help output

-delete

Deletes from the keystore the entry identified by -alias. The user is prompted for the alias, when no alias is provided at the command line.

Options:

-alias <alias>: Alias name of the entry to process
-cacerts: Access the CAcert keystore
-keystore <keystore>: Keystore name
-storepass <arg>: Keystore password
-storetype <type>: Keystore type
-v: Verbose output
-q: Suppress console output
-h: Help output

-exportcert

Reads from the keystore the certificate associated with -alias and stores it in the file “<file>”. By default (if the -rfc option is not specified), the certificate is output in binary encoding. If -alias refers to a key entry with an associated certificate chain, the first certificate in the chain is returned. This certificate authenticates the public key of the entity addressed by -alias. If -alias refers to a trusted certificate, then that certificate is output.

Options:

-rfc: Output in RFC style
-alias <alias>: Alias name of the entry to process
-file <file>: Output file name
-cacerts: Access the CAcert keystore
-keystore <keystore>: Keystore name
-storepass <arg>: Keystore password
-storetype <type>: Keystore type
-v: Verbose output
-q: Suppress console output
-h: Help output

-genkeypair

Wraps the public key into an X.509 v3 self-signed certificate, which is stored as a single-element certificate chain. This certificate chain and the private key are stored in a new keystore entry identified by -alias.
The -dname value is used as the issuer and subject fields in the self-signed certificate.

Options:

-alias <alias>: Alias name of the entry to process
-keyalg <alg>: Key algorithm name
-keysize <size>: Key bit size
-sigalg <alg>: Signature algorithm name
-dname <name>: Distinguished name
-ext <name{:critical}{=value}>: X.509 extension
-startdate <date>: Certificate validity start date/time
-validity <days>: Validity number of days
-keypass <arg>: Key password
-keystore <keystore>: Keystore name
-storepass <arg>: Keystore password
-storetype <type>: Keystore type
-v: Verbose output
-q: Suppress console output
-h: Help output

-import

Reads the private key from a PKCS#1, PKCS#5, PKCS#8, or PKCS#12 formatted file and the certificate or certificate chain (where the latter is supplied in a PKCS#7 formatted reply or a sequence of X.509 certificates) from a second file, and stores it in the keystore entry identified by -alias. If neither -keyfile nor -file are specified, the certificate and private key are read from “stdin”. The data to be imported must be provided either in binary encoding format (DER) or in printable encoding format (PEM, also known as Base64 encoding) as defined by the Internet RFC#1421 standard.
The alias defaults to the first hostname found in the HELIOS preference WOHost. If this preference cannot be found, the default alias is built from the first “DNS” SubjectAlternativeName or from the X.500 distinguished name “CN” extracted from the certificate.

Options:

-noprompt: Do not prompt
-trustcacerts: Trust certificates from CAcert
-alias <alias>: Alias name of the entry to process
-keyfile <file>: Private key file name
-keyfilepass <arg>: Source key password
-keyalg <alg>: Key algorithm name
-file <file>: Input file name
-keystore <keystore>: Keystore name
-storepass <arg>: Keystore password
-storetype <type>: Keystore type
-v: Verbose output
-q: Suppress console output
-h: Help output

-importcert

Reads the certificate or certificate chain (where the latter is supplied in a PKCS#7 formatted reply or a sequence of X.509 certificates) from -file, and stores it in the keystore entry identified by -alias. If no file is specified, the certificate or certificate chain is read from “stdin”.
“wskeytool” can import X.509 v1, v2, and v3 certificates, and PKCS#7 formatted certificate chains consisting of certificates of that type. The data to be imported must be provided either in binary encoding format or in printable encoding format (also known as Base64 encoding) as defined by the Internet RFC 1421 standard. In the latter case, the encoding must be bounded at the beginning by a string that starts with -----BEGIN, and bounded at the end by a string that starts with -----END.

You import a certificate for two reasons: To add it to the list of trusted certificates, or to import a certificate reply received from a CA as the result of submitting a CSR to that CA (see the -certreq command). Which type of import is intended is indicated by the value of the -alias option.
If the alias does not point to a key entry, “wskeytool” assumes you are adding a trusted certificate entry. In this case, the alias should not already exist in the keystore. If the alias does already exist, “wskeytool” outputs an error because there is already a trusted certificate for that alias, and does not import the certificate.
If the alias points to a private key entry (or no alias is provided and there is exactly one private key entry in the keystore), “wskeytool” assumes you are importing a certificate reply. The public key from the certificate has to match that private key.

Options:

-noprompt: Do not prompt
-trustcacerts: Trust certificates from CAcert
-alias <alias>: Alias name of the entry to process
-file <file>: Input file name
-keypass <arg>: Key password
-cacerts: Access the CAcert keystore
-keystore <keystore>: Keystore name
-storepass <arg>: Keystore password
-storetype <type>: Keystore type
-v: Verbose output
-q: Suppress console output
-h: Help output

-importkeystore

Imports one or all entries from another keystore (for import from PKCS#12, please note the differences to the -import command, which can also import an entry from PKCS#12, but the handling of the defaults is different).

If the -srcalias option is not provided, all entries in the source keystore are imported into the destination keystore. If a source keystore entry type is not supported in the destination keystore, or if an error occurs while storing an entry into the destination keystore, the user is prompted whether to skip the entry and continue or to quit.
If the destination alias already exists in the destination keystore, the user is prompted to either overwrite the entry or to create a new entry under a different alias name.
If the -noprompt option is provided, the user is not prompted for a new destination alias. Existing entries are overwritten with the destination alias name. Entries that cannot be imported are skipped and a warning is displayed.
The -destalias and -srckeypass options cannot be provided if the -srcalias option is not provided.

Options:

-srckeystore <keystore>: Source keystore name
-destkeystore <keystore>: Destination keystore name
-srcstoretype <type>: Source keystore type
-deststoretype <type>: Destination keystore type
-srcstorepass <arg>: Source keystore password
-deststorepass <arg>: Destination keystore password
-srcalias <alias>: Source alias
-destalias <alias>: Destination alias
-srckeypass <arg>: Source key password
-destkeypass <arg>: Destination key password
-noprompt: Do not prompt
-v: Verbose output
-q: Suppress console output
-h: Help output

-keyclone

Copy an existing keystore entry from the specified -alias to the new -destalias. If no destination alias is provided, the command prompts for one. If the original entry is protected with an entry password, the password can be supplied with the -keypass option. If no key password is provided, -storepass is attempted first. If the attempt fails, the user is prompted for a password.

If the WebShare Web Server is connected via multiple hostnames, the command -keyclone can be used to copy an key entry into the alias for another hostname. The certificate must support this name (as wild card certificate or with an X.509 certificate extension “SubjectAlternativeName”).

Options:

-alias <alias>: Alias name of the entry to process
-destalias <alias>: Destination alias
-keypass <arg>: Key password
-keystore <keystore>: Keystore name
-storepass <arg>: Keystore password
-storetype <type>: Keystore type
-v: Verbose output
-q: Suppress console output
-h: Help output

-list

Prints to “stdout” the contents of the keystore entry identified by -alias. If no alias is specified, the contents of the entire keystore are printed.
By default, this command prints the common name (CN) and the SHA1 fingerprint of a certificate. If the -v option is specified, the certificate is printed in human-readable format, with additional information such as the owner, issuer, serial number, and any extensions. You cannot specify both -v and -rfc.

When retrieving information from the keystore, the password is optional. If no password is specified, the integrity of the retrieved information cannot be verified and a warning is displayed.

Options:

-rfc: Output in RFC style
-alias <alias>: Alias name of the entry to process
-cacerts: Access the CAcert keystore
-keystore <keystore>: Keystore name
-storepass <arg>: Keystore password
-storetype <type>: Keystore type
-v: Verbose output
-h: Help output

-printcert

Reads the certificate from -file, the SSL server (-sslserver), or the signed JAR file (-JAR_file) and prints its contents in a human-readable format. Note that the -jarfile, -sslserver, and -file options cannot be provided at the same time. If neither option is specified, the certificate is read from “stdin”.
If the certificate is read from a file or “stdin”, it might be either binary encoded or in printable encoding format, as defined by the RFC 1421 Certificate Encoding standard.

Note:: This command can be used independently of a keystore.

Options:

-rfc: Output in RFC style
-file <file>: Input file name
-sslserver <server[:port]>: SSL server host and port
-jarfile <JAR_file>: Signed JAR file
-help: Help output

-printcertreq

Prints the content of a PKCS#10 format certificate request, which can be generated by the -certreq command. The command reads the request from -file. If there is no file, the request is read from “stdin”.

Note:: This command can be used independently of a keystore.

Options:

-file <file>: Input file name
-v: Verbose output
-help: Help output

-printcrl

Reads the Certificate Revocation List (CRL) from -file. A CRL is a list of digital certificates that were revoked by the CA that issued them. The CA generates the file.

Options:

-file <file>: Input file name
-v: Verbose output
-help: Help output

-storepasswd

Changes the password used to protect the integrity of the keystore contents.
If a password file for the keystore exists, the user must have write access to it. The protection for key entries, protected with the keystore password (default, like WebShare Web Server certificates), changes to the new password.

Options:

-new <arg>: New password
-cacerts: Access the CAcert keystore
-keystore <keystore>: Keystore name
-storepass <arg>: Keystore password
-storetype <type>: Keystore type
-v: Verbose output
-h: Help output

When the -v option appears, it signifies verbose mode, which means that more information is provided in the output. This is also working in combination with the -help option.

7.5.1 Completion

: Restart the WebShare Web Server.

# srvutil stop websharewoa 
# srvutil start websharewoa

SSL setup is now complete and WebShare can be reached via both HTTP and HTTPS.

Note:: To allow only HTTPS access and not HTTP, you must set the WOPort preference to 0 (see 7.6 “Preferences”).

7.5.2 Q & A

How will a “Certificate Request” look like?

-----BEGIN NEW CERTIFICATE REQUEST----- 
MIIBxzCCATACAQAwgYYxCzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdHZXJt 
YW55MRAwDgYDVQQHEwdHYXJic2VuMR0wGwYDVQQKExRIRUxJT1MgU29m 
dHdhcmUgR21iSDEXMBUGA1UECxMOSEVMSU9TIFN1... 
-----END NEW CERTIFICATE REQUEST-----

Usually this needs to be submitted including the -----BEGIN… and -----END… lines into your CA (e.g. verisign.com)

Why is my browser telling me that the certificate does not match?

There can be several reasons for this:

Your server domain name URL does not match the certificate
Your certificate has not been signed by a CA
You certificate has expired
Your browser does not know about your CA, e.g. VeriSign is installed in all major browsers

Our experience shows that Mozilla based browsers provide more detailed information on certificates than others. In a case of a problem these browsers can be used to show how the CA certificate response will look like.

7.5.3 Known issues

Problem:

If “websharewoa” issues an error message during startup:

websharewoa: [2009-11-28 15:54:30 MEST] <main> Unable to 
establish an SSL connection to port 443 on this host

and then exits, make sure that the SSL port is not used by another application, e.g.:

# netstat -an | grep 443

should not list a line like below:

*.443 *.* 0 0 24576 0 LISTEN

Also check for the following message:

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"

indicates that the used JVM implementation does not offer SSL support. Check for an update to that JVM or install the Oracle JVM.

Problem:: The Microsoft Internet Explorer 6 cannot use a port other than 443 (default) for a “websharewoa” secure HTTPS connection.

7.6 Preferences

This section lists all the preference keys that are pertinent to the WebShare Web Server. 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.

Important:: 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.

The following keys require a restart (see “srvutil” in the HELIOS Base manual) of the service to take effect:

: Key: Programs/websharewoa/<preference>

WOPort

int

2009

Specifies the WebShare Web Server port number for HTTP access. If set to “0” (without quotes) any HTTP connection to the WebShare Web Server is denied, only HTTPS/SSL connections are accepted. In that case, make sure the preference SSLPort is set, otherwise no connection to the WebShare Web Server can be established.

Note:: If you wish to use HTTP port 80, and Apache or another web server is also running on the WebShare Web Server, see 10.1.11 “Switching WebShare to port 80 on the WebShare Web Server” for configuration details.

MDNSPort

int

2006

Specifies the port number of the mDNS proxy server that is used for mDNS (“Bonjour”) branding registrations. If more than one WebShare Web Server is used, all used ports must have the same number.

Important:: 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!

SSLPort

int

443

Specifies the WebShare Web Server port number for HTTPS/SSL connections to the browser.

WOHost

str

(see description)

Specifies the hostname or IP address of the WebShare Web Server. This is useful on machines with multiple IP addresses/hostnames. 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/hostnames. 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.

Example 1:

(WOHost="myDomain:2035:2036"; WOPort="2009"; SSLPort="443";)

For “myDomain”, the default settings 2009 and 443 are overridden.

Access to the application:
http://myDomain:2035
and via SSL:
https://myDomain:2036

Example 2:

(WOHost="myDomain::2036"; WOPort="2009"; SSLPort="443";)

For “myDomain”, no individual port is specified so the standard settings apply.

Access to the application:
http://myDomain:2009
and via SSL:
https://myDomain:2036

Example 3:

(WOHost="myDomain:0:2036"; WOPort="2009"; SSLPort="443";)

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

WSRedirectToSSL

bool

FALSE

If set to TRUE, this preference induces the server to redirect the request to a secure Internet connection, for example:

http://webshare.helios.de:2009 => https://webshare.helios.de:2012

Note:: It is required that an SSL port be specified via the SSLPort or WOHost preference.

WSDenyAccessForUA

strlist

"+http"

This preference contains a string list to specify user agents which should not be serviced. This is helpful to disable web crawlers that do not honor the “robots.txt”² file, e.g.:

prefvalue -k 'Programs/websharewoa/WSDenyAccessForUA' -t strlist
              "+http://baidu.com,+http://webcrawlerXYZ.com"

Requests with a user agent string containing a string of this preference receive a status 404 (“not found”) response.

Important:: A faulty entry, e.g. a string that is included in many user agents, can block access completely!

WSPublicHost

str

This preference determines which hostname is used by default when multiple network interfaces are active on the Webshare Web Server. Setting a public hostname may also become necessary if the internal WebShare Web Server hostname is different from that when used from external, e.g. via port mapping in a router/firewall, or via a proxy server. This setting is mainly used for Quickshare generated URLs. Two different settings are supported:

Qualified hostname:: (e.g.: "webshare.yourdomain.com"); This specifies the hostname for public access when multiple network interfaces are valid. The port and SSL configuration will be used from the matching WOHost configuration with the WSPublicHost hostname specified.

URLs:

(e.g.: "https://webshare.yourdomain.com:80")

Specifies the protocol, e.g. http or https, the hostname and, optionally, a port for generated public URLs. In this case, it must be ensured that public host connections are forwarded to the WebShare Web Server, e.g.:

<external hostname>:80 => <internal hostname>:2009.

WSDisabledSSLProtocols

strlist

"SSLv3,SSLv2Hello"

By default, this preference is not set which means that SSLv3 and SSLv2Hello are disabled. This configuration is advised by Oracle for all server applications supporting HTTPS.

The list of supported HTTPS protocols depends on the Java version.

Protocols supported by Java 7:
SSLv2Hello, SSLv3, TLSv1, TLSv1.1, TLSv1.2

If this preference is set, all protocols that should be disabled must be specified. Example configuration to allow TLSv1.2 and newer only:

prefvalue -k 'Programs/websharewoa/WSDisabledSSLProtocols' -t
              strlist "SSLv2Hello,SSLv3,TLSv1,TLSv1.1"

Note:: Use this preference with care. Disabling additional protocols may cause incompatibilities with older web browsers using HTTPS.

WSHostName

str

localhost,*

Specifies the WebShare File Server default hostname 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 hostnames. 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/hostnames 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 hostname, e.g.

prefvalue -k 'Programs/websharewoa/WSHostName' -t str
"localhost:2010,Server 1=fileserver,Server 2=172.16.2.222"

However, specifying a port number requires that this port has also been set, together with the hostname, in the WSAllowedHostNames preference, provided that WSAllowedHostNames was specified at all. If not, the connection is refused and an error message is issued.

If an “*” is found as a hostname 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 hostname 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 hostname 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.

Note:: 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.

WSAllowedHostNames

str

(see description)

List of WebShare File Server hostnames or IP addresses which are allowed to be used on the WebShare Web Server. The string must be comma-separated if more than one “allowed” hostname or IP address is specified. If not set, all hostnames are allowed.

WSHostPort

int

2010

Specifies the WebShare File Server port number. If more than one WebShare File Server is used, they all have to use the same port.

Note:: The value of this preference needs to be identical with the WebShare File Server preference TcpPort (8.5 “Preferences”). If there should be the need to change a value, then make sure that both preference keys are assigned the same value!

WSUploadChunkSize

int64

1024

This preference specifies the chunk size for drag & drop uploads in MB for uploads that exceed the 4 GB limit. Split uploads become necessary because of web browser and proxy server limits.

WSDisableHTML5Upload

bool

FALSE

If this preference is set to TRUE, the drag & drop upload functionality is switched off completely. Instead the standard upload form and window will be used.

WSEventDisplayPassword

str

This preference allows specifying a password for a protected HTML page, which allows monitoring the WebShare Web Server 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 Web Server and WebObjects work internally.

WSUpDownloadTimeOut

int

86400

The default time-out value for uploads and downloads of the WebShare Web Server 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.

WOSessionTimeOut

int

3600

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).

WSGZIPResponse

bool

TRUE

Modern browsers, e.g. Safari, Firefox, Internet Explorer support “gzip” compressed HTML pages. If supported by the browser, the WebShare Web Server 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.

WSPrintJavaExceptions

bool

FALSE

If this preference is set to TRUE, and an error occurs, a stack trace (debugging information) is printed on the error page.

JavaOptions

strlist

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.

Note:: Use this preference with caution! Providing invalid arguments will preclude “websharewoa” from starting! Providing wrong argument values can cause considerable performance issues.

7.6.1 WOStarter preference keys

WatchdogInterval: int
600; Specifies the interval in seconds in which the watchdog process checks the WebShare Web Server (“websharewoa”) for plausibility of its output to the web browser.
ResponsePositive: strlist
""; Specifies a list of strings that are mandatory in the WebShare Web Server 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”.
ResponseNegative: strlist
""; Specifies a list of strings that must not be contained in the WebShare Web Server response to the web browser. If just one of these strings is included, the “websharewoa” service is restarted.

¹ LetsEncrypt requires root access to the machine on which the WebShare Web Server is installed!
² “robots.txt” in the domain root allows defining the behavior of search robots on a website.

HELIOS Manuals September 29, 2020