From 8bb9728039eb33b43ef7e9f4469a13fc9d06d753 Mon Sep 17 00:00:00 2001
From: Kevin Whitaker <eyecreate@gmail.com>
Date: Wed, 22 Feb 2017 20:48:39 -0500
Subject: [PATCH] add config with higher upload limit. Add basic bash run
 script. Add cmake directives to put these in install location.

---
 CMakeLists.txt |   2 +
 run.sh         |   2 +
 wt_config.xml  | 612 +++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 616 insertions(+)
 create mode 100644 run.sh
 create mode 100644 wt_config.xml

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 10924b0..8d60837 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -13,3 +13,5 @@ add_executable(arbitrateor src/main.cpp src/WebInterface.cpp src/GroovePlayer.cp
 target_link_libraries(arbitrateor ${Wt_LIBRARIES} ${GROOVE_LIBRARY} ${GROOVE_FINGERPRINT_LIBRARY} ${GROOVE_PLAYER_LIBRARY} ${TAGLIB_LIBRARY} pthread boost_system stdc++fs) #TODO get threading links based on platform. Remove gcc experimental fs when official c++17 exists.
 
 install(TARGETS arbitrateor RUNTIME DESTINATION bin)
+install(FILES ${CMAKE_SOURCE_DIR}/wt_config.xml DESTINATION bin)
+install(FILES ${CMAKE_SOURCE_DIR}/run.sh DESTINATION bin)
diff --git a/run.sh b/run.sh
new file mode 100644
index 0000000..214de92
--- /dev/null
+++ b/run.sh
@@ -0,0 +1,2 @@
+#!/bin/bash
+./arbitrateor --docroot /use/share/Wt --http-address 0.0.0.0 --http-port 8080 -c wt_config.xml
diff --git a/wt_config.xml b/wt_config.xml
new file mode 100644
index 0000000..bb90281
--- /dev/null
+++ b/wt_config.xml
@@ -0,0 +1,612 @@
+<!--
+    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 seperate 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.
+              -->
+
+	    <!--
+	       <dedicated-process>
+		 <max-num-sessions>100</max-num-sessions>
+	       </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
+	       seperated.
+
+	       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 is available, otherwise URL rewriting
+		 URL:  only URL rewriting
+
+               It is recommended to stick to URL rewriting 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>
+
+	    <!-- 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>/var/run/wt</run-directory>
+
+	    <!-- Number of threads per process
+
+               This configures the size of the thread pool. You may
+               want to change this value if you would like to support
+               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).
+
+	       For the built-in http connector, there is a similar
+	       config option that is specified in the whttpd config
+	       file or on the command line (-t).
+
+               The default value is 1.
+	      -->
+	    <num-threads>1</num-threads>
+
+	</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>
+	    <!-- Number of threads per process
+
+               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.
+
+               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.
+
+               The default value is 10.
+	      -->
+	    <num-threads>10</num-threads>
+
+	    <!-- Maximum Request Size spooled in memory (Kb)
+        
+               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 (Kb)
+
+           Maximum size of an incoming POST request. This value must be
+           increased when the user is allowed to upload files.
+         -->
+	<max-request-size>30000</max-request-size>
+
+	<!-- 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.
+	  -->
+	<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.
+
+           This feature is still experimental: the Web Sockets RFC is
+           still a draft. Wt implements up to version 17 of the draft
+	   (latest as of November 2011).
+	  -->
+	<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 neccesary 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.
+
+	 -->
+	<meta-headers user-agent=".*MSIE.*">
+	  <meta name="robots" content="noindex" />
+	</meta-headers>
+
+	<!-- 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>
-- 
GitLab