OpenWGA 7.10 - OpenWGA Concepts and Features

Publishing » Organizing website publishing

Connect web applications with hostnames

When you create web application on an OpenWGA server the initially it will only be available under its database key path.

However this normally is not how your web application gets called. In most situations you will want the users of your website to simple enter a web host name without any path and be redirected to one of your web applications. You may also want to publish different web applications on different host names.

There are three different ways to control this behaviour, to be outlined in the following chapters.

Determine a server wide default application

This is the most simple but also least configurable way. You can simply assign a default application to your server. With this done the OpenWGA server will automatically redirect requests to the root URL of OpenWGA to this application, no matter where the request came from.

How to enable this:

  • Go to OpenWGA Admin Client, Menu "Configuration", "Basic Settings"
  • Click "Edit"
  • On section "Other settings" click "show/hide more options" to show the selection box for further options
  • Find "Default Application" in this box and click it to add this option to the configuration
  • In the now appearing option field choose the application which should be your default application
  • Click button "save" to save the modified configuration

Use OpenWGA virtual host configurations

OpenWGA has its own virtual host configurations where the published web applications can be configured per host name. As they are denoted an "expert configuration" you need to check the checkbox "Export mode" to the top right in OpenWGA admin client to see them.

In expert mode virtual host configurations are available under Menu "Configuration" > "Virtual Hosts" in OpenWGA admin client. Here an example from this website:


As you can see there is a list of virtual host configurations where each one is assigned to a host name. This host name can be wildcarded with the star sign "*", so a single virtual host configuration may match a range of host names, for example "*" would match "", "" and all other subdomains.

When a request comes in OpenWGA goes through this list and looks for a matching host configuration. If one is found then its rules are applied to the request. All later configurations on the list then do not effect the request.

If no virtual host configuration matches the request it is just processed without any rules.

These are the settings on a virtual host configuration:


The following settings can be done:

  • The enabled field can be used to enable/disable a host configuration with one click
  • The host name is the primary host name of this configuration. It is matched against the server name in URLs of incoming requests. You can use the wildcard character "*" at arbitrary places which will match any string
  • The same can be said for host aliases which give you the opportunity to specify multiple host namees per virtual host configuration
  • The setting Allowed Databases knows the options "All", "None" and "Specified Databases". On the latter setting the databases that are allowed can be specified under Database allowed for this host. Allowed databases are all the web applications that will be reachable under the given host names. If someone tries to reach a web application under a host where it is not allowed OpenWGA will return a HTTP error 404 "Not Found", so it looks like those applications do not exist on this host.
  • The default database is the web application which OpenWGA will serve on URLs that do not explictly select a web application by path. In most cases this will be requests that just address the host name without any path. So this setting has the same effect as the "default application" of the previous chapter, only that it can be set per virtual host.
  • The setting hide default database in URL lets OpenWGA dispatch requests that have no database key on the first path element to the default application. It actually also effects URL generation for the default application. URLs to it will also contain no database key, making the URL shorter and maybe more "friendly on the eye".
  • Lastly you can define some virtual resources per virtual host. These are simple redirection rules where a given URL path is redirected to another path. You can use this to redirect URLs that are requested, but which do not match OpenWGA URL patterns, to actual OpenWGA resources. In most situations it is used to catch URLs that are requested by search engine bots, so you can serve something meaningful for them. The name of the virtual resource is the path that is requested below the OpenWGA base URL. Under path you can specify the path of some OpenWGA resource which should be served under this path.

Virtual host configurations have yet another effect. They are used when absolute URLs are generated by OpenWGA. In that case OpenWGA needs to choose a host name to use in the URL. It therefor searches the virtual hosts for the best matching configuration. The best match is, in this priority order:

  • either a virtual host having the current application as "default database"
  • or the first virtual host in the list to explicitly include it in the "allowed databases", when "Specified Databases" is selected
  • or the first virtual host allowing "all" databases

Use an external HTTP server

This is an option which was frequently used before OpenWGA featured virtual host configuration, mostly because it was without alternative for any non-trivial setup. Today it is only second priority as on most installations the virtual host configurations are indeed a good match and more comfortable to configure.

However there are still situations where the HTTP server may need to be used to for organizing website publishing. This is the case for example when OpenWGA is not in control of the root path but is installed to be served under some deeper context path. In other cases you may need to use certain special features of the HTTP server in order to make your custom publishing architecture work, or you are just more comfortable with configuring HTTP server redirection rules.

The most frequently used tools for this task are the Apache modules mod_proxy and mod_redirect which are quite powerful at defining custom redirection schemes. Here you can redirect custom request paths by rules of unlimited complexity, for example redirecting the server root URL to some OpenWGA resource.

This however is beyond the scope of this tutorial. See the various internet resources on custom redirection rules for these modules  instead.

Using external redirections has some drawbacks which you should consider:

  • Redirection rules have unlimited flexibility but because of this tend to become complex beyond maintainability.  Complex redirection configurations which have grown historically frequently become unpredictable in their results. Virtual host configurations in OpenWGA stay clearer and are more focussed on the task. While custom redirections sometimes may not be preventable they should be kept concise.
  • Redirection rules should not be misused so that a given site only works correctly with those rules in place. This makes it inherently harder to maintain other installations of the same site for development and testing purposes.