wt_config.xml.in

<!--
    Wt Configuration File.

    The Wt configuration file manages, for every Wt application, settings
    for session management, debugging, directory for runtime information
    such as session sockets, and some security settings.

    Settings may be specified globally, or for a single application path.

    The path should be as configured in the Wt build process, where it
    defaults to /etc/wt/wt_config.xml. It can be overridden in the environment
    variable WT_CONFIG_XML, or with the -c startup option of wthttp.

    The values listed here are the default values, which are used when the
    declaration is missing or no configuration file is used.
  -->

<server>

    <!-- Default application settings

      The special location "*" always matches. See below for an example
      of settings specific to a single application.
      -->
    <application-settings location="*">

        <!-- Session management. -->
        <session-management>
            <!-- Every session runs within a dedicated process.

               This mode guarantees kernel-level session privacy, but as every
               session requires a separate process, it is also an easy target
               for DoS attacks if not shielded by access control.

               Note: currently only supported by the wtfcgi and wthttp
               connectors.

               max-num-sessions determines the maximum number of sessions

               num-session-threads determines the number of threads for every
               session process. If not specified, the number of threads for every
               session process is the same as the number of threads for the parent
               process.
              -->

            <!--
               <dedicated-process>
                 <max-num-sessions>100</max-num-sessions>
                 <num-session-threads>10</num-session-threads>
               </dedicated-process>
            -->

            <!-- Multiple sessions within one process.

               This mode spawns a number of processes, and sessions are
               allocated randomly to one of these processes (you should not
               use this for dynamic FCGI servers, but only in conjunction
               with a fixed number of static FCGI servers.

               This requires careful programming, as memory corruption in one
               session will kill all of the sessions in the same process. You
               should debug extensively using valgrind. Also, it is your
               responsibility to keep session state not interfering and
               separated.

               On the other hand, sessions are inexpensive, and this mode
               suffers far less from DoS attacks than dedicated-process mode.
               Use it for non-critical and well-debugged web applications.

               Note: the wthttp connector will ignore the num-processes
               setting and use only process.
              -->
            <shared-process>
                <num-processes>1</num-processes>
            </shared-process>

            <!-- Session tracking strategy.

               Possible values:
                 Auto: cookies if available, otherwise URL rewriting
                 URL:  only URL rewriting
                 Combined: uses URL rewriting, with a multi-session cookie to
                           prevent stealing of sessions through the URL. Will
                           not fall back to URL rewriting if cookies are not
                           available. This is the most secure strategy.

               It is recommended to stick to URL rewriting or Combined for session
               tracking as this is more secure (it avoids the risk of attacks
               like CSRF or BREACH), and also provides proper support for
               concurrent sessions in a single browser.
              -->
            <tracking>URL</tracking>

            <!-- How reload should be handled.

               When reload should (or rather, may) spawn a new session, then
               even in the case cookies are not used for session management,
               the URL will not be cluttered with a sessionid.
               However, WApplication::refresh() will never be called.
              -->
            <reload-is-new-session>true</reload-is-new-session>

            <!-- Session timeout (seconds).

               When a session remains inactive for this amount of time, it is
               cleaned up.
              -->
            <timeout>600</timeout>

            <!-- Idle timeout (seconds).

               When the user does not interact with the application for the set number of seconds,
               WApplication::idleTimeout() is called. By default, this
               method quits the application immediately, but it can be overridden
               if different behaviour is desired.

               This feature can be used to prevent others from taking over a session
               when the device that the Wt application is being used from is left behind,
               and is most effective in combination with a fairly short session timeout (<timeout>)

               When omitted, or left empty, this feature is disabled.
               -->
            <!--<idle-timeout>900</idle-timeout>-->

            <!-- Server push timeout (seconds).

               When using server-initiated updates, the client uses
               long-polling requests. Proxies (including reverse
               proxies) are notorious for silently closing idle
               requests; the client therefore cancels the request
               periodically and issues a new one. This timeout sets
               the frequency.
              -->
            <server-push-timeout>50</server-push-timeout>
        </session-management>

        <!-- Settings that apply only to the FastCGI connector.

           To configure the wthttp connector, use command line options, or
           configure default options in /etc/wt/wthttpd
          -->
        <connector-fcgi>
            <!-- Valgrind path

               If debugging is enabled and this path is not empty, then valgrind
               will be started for every shared process, or for every session
               which has ?debug appended to the command line.

               The variable is slighly misnamed. Not only a path can be set,
               but also options, like for example:

                 /usr/bin/valgrind - -leak-check=full
             -->
            <valgrind-path></valgrind-path>

            <!-- Run directory

               Path used by Wt to do session management.
              -->
            <run-directory>${RUNDIR}</run-directory>

        </connector-fcgi>

        <!-- Settings that apply only to the MS IIS ISAPI connector.

           To configure the wthttp connector, use command line options, or
           configure default options in /etc/wt/wthttpd
          -->
        <connector-isapi>

            <!-- Maximum Request Size spooled in memory (KiB)

               Normally, Wt keeps incoming requests (POST data) in memory.
               However, malicious users could send a big POST and as such
               use up all memory of your HTTP server. With this parameter,
               you tune how big a request can be before Wt spools it in a
               file before processing it. Legitimate big POST messages may
               occur when users are expected to upload files.

               See also max-request-size.

               The default value is 128K, which is more than enough for
               any interactive Wt event.
              -->
            <max-memory-request-size>128</max-memory-request-size>
        </connector-isapi>

        <!-- Javascript debug options

             Values:
             - naked: JavaScript errors are not caught at all
             - false: JavaScript errors are caught and a simple error message
                      is printed to indicate that something is terribly wrong
             - stack: equivalent to 'false'
             - true: JavaScript errors are rethrown after server-side logging

             Unless the value is 'naked',
             WApplication::handleJavaScriptError() is called which by
             default logs the error and terminates the session.
          -->
        <debug>false</debug>

        <!-- Log file

           When the log file is empty, or omitted, logging is done to
           stderr. This may end up in the web server error log file
           (e.g. for apache + fastcgi module), or on stderr (e.g. for
           the built-in httpd).
         -->
        <log-file></log-file>

        <!-- Logger configuration

           This configures the logger. With the default configuration,
           everything except for debugging messages are logged.

           The configuration is a string that defines rules for
           enabling or disabling certain logging. It is a white-space
           delimited list of rules, and each rule is of the form:

             [-]level : enables (or disables) logging of messages of
             the given level; '*' is a wild-card that matches all
             levels

             [-]level:scope : enables (or disables) logging of
             messages of the given level and scope; '*' is a wild-card
             that matches all levels or scopes.  The default
             configuration is "* -debug", i.e. by default everything
             is logged, except for "debug" messages.

           Some other examples:

             "* -debug debug:wthttp": logs everything, including
             debugging messages of scope "wthttp", but no other
             debugging messages.

             "* -info -debug": disables logging of info messages
             in addition to debugging messages.

           Note debugging messages are only emitted when debugging
           has been enabled while building Wt.
          -->
        <log-config>* -debug</log-config>

        <!-- Maximum HTTP request size (KiB)

           Maximum size of an incoming POST request. This value must be
           increased when the user is allowed to upload files.
         -->
        <max-request-size>128</max-request-size>

        <!-- Maximum form data (KiB)

           Maximum size of the data in a POST request of type
           'application/x-www-form-urlencoded' (used for Wt form-field values)
           Note that the maximum size is also limited by the value of
           'max-request-size'.
        -->
        <max-formdata-size>5120</max-formdata-size>

        <!--- Maximum number of pending events

            Client-side events (user-interaction, WTimer, custom js signals) are
            queued if the server did not yet respond to a previous update.
            This allows you to configure the maximum number of events in the queue.
            When the maximum is exceeded, the session stops and an error is logged
            in the server.
            Setting it to zero will disable the limit.
        -->
        <max-pending-events>1000</max-pending-events>

        <!-- Number of threads per process

           You may want to change this value if you would like to
           support more reentrant event loops, where you block one
           event loop using WDialog::exec() or related static
           methods. Everytime you enter such an event loop, one
           thread is blocked, and therefore the total number of
           sessions that reliably can do this is limited to the
           number of thread you have (minus one to unblock).

           You may also want to increase this number if your Wt
           application is regularly waiting for IO (databases, network,
           files, ...). If this number is too low, all threads could
           be waiting for IO operations to complete while your CPU
           is idle. Increasing the number of threads may help.

           Computing intensive applications may also increase this number,
           even though it is better to offload computations to a helper
           thread and user server push or a WTimer to check for
           completion of the task in order to keep your GUI responsive
           during the computations.

           When using the MS IIS ISAPI connector, this configures the
           number of threads that will be used to handle Wt requests.
           The IIS internal threads are never used to do any
           processing; all requests are forwarded to be handled in
           this threadpool. Rather than to configure a so-called
           'web-garden' in IIS, increase this number. The ISAPI
           connector will not work correctly when a web-garden is
           configured.

           The default value is 10.
              -->
        <num-threads>10</num-threads>

        <!-- Session id length (number of characters) -->
        <session-id-length>16</session-id-length>

        <!-- DoS prevention: limit plain HTML sessions

           This is a simple measure which avoids Denial-of-Service
           attacks on plain HTML sessions, which are easy to mount in
           particular in the case of progressive bootstrap mode.

           This setting may be used to keep the ratio of plain HTML
           versus Ajax sessions under a certain ratio. Typically, most
           of your sessions will be Ajax sessions, and only a tiny
           fraction (e.g. less than 5%) will be plain HTML
           sessions. This ratio is only enforced when more than 20 sessions
           have been created.

           The default is 1 (= 100%), which means that 100% of all sessions
           may be plain HTML sessions, effectively disabling this feature. If
           you set it to 0.5 for example, that means that 50% of all sessions
           may be plain HTML sessions.
          -->
        <plain-ajax-sessions-ratio-limit>1</plain-ajax-sessions-ratio-limit>

        <!-- DoS prevention: adds a puzzle to validate Ajax sessions

           This is a simple measure which avoids Denial-of-Service
           attacks on Ajax sessions.

           When enabled, a puzzle needs to be solved in the first Ajax
           request which eliminates agents that do not build a proper
           DOM tree.
          -->
        <ajax-puzzle>false</ajax-puzzle>

        <!-- Do strict serialization of events.

           By default events are queued at the client-side, and
           transmitted to the server so that at any time only one
           request/response is pending. This scheme has a quality that
           resembles TCP: on a low-latency link you allow the
           transmission of many smaller requests, while on a high
           latency link, events will be propagated less often, but in
           batches.

           In any case, this scheme does not drop events, no matter
           how quickly they are generated.

           In rare cases, the scheme may result in unwanted behaviour,
           because the client-side is allowed to be slighly out of
           sync at the time an event is recorded with the server-side
           (and more so on high-latency links). The drastic
           alternative is to discard events while a response is
           pending, and can be configured by setting this option to
           true.
          -->
        <strict-event-serialization>false</strict-event-serialization>

        <!-- Enables web socket.

           By default Ajax and long polling are used to communicate
           between server and browser.

           By enabling web socket support, if the browser supports
           WebSockets, then WebSocket is the protocol used for
           communication between client and server. WebSockets are
           currently only supported by the built-in httpd Connector,
           which acts as both an HTTP and WebSocket server. The WebSocket
           protocol is intentionally not compatible with HTTP, through
           a special hand-shake mechanism, and requires
           that all (reverse) proxy servers also have explicit support
           for this protocol.
          -->
        <web-sockets>false</web-sockets>

        <!-- Enables the detection of webgl-capabilites.

             When this is enabled, the browser will try to create a
             webgl-context when loading to verify that it is possible. This
             is necessary when using WGLWidget.

             This can take up some load time. When your application does not
             use WGLWidget, this option can be set to false. It will improve
             the initial loading time of the web application.
        -->
        <webgl-detection>true</webgl-detection>

        <!-- Redirect message shown for browsers without JavaScript support

           By default, Wt will use an automatic redirect to start the
           application when the browser does not support
           JavaScript. However, browsers are not required to follow
           the redirection, and in some situations (when using XHTML),
           such automatic redirection is not supported.

           This configures the text that is shown in the anchor which
           the user may click to be redirected to a basic HTML version
           of your application.
          -->
        <redirect-message>Load basic HTML</redirect-message>

        <!-- Whether we are sitting behind a reverse proxy

           When deployed behind a reverse proxy (such as Apache or Squid),
           the server location is not read from the "Host" header,
           but from the X-Forwarded-For header, if present.

           This option is required to make e.g. clientAddress() return the
           correct address.

           Deprecated: use trusted-proxy-config instead. If this option is
           set to true, Wt will take the first non-local IP address from the
           Client-IP and X-Forwarded-For headers to determine the clientAddress().
          -->
        <!--<behind-reverse-proxy>false</behind-reverse-proxy>-->

        <!-- The following configuration options can be used when Wt is behind a reverse proxy.
          -->
        <trusted-proxy-config>
          <!-- Which header to use to get the real client IP address when behind a reverse proxy.

               This could be X-Forwarded-For (default), CF-Connecting-IP for Cloudflare,
               True-Client-IP, Fastly-Client-IP,...

               This will influence the IP address returned by WEnvironment::clientAddress() and
               Http::Request::clientAddress().
            -->
          <original-ip-header>X-Forwarded-For</original-ip-header>

          <!-- Which proxy servers are trusted

               You can use single IP addresses or subnets in CIDR notation.

               By default, no proxy servers are trusted and any proxy headers are ignored, e.g.
               X-Forwarded-For, X-Forwarded-Proto, etc.
            -->
          <trusted-proxies>
            <!-- loopback -->
            <!--
            <proxy>127.0.0.1/8</proxy>
            <proxy>::1/128</proxy>
            -->
            <!-- link local -->
            <!--
            <proxy>169.254.0.0/16</proxy>
            <proxy>fe80::/10</proxy>
            -->
            <!-- local -->
            <!--
            <proxy>10.0.0.0/8</proxy>
            <proxy>172.16.0.0/12</proxy>
            <proxy>192.168.0.0/16</proxy>
            <proxy>fc00::/7</proxy>
            -->
          </trusted-proxies>
        </trusted-proxy-config>

        <!-- Whether inline CSS is allowed.

           Some Wt widgets will insert CSS rules in the the inline
           stylesheet when first used. This can be disabled using this
           configuration option.

           Note: some widgets, such as WTreeView and WTableView,
           dynamically manipulate rules in this stylesheet, and will
           no longer work properly when inline-css is disabled.
          -->
        <inline-css>true</inline-css>

        <!-- The timeout before showing the loading indicator.

           The value is specified in ms.
          -->
        <indicator-timeout>500</indicator-timeout>

        <!-- The timeout for processing a double click event.

           The value is specified in ms.
          -->
        <double-click-timeout>200</double-click-timeout>

        <!-- Ajax user agent list

           Wt considers three types of sessions:
           - Ajax sessions: use Ajax and JavaScript
           - plain HTML sessions: use plain old server GETs and POSTs
           - bots: have clean internal paths and no persistent sessions

           By default, Wt does a browser detection to distinguish between
           the first two: if a browser supports JavaScript (and has it
           enabled), and has an Ajax DOM API, then Ajax sessions are chosen,
           otherwise plain HTML sessions.

           Here, you may indicate which user agents should or should
           not receive an Ajax session regardless of what they report as
           capabilities.

           Possible values for 'mode' are "white-list" or "black-list". A
           white-list will only treat the listed agents as supporting Ajax,
           all other agents will be served plain HTML sessions. A black-list
           will always server plain HTML sessions to listed agents and
           otherwise rely on browser capability detection.

           Each <user-agent> is a regular expression.
          -->
        <user-agents type="ajax" mode="black-list">
          <!-- <user-agent>.*Crappy browser.*</user-agent> -->
        </user-agents>

        <!-- Bot user agent list

           Here, you can specify user agents that should be should be
           treated as bots.

           Each <user-agent> is a regular expression.
          -->
        <user-agents type="bot">
            <user-agent>.*Googlebot.*</user-agent>
            <user-agent>.*msnbot.*</user-agent>
            <user-agent>.*Slurp.*</user-agent>
            <user-agent>.*Crawler.*</user-agent>
            <user-agent>.*Bot.*</user-agent>
            <user-agent>.*ia_archiver.*</user-agent>
            <user-agent>.*Twiceler.*</user-agent>
            <user-agent>.*Yandex.*</user-agent>
            <user-agent>.*Nutch.*</user-agent>
            <user-agent>.*MJ12bot.*</user-agent>
            <user-agent>.*Baiduspider.*</user-agent>
            <user-agent>.*Ezooms.*</user-agent>
            <user-agent>.*Sogou web spider.*</user-agent>
            <user-agent>.*AhrefsBot.*</user-agent>
        </user-agents>

        <!-- Configures different rendering engines for certain browsers.

           Currently this is only used to select IE7 compatible rendering
           engine for IE8, which solves problems of unreliable and slow
           rendering performance for VML which Microsoft broke in IE8.

           Before 3.3.0, the default value was IE8=IE7, but since 3.3.0
           this has been changed to an empty string (i.e. let IE8 use the
           standard IE8 rendering engine) to take advantage of IE8's
           improved CSS support. If you make heavy use of VML, you may need
           to revert to IE8=IE7.
          -->
        <UA-Compatible></UA-Compatible>

        <!-- Configures whether the progressive bootstrap method is used.

           The default bootstrap method first senses whether there is Ajax
           support, and only then creates the application.

           The progressive bootstrap method first renders a plain HTML
           version and later upgrades to an Ajax version.

           (Not to be confused with the Twitter Bootstrap theme)
          -->
        <progressive-bootstrap>false</progressive-bootstrap>

        <!-- Configures whether the loading the application is delayed at boot.

            By default, the loading of the application is delayed. This can in 
            some very specific circumstances lead to the browser waiting several
            seconds before loading the application. 
            
            If this is a bug that you are facing, consider setting this to false.
            This could however impact your code if you inject JS during boot.
          -->
        <delay-load-at-boot>true</delay-load-at-boot>

        <!-- Set session-ID cookie

           In its default (and recommended) configuration, Wt does not
           rely on cookies for session tracking.

           Wt has several mechanisms in place to prevent session ID stealing:
           - for an Ajax session, the session ID is not shown in the URL,
             avoiding session ID stealing through a referer attack.
           - in case the session ID is present in the URL (e.g. for a plain
             HTML session), Wt will redirect links to images or external
             anchors through an intermediate page that censors the session ID

           In case of the loss of a session ID, the impact is minimized:
           - a full page refresh is not supported if the client IP address
             changes or the user-agent changes
           - an Ajax update is protected by other state which is not exposed
             in the URL

           To still enable a full page refresh when the client IP address
           changes, an additional cookie may be set which is used only
           for this purpose, and can be enabled using this setting.
          -->
        <session-id-cookie>false</session-id-cookie>

        <!-- Configure cookie checks

         By default, Wt will test for cookie support using JavaScript.
         Because cookie manipulation from JavaScript is a common security
         risk vector, some prefer to disable these checks.

         -->
        <cookie-checks>true</cookie-checks>

        <!-- Configure meta headers

         The user-agent allows optional filtering based on the
         user-agent, using a regular expression. You can have multiple
         set-meta-headers definitions.

         Deprecated: use <head-matter> instead.

        <meta-headers user-agent=".*MSIE.*">
          <meta name="robots" content="noindex" />
        </meta-headers>
         -->

        <!-- Configure <head> matter

          The user-agent allows optional filtering based on the
          user-agent, using a regular expression. You can have multiple
          head-matter definitions.

          All contents will be inserted into the <head> tag
          verbatim. This could be useful for setting <meta> tags or
          <link> tags that are global for the entire application.
        -->
        <head-matter user-agent=".*MSIE.*">
          <meta name="robots" content="noindex" />
        </head-matter>

        <!-- Configure default headers for HTTP responses

          Headers required for security of functionality can be added here,
          to ensure their presence in each HTTP response Wt serves.
        -->
        <http-headers>
          <header name="X-Content-Type-Options" content="nosniff" />
          <header name="Strict-Transport-Security" content="max-age=15724800; includeSubDomains" />
          <header name="Referrer-Policy" content="strict-origin-when-cross-origin" />
        </http-headers>

        <!-- Configure whether header X-Frame-Option "SAMEORIGIN" is used

          Configure whether the header X-Frame-Option "SAMEORIGIN" is sent when serving
          the main page or the bootstrap.
        -->
        <x-frame-same-origin>true</x-frame-same-origin>

        <!-- Configure whether nonces are used for scripts

        Setting this to true forces every script HTML tag to have the same nonce as the one given
        in the header of the reply in order to be executed. This nonce is randomly generated for
        each reply, helping to protect against XSS attack.

        If you need to use script in a WResource, it is possible to obtain the nonce through the
        response parameter given to WResource::handleRequest().

        This will be used by Wt to generate a default CSP (Content Security Policy). The header will
        have the following content: 
        Content-Security-Policy: script-src 'nonce-{randomNonce}' 'strict-dynamic' 'unsafe-eval'.

        This enforces:
          - script-src 'nonce-{randomNonce}' 'stric-dynamic':
              that any script loaded on the page served by Wt has a nonce attached to it. This makes sure that
              the random value is matched between the request and the response. Making XSS (Cross-Side Scripting)
              much harder. The 'strict-dynamic' identifier ensures that if any script that is served by Wt requests
              another script, that this can be safely loaded without a nonce. Essentially meaning that the initially
              served script is always trusted.

         - unsafe-eval:
            that JavaScript eval() calls are still allowed. Wt uses these to process the updates the server returns.
            This response was already parsed by Wt, making any attack vector in it highly unlikely.

        Developers can make this more scrict, and provide their own CSP header(s). This can be done in the
        http-headers section. Any CSP header put there will be sent over together with the existing
        default CSP header. This means the default one is the baseline, and any policy it dictates is the minimum
        requirement. Only more strict rules the developer provides will be considered valid, and will be caught by the
        browser.

        -->
        <use-script-nonce>false</use-script-nonce>

        <!-- Configure allowed origins for CORS (only for WidgetSet entry points)

         Since Wt 3.3.8, cross-origin requests are disallowed by default.

         <allowed-origins> allows to selectively allow cross-origin requests
         for WidgetSet entry points (cross-origin requests are always disallowed
         for normal applications).

         Use <allowed-origins> to determine which origins should be allowed.
         Wt will only allow requests with an Origin header if it is an exact
         match for one of the origins in the list.

         "null" can be included in the list of allowed origins. In that case,
         Wt responds with "Access-Control-Allow-Origin: *".

         If <allowed-origins> is omitted or empty, no origins are allowed.

         If <allowed-origins> contains * (the asterisk character),
         all origins are allowed.
          -->
        <allowed-origins>
          <!-- Leave empty to disallow all origins. -->

          <!-- To allow any origin: -->
          <!-- * -->

          <!-- To allow only http://example.com and http://example.org: -->
          <!-- http://example.com,http://example.org -->
        </allowed-origins>

        <!-- Runtime Properties

           These properties may be used to adapt applications to their
           deployment environment. Typical use is for paths to resources
           that may or may not be shared between several applications.
          -->
        <properties>
            <!-- baseURL property

               The absolute URL at which the application is deployed
               (known to the user). This is needed only in two scenarios.

               a) use of relative URLs in included XHTML

               When you use relative URLs for images, etc... in
               literal XHTML fragments (e.g. in WTemplate), which need
               to resolve against the deployment path of the
               application. This will not work as expected in the
               presence of an internal application path.  This URL is
               set as base URL in the HTML, against which relative
               URLs are resolved so that these work correctly
               regardless of the internal path. It is also used
               explicitly in any URL generated by the library.

               b) widgetset mode deployments

               Another situation in which you need to define the baseURL is
               when deploying a widgetset mode application behind a reverse
               proxy. A widgetset mode application uses only absolute URLs
               because it may be hosted in a web page from an entirely
               different domain.

               By default, no baseURL is specified, in which case Wt will
               avoid using absolute URLs. Relative URLs passed in API calls
               will be "fixed" so that they resolve against the location of the
               application deploy path, even in the presence of an
               internal path.
              -->
            <!-- <property name="baseURL">"http://mysite.com/app</property> -->

            <!-- resourcesURL property

               The URL at which the resources/ folder is deployed that
               comes distributed with Wt and contains auxiliary files
               used to primarily for styles and themes.

               The default value is 'resources/'
              -->
            <property name="resourcesURL">resources/</property>

            <!-- favicon property

               By default, a browser will try to fetch a /favicon.ico icon
               from the root of your web server which is used as an icon
               for your application. You can specify an alternative location
               by setting this property, or for an individual application
               entry point by passing a location to WServer::addEntryPoint().
              -->
            <!-- <property name="favicon">images/favicon.ico</property> -->

            <!-- leafletJSURL and leafletCSSURL properties

               This is required if you want to use WLeafletMap, since leaflet itself is not bundled with Wt.
               leafletJSURL should be a valid URL leading to the leaflet JavaScript, and leafletCSSURL to the leaflet CSS.
              -->
            <!-- <property name="leafletJSURL">https://unpkg.com/leaflet@1.5.1/dist/leaflet.js</property> -->
            <!-- <property name="leafletCSSURL">https://unpkg.com/leaflet@1.5.1/dist/leaflet.css</property> -->

            <!-- google_api_key property

                The Google API key to be used with WGoogleMap.
            -->
            <!-- <property name="google_api_key"></property> -->

            <!-- Mail properties

              These properties can be used to change the default settings used by Wt::Mail::Client.

             - smtp-host: the hostname (or IP address) of the SMTP server to connect to (defaults to "localhost")
             - smtp-port: the port of the SMTP server to connect to (defaults to 25)
             - smtp-self-host: the hostname that the mail client uses to identify itself (defaults to "localhost")
             - smtp-transport-encryption: the encryption method to use in the mail client. This can be "none", "starttls", or "tls".
                                          The default is "none" for no encryption.
             - smtp-auth-method: the method to use for authentication. This can be "none", "plain", or "login".
                                 The default is "none" for no authentication.
             - smtp-auth-username: the username to use for authentication (defaults to empty)
             - smtp-auth-password: the password to use for authentication (defaults to empty)
            -->
            <!-- <property name="smtp-host">localhost</property> -->
            <!-- <property name="smtp-port">25</property> -->
            <!-- <property name="smtp-self-host">localhost</property> -->
            <!-- <property name="smtp-transport-encryption>none</property> -->
            <!-- <property name="smtp-auth-method">none</property> -->
            <!-- <property name="smtp-auth-username"></property> -->
            <!-- <property name="smtp-auth-password"></property> -->

            <!-- AuthService properties

              These properties are used to configure AuthService.

             - auth-mail-sender-name: the sender name when AuthService sends emails, defaults to "Wt Auth module"
             - auth-mail-sender-address: the sender address when AuthService sends emails, defaults to "noreply-auth@www.webtoolkit.eu"
            -->
            <!-- <property name="auth-mail-sender-name">Wt Auth module</property> -->
            <!-- <property name="auth-mail-sender-address">noreply-auth@www.webtoolkit.eu</property> -->

            <!-- OAuthService properties

              These properties are used to configure OAuthService.

             - oauth2-secret: the secret used to create the OAuth2 'state' hash. By default,
                              this is randomly generated, which is sufficient for single-process
                              deployments, but for multi-process deployments the same value must
                              be used in all processes and thus needs to be pre-configured.
             - oauth2-redirect-timeout: a timeout (in seconds) for when single-sign-on is used
                                        without popup. If a user takes longer than this to login,
                                        the application will be destroyed. The default is 10 minutes.
            -->
            <!-- <property name="oauth2-secret"></property> -->
            <!-- <property name="oauth2-redirect-timeout">600</property> -->

            <!-- SAML properties

              These properties are used to configure Saml::Service.

              - saml-secret: the secret used to create the SAML 'RelayState'. By default,
                             this is randomly generated, which is sufficient for single-process
                             deployments, but for multi-process deployments the same value must
                             be used in all processes and thus needs to be pre-configured.
              - saml-redirect-timeout: a timeout (in seconds) for when single-sign-on is used
                                       without popup. If a user takes longer than this to login,
                                       the application will be destroyed. The default is 10 minutes.
            -->
            <!-- <property name="saml-secret"></property> -->
            <!-- <property name="saml-redirect-timeout">600</property> -->

            <!-- PayPal properties

              These properties can be used to configure Wt::Payment::PayPalService,
              by calling configureFromProperties().

             - paypal-user: the PayPal API username
             - paypal-password: the PayPal API password
             - paypal-signature: the PayPal API signature
             - paypal-api-server-url: the URL of the PayPal API server
             - paypal-pay-server-url: the URL of the server where the user is redirected for the payment
             - paypal-version: the PayPal API version
            -->
            <!-- <property name="paypal-user"></property>
                 <property name="paypal-password"></property>
                 <property name="paypal-signature"></property>
                 <property name="paypal-api-server-url"></property>
                 <property name="paypal-pay-server-url"></property>
                 <property name="paypal-version"></property> -->

            <!-- TinyMCE properties

              These properties are used to configure TinyMCE for WTextEdit.

             - tinyMCEVersion: the version of TinyMCE to use, currently version 3.x and 4.x are supported
             - tinyMCEURL: the URL to the main TinyMCE script file
             - tinyMCEBaseURL: the base URL where TinyMCE is deployed.
                               The default is resourcesURL/tiny_mce for TinyMCE 3,
                               and resourcesURL/tinymce for TinyMCE 4 or later.
                               Note: resourcesURL refers to the resourcesURL property, which itself defaults to "resources/"
            -->
            <!-- <property name="tinyMCEVersion">3</property> -->
            <!-- <property name="tinyMCEURL"></property> -->
            <!-- <property name="tinyMCEBaseURL">resources/tiny_mce</property> -->
        </properties>

    </application-settings>


    <!-- Override settings for specific applications.

       Location refers to physical filesystem location of the
       application. The application prints this location (which
       corresponds to argv[0]) to the log file on startup, and this
       should match exactly.
      -->
    <!--
    <application-settings
       location="/var/www/localhost/wt-examples/hello.wt">
    </application-settings>
    -->
</server>