Project

General

Profile

Bug #5971 ยป wt_config.xml

Momo LALMI, 10/06/2017 03:38 PM

 
1
<!--
2
    Wt Configuration File.
3

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

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

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

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

    
18
<server>
19

    
20
    <!-- Default application settings
21

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

    
27
        <!-- Session management. -->
28
	<session-management>
29
            <!-- Every session runs within a dedicated process.
30

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

    
35
	       Note: currently only supported by the wtfcgi and wthttp
36
	       connectors.
37
              -->
38

    
39
	    <!--
40
	       <dedicated-process>
41
		 <max-num-sessions>100</max-num-sessions>
42
	       </dedicated-process>
43
	      -->
44

    
45
	    <!-- Multiple sessions within one process.
46

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

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

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

    
62
	       Note: the wthttp connector will ignore the num-processes
63
	       setting and use only process.
64
              -->
65
	    <shared-process>
66
	        <num-processes>1</num-processes>
67
	    </shared-process>
68

    
69
	    <!-- Session tracking strategy.
70

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

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

    
86
	    <!-- How reload should be handled.
87

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

    
95
	    <!-- Session timeout (seconds).
96

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

    
102
	    <!-- Server push timeout (seconds).
103

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

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

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

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

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

    
129
                 /usr/bin/valgrind - -leak-check=full
130
             -->
131
	    <valgrind-path></valgrind-path>
132

    
133
	    <!-- Run directory
134

    
135
               Path used by Wt to do session management.
136
	      -->
137
	    <run-directory>c:/witty</run-directory>
138

    
139
	    <!-- Number of threads per process
140

    
141
               This configures the size of the thread pool. You may
142
               want to change this value if you would like to support
143
               reentrant event loops, where you block one event loop
144
               using WDialog::exec() or related static
145
               methods. Everytime you enter such an event loop, one
146
               thread is blocked, and therefore the total number of
147
               sessions that reliably can do this is limited to the
148
               number of thread you have (minus one to unblock).
149

    
150
	       For the built-in http connector, there is a similar
151
	       config option that is specified in the whttpd config
152
	       file or on the command line (-t).
153

    
154
               The default value is 1.
155
	      -->
156
	    <num-threads>1</num-threads>
157

    
158
	</connector-fcgi>
159

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

    
162
	   To configure the wthttp connector, use command line options, or
163
	   configure default options in /etc/wt/wthttpd
164
	  -->
165
	<connector-isapi>
166
	    <!-- Number of threads per process
167

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

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

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

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

    
196
               The default value is 10.
197
	      -->
198
	    <num-threads>10</num-threads>
199

    
200
	    <!-- Maximum Request Size spooled in memory (Kb)
201
        
202
               Normally, Wt keeps incoming requests (POST data) in memory.
203
               However, malicious users could send a big POST and as such
204
               use up all memory of your HTTP server. With this parameter,
205
               you tune how big a request can be before Wt spools it in a
206
               file before processing it. Legitimate big POST messages may
207
               occur when users are expected to upload files.
208

    
209
               See also max-request-size.
210

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

    
217
        <!-- Javascript debug options
218

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

    
226
             Unless the value is 'naked',
227
	     WApplication::handleJavaScriptError() is called which by
228
	     default logs the error and terminates the session.
229
	  -->
230
	<debug>true</debug>
231

    
232
	<!-- Log file
233

    
234
	   When the log file is empty, or omitted, logging is done to
235
	   stderr. This may end up in the web server error log file
236
	   (e.g. for apache + fastcgi module), or on stderr (e.g. for
237
	   the built-in httpd).
238
         -->
239
	<log-file>c:/Temp/witty.log</log-file>
240

    
241
	<!-- Logger configuration
242

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

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

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

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

    
260
	   Some other examples:
261

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

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

    
269
	   Note debugging messages are only emitted when debugging
270
	   has been enabled while building Wt.
271
	  -->
272
	<log-config>*</log-config>
273

    
274
	<!-- Maximum HTTP request size (Kb)
275

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

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

    
284
	<!-- DoS prevention: limit plain HTML sessions
285

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

    
290
           This setting may be used to keep the ratio of plain HTML
291
           versus Ajax sessions under a certain ratio. Typically, most
292
           of your sessions will be Ajax sessions, and only a tiny
293
           fraction (e.g. less than 5%) will be plain HTML
294
           sessions. This ratio is only enforced when more than 20 sessions
295
	   have been created.
296
	  -->
297
	<plain-ajax-sessions-ratio-limit>1</plain-ajax-sessions-ratio-limit>
298

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

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

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

    
310
	<!-- Do strict serialization of events.
311

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

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

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

    
333
	<!-- Enables web socket.
334

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

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

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

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

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

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

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

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

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

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

    
382
           This option is required to make e.g. clientAddress() return the
383
           correct address.
384
	  -->
385
	<behind-reverse-proxy>false</behind-reverse-proxy>
386

    
387
	<!-- Whether inline CSS is allowed.
388

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

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

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

    
401
	   The value is specified in ms.
402
          -->
403
	<indicator-timeout>500</indicator-timeout>
404

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

    
407
	   The value is specified in ms.
408
          -->
409
	<double-click-timeout>200</double-click-timeout>
410

    
411
	<!-- Ajax user agent list
412

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

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

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

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

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

    
439
	<!-- Bot user agent list
440

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

    
444
           Each <user-agent> is a regular expression.
445
	  -->
446
	<user-agents type="bot">
447
	  <user-agent>.*Googlebot.*</user-agent>
448
	  <user-agent>.*msnbot.*</user-agent>
449
	  <user-agent>.*Slurp.*</user-agent>
450
	  <user-agent>.*Crawler.*</user-agent>
451
	  <user-agent>.*Bot.*</user-agent>
452
	  <user-agent>.*ia_archiver.*</user-agent>
453
	  <user-agent>.*Twiceler.*</user-agent>
454
	</user-agents>
455

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

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

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

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

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

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

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

    
482
	<!-- Set session-ID cookie
483

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

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

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

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

    
506
	<!-- Configure cookie checks
507

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

    
512
	 -->
513
	<cookie-checks>true</cookie-checks>
514

    
515
	<!-- Configure meta headers
516

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

    
521
	 -->
522
	<meta-headers user-agent=".*MSIE.*">
523
	  <meta name="robots" content="noindex" />
524
	</meta-headers>
525

    
526
	<!-- Runtime Properties
527
     
528
           These properties may be used to adapt applications to their
529
	   deployment environment. Typical use is for paths to resources
530
	   that may or may not be shared between several applications.
531
	  -->
532
	<properties>
533
	    <!-- baseURL property
534

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

    
538
	       a) use of relative URLs in included XHTML
539

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

    
550
	       b) widgetset mode deployments
551

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

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

    
566
            <!-- resourcesURL property
567

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

    
572
	       The default value is 'resources/'
573
              -->
574
	    <property name="resourcesURL">resources/</property>
575

    
576
	    <!-- extBaseURL property
577

    
578
               Used in conjunction with Ext:: widgets, and points to the
579
	       URL of Ext JavaScript and resource files (css, images).
580
	       See the documentation for the Ext namespace for details.
581

    
582
	       The default value is 'ext/'
583
              -->
584
	    <property name="extBaseURL">ext/</property>
585

    
586
	    <!-- favicon property
587

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

    
597
    </application-settings>
598

    
599

    
600
    <!-- Override settings for specific applications.
601

    
602
       Location refers to physical filesystem location of the
603
       application. The application prints this location (which
604
       corresponds to argv[0]) to the log file on startup, and this
605
       should match exactly.
606
      -->
607
    <!--
608
    <application-settings
609
       location="/var/www/localhost/wt-examples/hello.wt">
610
    </application-settings>
611
    -->
612
</server>
    (1-1/1)