840 lines
36 KiB
XML
840 lines
36 KiB
XML
<!--
|
|
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>/opt/Libraries/wt-4.11.1/var/run/wt</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>
|
|
|
|
<!-- 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 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>
|