Wapp

Wapp - A Web-Application Framework for TCL
==========================================

Wapp is a framework for writing web applications in TCL,
with the following advantages:

  *   Small and simple API → easy to learn and use
  *   A complete app is a single small file of TCL
  *   Resistant to attacks and exploits
  *   Cross-platform → CGI, SCGI, or a built-in web server
  *   The Wapp framework itself is a single-file TCL script
  *   Easy to embedded in a larger application, if desired


  *   2-clause BSD license

Documentation
-------------

  *  ["Hello World!" App (6 lines of code)](/doc/trunk/docs/helloworld.md)
  *  [Introduction To Writing Wapp Applications](/doc/trunk/docs/intro.md)

Hints For Debugging Wapp Applications
=====================================

Here are some suggestions for debugging Wapp applications:

  +  If it seems like the [wapp-param](commands.md#wapp-param) command is not 
     working correctly, that might be because the same-origin policy
     is preventing query parameters from being parsed.
     Try adding the [wapp-allow-xorigin-parameters](commands.md#allow-xorigin)
     command to the top of the page generator proc, at
     least temporarily, to see if that clears the problem.

  +  If parts of your webpage do not appear to be working, that might
     be due to the restrictive default 
     [Content Security Policy (CSP)](https://en.wikipedia.org/wiki/Content_Security_Policy)
     that Wapp uses.  Try temporarily disabling the CSP using a command
     like <blockquote><b>wapp-content-security-policy off</b></blockquote>
     near the top of your page-generator proc.

      wapp-trim {
        <h1>Wapp Environment</h1>\n<pre>
        <pre>%html([wapp-debug-env])</pre>
      }
    }
    wapp-start $argv

Many Wapp applications contain an /env page for debugging and
trouble-shooting purpose.  Examples:
<https://sqlite.org/checklists/env> and
<https://sqlite.org/search?env=1>


2.1 Binary Resources
--------------------

  6.  If the application is launched on a command-line with the --lint
      option, then instead of running the application, Wapp scans the
      application code looking for constructs that are unsafe.  Unsafe
      constructs include things such as using 
      "[wapp-subst](commands.md#wapp-subst)" with an argument
      that is not contained within {...}.

  7.  The new (non-standard) SAME\_ORIGIN variable is provided. This variable
      has a value of "1" or "0" depending on whether or not the current HTTP
      request comes from the same origin. Applications can use this information
      to enhance their own security precautions by refusing to provide sensitive
      information or perform sensitive actions if SAME\_ORIGIN is not "1".

  8.  The --scgi mode only accepts SCGI requests from localhost.  This prevents
      an attacker from sending an SCGI request directly to the script and bypassing
      the webserver in the event that the site firewall is misconfigured or omitted.

  9.  Though cookies, query parameters and POST parameters are accessed using
      the same mechanism as CGI variables, the CGI variable names use a disjoint
      namespace.  (CGI variables are all upper-case and all others are lower-case.)
      Hence, it is not possible for a remote attacher to create a fake CGI variable 
      or override the value of a CGI variable.


Part of what makes Wapp easy to use is that it helps free application
developers from the worry of accidently introducing security vulnerabilities
via programming errors.  Of course, no framework is fool-proof.  Developers
still must be aware of security.  Wapp does not prevent every error, but
it does help make writing a secure application easier and less stressful.