Servoy 2020 Documentation
Child pages
  • Network Related Settings
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

The Servoy Application Server exposes several services to the network it is connected to. Among other they are the following Services:

  • Launch & run Smart Clients
  • Launch & run Web Clients
  • Host the Servoy Admin page
  • Expose services of plugins, like the PDF Forms and RESTful Web Services plugins

This chapter discusses the various configuration options in the area of network connectivity, including the ports over which the services are exposed and enabling HTTPS & SSL. The network configuration options for Smart Client connectivity comprises the majority of this chapter, as it is the most extensive

Table of Contents

High level overview

The Servoy Application Server exposes the majority of it's services over the so-called HTTP Port (default port 8080). Through this port the Servoy Admin page, the Web Clients and plugin services are exposed to the outside world.

How Smart Clients communicate with the Servoy Application server depends largely on the chosen configuration. By default the communication goes through the so-called RMI port (default port 1099), but the Servoy Application Server can be configured to tunnel all the communication over the HTTP port as well, through the so-called Tunnel.

All network communication with the Servoy Application Server can be optionally secured, by enabling HTTPS for all traffic over the HTTPS port and by enabled SSL encryption for the communication between the Smart Client and the Application Server.

Setting the HTTP port

The HTTP port, used to expose many of the services of the Servoy Application Server can be configured by editing the server.xml file located in ../application_server/server/conf. This file contains the following entry by default:

<Connector port="8080" protocol="HTTP/1.1" maxThreads="500" connectionTimeout="60000" redirectPort="8443" useBodyEncodingForURI="true" />

By altering the value of the "port" attribute, for example to 9090 or 80, the port on which the services of the Servoy Application Server are exposed can be changed. In order for the changes to gointo effect a restart of the Application Server is required.

Note that on some operating systems, like Linux of FreeBSD, bind a process to a port number lower than 1024 (for example the default HTTP port 80) required the process to run as root or under administrator privileges.

Enabling HTTPS

HTPPS can be enabled by added an additional connector, configured for secure access to the server.xml file located in ../application_server/server/conf.

In order to create a secure HTTPS connector a keystore with a signed SSL Certificate is required. While it's possible to enable SSL withough a keystore, this is insecure and browsers will generate security warnings when accessing webpages through HTTPS. For more information on how to create a keystore, see Creating a keystore

<Connector port="8443"
           maxThreads="500" connectionTimeout="60000"
           scheme="https" secure="true" SSLEnabled="true"
           keystoreFile="conf/keystore" keystorePass="changeit"/>

The following attributes in the connector above most likely require modification:

  • keystoreFile: The value of this attribute needs to refer to the location plus name of the keystore (either absolute or relative to the server home directory (../application_server))
  • keystorePass: The passPhrase of the keystore. The passPhrase is specified when creating the keystore

Additionally, the value of the port attribute needs to be brought in sync with the value of the redirectPort attribute of the standard HTTP connector (or vise versa), as the redirectPort attribute on the HTTP connector is used to redirect HTTP traffic to HTTPS when required, see #Enforcing HTTPS for all traffic.

Note that on some operating systems, like Linux of FreeBSD, bind a process to a port number lower than 1024 (for example the default HTTPS port 443) requires the process to run as root or under administrator privileges.

Enforcing HTTPS for all traffic

If HTTPS is enabled, it's possible to redirect all incoming HTTP traffic to HTTPS by editing the web.xml file located in ../application_server/server/webapps/ROOT/web_inf. Athe the bottom of the file, just before '</web-app>', add the following security-contraints to redirect all HTTP Requests to HTTPS:

<security-constraint>
    <web-resource-collection>
      <web-resource-name>Automatic SLL Forwarding</web-resource-name>
      <url-pattern>/</url-pattern>
    </web-resource-collection>
    <user-data-constraint>
      <transport-guarantee>CONFIDENTIAL</transport-guarantee>
    </user-data-constraint>
  </security-constraint>

When forcing all HTTP requests to HTTPS, the "servoy.jnlpCodebaseOverride" setting needs to be the HTTPS URL (including the HTTPS Connector port number).

Smart Client network configuration

The network configuration options for Smart Clients are quite extensive and which configuration to choose is largely dependent on the (different) network setups between the machines on which Smart Clients are launched and the Servoy Application Server. What the optimal network configuration for Smart Client is, comes down to the following questions:

  • Are some of the client machines configured to access webpages through a proxy?
  • Can the Servoy Application Server directly access the client machines on any port?
  • Can all client machines access the RMI port on the Servoy Application Server?
  • Can all client machines access the Servoy Application Server on the same IP address?

Connection Modes

The Servoy Application Server has several modes in which Smart Clients can communicate with the Application Server. Which mode is the best depends on the network setup between the Servoy Application Server and the client machines on which the Smart Client will be launched. As the Servoy Smart Client runs over both a LAN and WAN's, including over the internet, it can be that there are different network setups for different client machines. 

  • Direct Connections
    In Direct Connection mode Smart Clients connect to the Application Server for communication over the configured RMI port. Vise versa, the Application Server connects to the client machine on a random port to communicate with the Smart Client. 
    While being the mode with the least overhead, only has limited use cases. Using direct connections, all Smart Clients should be able to access the Servoy Application Server under the same IP address and access to the RMI port of the server should not be restricted. Secondly the Servoy Application Server should be able to connect without restrictions to any port on any client machine that will run a Smart Client. This scenario is not very likely, due to firewalls, proxies and anti-virus software.
    Direct connection mode does not support compression and SS.
  • Two-Way socket
    Two-Way socket mode provides a more robust communication mechanism between Smart Clients and the Servoy Application Server, where only the Smart Client initiates connections to the Application Server. This means that only the Smart Clients need to be able to access the Application Server and that the Application Server does not need to be able to connect to the client machine, like is required when using direct connections.
    However Two-Way Socket connections are not possible if the client machine is configured to to through a proxy to access webpages. In that scenario the Java Web Start mechanism already initializes the communication mechanism for use with a proxy, stopping Servoy from initializing Two-Way socket mode, thus falling back to Direct Connection mode, with it's limitations mentioned above. 
  • Tunnel
    Servoy comes with a so-called tunnel that Smart Clients can use to connect to Application Server. The tunnel is the most robust communication mode available, at the cost of utilization of server-side resources. For each Smart Client more memory, threads and sockets (connections) are used on the Application Server. The tunnel supports to modes, namely HTTP and Socket:
    • HTTP Tunnel
      When using the tunnel in HTTP mode, all communication between the Smart Client and the Application Server is done using the HTTP Protocol, over the HTTP port on which the Application Server runs. The benefit of this mode is that it doesn't require that the client machines can access the Application Server on the RMI port. This can be a huge benefit in cases where it's not possible to open up access to the RMI port. When Smart Clients connect to the Application Server using the HTTP Tunnel, they will utilize threads and connections from the Tomcat application server that underlies the Servoy Application Server. 
    • Socket Tunnel
      The tunnel in Socket mode is similar to the tunnel in HTTP mode, except that the communication with the Application Server goes over the RMI port of the Application Server. This means that the RMI port of the Application Server should be accessible from all client machines that will run Smart Clients. Unlike the tunnel in HTTP mode, the tunnel in Socket mode uses server-side resources (threads & sockets (connections)) directly in Servoy, not through Tomcat. 

Profiles

SSL

Tunnel:

Tunnel over HTTP:

Tunnel over socket connection:

HTTP & Socket tunnel

Profiles

----The Network Settings node on the Servoy Admin page exposes the Servoy Application Server settings that relate to network connectivity. The Network Settings node can be accessed through <serverUrl>/servoy-admin/network-settings

The Servoy Application Server provides, among others, the following services:

  • No labels