add configuration files
This commit is contained in:
Bartosz Wieczorek
parent
ca7ad8cbb2
commit
369dbd244d
@ -11,7 +11,7 @@ Config::Config() {
|
||||
password = "postgres";
|
||||
dbname = "postgres";
|
||||
port = 5432;
|
||||
debug = true;
|
||||
debug = false;
|
||||
}
|
||||
|
||||
Config::Config(std::function< bool(const std::string &, std::string &) > readProperty) {
|
||||
@ -44,6 +44,6 @@ Config::Config(std::function< bool(const std::string &, std::string &) > readPro
|
||||
readString("db_password", password, "postgres");
|
||||
readString("db_name", dbname, "postgres");
|
||||
readInt("db_port", port, 5432u);
|
||||
readBool("db_debug", debug, true);
|
||||
readBool("db_debug", debug, false);
|
||||
}
|
||||
} // namespace eedb::db
|
||||
|
||||
@ -1,9 +1,13 @@
|
||||
set(LIB webapp)
|
||||
|
||||
file(GLOB_RECURSE ${LIB}_SOURCE src/*)
|
||||
file(GLOB ${LIB}_CONFIG config/*)
|
||||
|
||||
set(CONFIG )
|
||||
configure_file(config/wt_config_${CMAKE_BUILD_TYPE}.xml ${CMAKE_BINARY_DIR}/local/etc/wt/wt_config.xml COPYONLY)
|
||||
|
||||
# find packages
|
||||
find_package(wt)
|
||||
find_package(wt REQUIRED)
|
||||
find_package(nlohmann_json CONFIG REQUIRED)
|
||||
|
||||
if (CMAKE_BUILD_TYPE STREQUAL "Debug")
|
||||
@ -17,7 +21,7 @@ else (CMAKE_BUILD_TYPE STREQUAL "Release")
|
||||
endif()
|
||||
|
||||
# create library
|
||||
add_library(${LIB} ${${LIB}_SOURCE})
|
||||
add_library(${LIB} ${${LIB}_SOURCE} ${${LIB}_CONFIG})
|
||||
|
||||
# link all
|
||||
target_include_directories(${LIB}
|
||||
|
||||
658
src/libs/webapp/config/wt_config_Debug.xml
Normal file
658
src/libs/webapp/config/wt_config_Debug.xml
Normal file
@ -0,0 +1,658 @@
|
||||
<!--
|
||||
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>false</reload-is-new-session>
|
||||
|
||||
<!-- Session timeout (seconds).
|
||||
|
||||
When a session remains inactive for this amount of time, it is
|
||||
cleaned up.
|
||||
-->
|
||||
<timeout>600</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>/home/bwieczor/src/build-eedb-Desktop_GCC_7-Debug/local/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>-*</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>
|
||||
|
||||
<!-- 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>13</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.
|
||||
-->
|
||||
<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>true</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.
|
||||
-->
|
||||
<behind-reverse-proxy>false</behind-reverse-proxy>
|
||||
|
||||
<!-- 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' or "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-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>
|
||||
|
||||
<!-- extBaseURL property
|
||||
|
||||
Used in conjunction with Ext:: widgets, and points to the
|
||||
URL of Ext JavaScript and resource files (css, images).
|
||||
See the documentation for the Ext namespace for details.
|
||||
|
||||
The default value is 'ext/'
|
||||
-->
|
||||
<property name="extBaseURL">ext/</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> -->
|
||||
</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>
|
||||
658
src/libs/webapp/config/wt_config_Release.xml
Normal file
658
src/libs/webapp/config/wt_config_Release.xml
Normal file
@ -0,0 +1,658 @@
|
||||
<!--
|
||||
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>false</reload-is-new-session>
|
||||
|
||||
<!-- Session timeout (seconds).
|
||||
|
||||
When a session remains inactive for this amount of time, it is
|
||||
cleaned up.
|
||||
-->
|
||||
<timeout>600</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>/home/bwieczor/src/build-eedb-Desktop_GCC_7-Debug/local/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>-*</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>
|
||||
|
||||
<!-- 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>13</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.
|
||||
-->
|
||||
<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>true</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.
|
||||
-->
|
||||
<behind-reverse-proxy>false</behind-reverse-proxy>
|
||||
|
||||
<!-- 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' or "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-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>
|
||||
|
||||
<!-- extBaseURL property
|
||||
|
||||
Used in conjunction with Ext:: widgets, and points to the
|
||||
URL of Ext JavaScript and resource files (css, images).
|
||||
See the documentation for the Ext namespace for details.
|
||||
|
||||
The default value is 'ext/'
|
||||
-->
|
||||
<property name="extBaseURL">ext/</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> -->
|
||||
</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>
|
||||
@ -15,13 +15,13 @@ class HomePage;
|
||||
class IWebSession;
|
||||
|
||||
using AuthPageFactory = std::function< std::unique_ptr< AuthPage >() >;
|
||||
using HomePageFactory = std::function< std::unique_ptr< HomePage >(Wt::Auth::AuthWidget&) >;
|
||||
using HomePageFactory = std::function< std::unique_ptr< HomePage >(Wt::Auth::AuthWidget &) >;
|
||||
|
||||
class WebApplication : public Wt::WApplication {
|
||||
public:
|
||||
enum class LoginState { weak, strong };
|
||||
WebApplication(std::unique_ptr< eedb::IWebSession > session, AuthPageFactory authPageFactory, HomePageFactory homePageFactory);
|
||||
~WebApplication(){}
|
||||
~WebApplication() {}
|
||||
void authEventLogin(LoginState state);
|
||||
|
||||
void authEventLogout();
|
||||
|
||||
@ -11,6 +11,8 @@ class WServer;
|
||||
} // namespace Wt
|
||||
|
||||
namespace eedb {
|
||||
|
||||
|
||||
class WebServer {
|
||||
public:
|
||||
using AppCreator = std::function< std::unique_ptr< Wt::WApplication >(const Wt::WEnvironment &) >;
|
||||
|
||||
@ -10,20 +10,13 @@
|
||||
namespace eedb {
|
||||
|
||||
struct DefaultAuthPage::DefaultAuthPagePriv {
|
||||
DefaultAuthPagePriv(Wt::Auth::AuthWidget * widget, std::unique_ptr< Wt::Auth::AbstractUserDatabase > userDatabase)
|
||||
: _authWidget{widget}, _userDatabase{std::move(userDatabase)} {
|
||||
_authWidget->model()->addPasswordAuth(eedb::auth::Services::passwordService());
|
||||
_authWidget->model()->addOAuth(eedb::auth::Services::oAuthServices());
|
||||
_authWidget->setRegistrationEnabled(true);
|
||||
_authWidget->setId("eedb.authWidget");
|
||||
}
|
||||
DefaultAuthPagePriv(std::unique_ptr< Wt::Auth::AbstractUserDatabase > userDatabase) : _userDatabase{std::move(userDatabase)} {}
|
||||
|
||||
Wt::Signal<> _onNeedEmailVerification;
|
||||
Wt::Signal<> _onUserWeakLogin;
|
||||
Wt::Signal<> _onUserStrongLogin;
|
||||
Wt::Signal<> _onUserLogout;
|
||||
|
||||
Wt::Auth::AuthWidget * _authWidget;
|
||||
std::unique_ptr< Wt::Auth::AbstractUserDatabase > _userDatabase;
|
||||
};
|
||||
|
||||
@ -31,7 +24,12 @@ DefaultAuthPage::DefaultAuthPage(const auth::Services & baseAuth,
|
||||
std::unique_ptr< Wt::Auth::AbstractUserDatabase > userDatabase,
|
||||
Wt::Auth::Login & _login)
|
||||
: AuthPage(*baseAuth.authService(), *userDatabase, _login),
|
||||
_priv{spimpl::make_unique_impl< DefaultAuthPagePriv >(this, std::move(userDatabase))} {
|
||||
_priv{spimpl::make_unique_impl< DefaultAuthPagePriv >(std::move(userDatabase))} {
|
||||
model()->addPasswordAuth(eedb::auth::Services::passwordService());
|
||||
model()->addOAuth(eedb::auth::Services::oAuthServices());
|
||||
setRegistrationEnabled(true);
|
||||
setId("eedb.authWidget");
|
||||
|
||||
login().changed().connect([this]() {
|
||||
if(login().state() == Wt::Auth::LoginState::Strong) {
|
||||
_priv->_onUserStrongLogin.emit();
|
||||
|
||||
@ -46,26 +46,23 @@ WebApplication::WebApplication(std::unique_ptr< eedb::IWebSession > session,
|
||||
authPage->registerOnUserWeakLogin([=] { authEventLogin(LoginState::weak); });
|
||||
authPage->registerOnUserStrongLogin([=] { authEventLogin(LoginState::strong); });
|
||||
authPage->registerOnUserLogout([=] { authEventLogout(); });
|
||||
authPage->processEnvironment();
|
||||
|
||||
root()->addWidget(std::move(authPage));
|
||||
root()->addWidget(std::move(authPage))->processEnvironment();
|
||||
}
|
||||
|
||||
void WebApplication::authEventLogin(WebApplication::LoginState state ) {
|
||||
if(state == WebApplication::LoginState::strong) {
|
||||
if(!_authWidget) {
|
||||
_authWidget = std::unique_ptr< Wt::Auth::AuthWidget >(
|
||||
dynamic_cast< Wt::Auth::AuthWidget * >(root()->removeWidget(root()->findById("eedb.authWidget")).release()));
|
||||
_authWidget->hide();
|
||||
}
|
||||
root()->clear();
|
||||
root()->removeStyleClass("container");
|
||||
root()->addWidget(_homePageFactory(*_authWidget));
|
||||
void WebApplication::authEventLogin(WebApplication::LoginState) {
|
||||
if(!_authWidget) {
|
||||
_authWidget = std::unique_ptr< Wt::Auth::AuthWidget >(
|
||||
dynamic_cast< Wt::Auth::AuthWidget * >(root()->removeWidget(root()->findById("eedb.authWidget")).release()));
|
||||
_authWidget->hide();
|
||||
}
|
||||
root()->clear();
|
||||
root()->removeStyleClass("container");
|
||||
root()->addWidget(_homePageFactory(*_authWidget));
|
||||
}
|
||||
|
||||
void WebApplication::authEventLogout() {
|
||||
redirect(url());
|
||||
quit();
|
||||
}
|
||||
|
||||
} // namespace eedb
|
||||
|
||||
Loading…
Reference in New Issue
Block a user