paulb@35 | 1 | Webware's CGI adapter:
|
paulb@35 | 2 |
|
paulb@35 | 3 | Copy the Webware/WebKit/Adapters/WebKit.cgi file to your CGI directory (eg.
|
paulb@35 | 4 | /home/httpd/cgi-bin), then add a line like this to httpd.conf:
|
paulb@35 | 5 |
|
paulb@35 | 6 | ScriptAlias /webkit "/home/httpd/cgi-bin/WebKit.cgi"
|
paulb@35 | 7 |
|
paulb@35 | 8 | --------
|
paulb@35 | 9 |
|
paulb@52 | 10 | Authentication/authorisation in Webware:
|
paulb@52 | 11 |
|
paulb@52 | 12 | Since Webware provides some kind of CGI emulation environment, the actual HTTP
|
paulb@52 | 13 | headers involved with authentication/authorisation are not available to the
|
paulb@52 | 14 | WebStack transaction. Therefore, WebStack depends on Webware having access to
|
paulb@52 | 15 | the REMOTE_USER environment variable set by the Web server, and with Apache,
|
paulb@52 | 16 | this variable is only ever set when Apache itself has performed
|
paulb@52 | 17 | authentication. Whilst applications can send the "WWW-Authenticate" header to
|
paulb@52 | 18 | HTTP clients, unless Apache has been instructed to process the resulting
|
paulb@52 | 19 | username/password information, the REMOTE_USER will apparently remain
|
paulb@52 | 20 | undefined.
|
paulb@52 | 21 |
|
paulb@52 | 22 | Consequently, it is recommended that the following kind of definition is added
|
paulb@52 | 23 | to httpd.conf (for Apache) in order to give applications access to
|
paulb@52 | 24 | username/password details:
|
paulb@52 | 25 |
|
paulb@52 | 26 | <Location "/webkit/auth">
|
paulb@52 | 27 | AuthType Basic
|
paulb@52 | 28 | AuthName "AuthResource"
|
paulb@52 | 29 | AuthUserFile /usr/local/apache2/conf/users
|
paulb@52 | 30 | require valid-user
|
paulb@52 | 31 | </Location>
|
paulb@52 | 32 |
|
paulb@52 | 33 | The details of the application's deployment, including the exact pathname of
|
paulb@52 | 34 | the users file and the appropriate access policy, must obviously be defined
|
paulb@52 | 35 | according to the actual application concerned.
|
paulb@52 | 36 |
|
paulb@58 | 37 | Note that the above example will only apply authentication to either a
|
paulb@58 | 38 | specific context (for Webware releases beyond 0.8.1) and only to a specific
|
paulb@58 | 39 | "region" of possible URLs (for Webware 0.8.1 and earlier).
|
paulb@58 | 40 |
|
paulb@52 | 41 | --------
|
paulb@52 | 42 |
|
paulb@35 | 43 | For Webware releases beyond 0.8.1:
|
paulb@35 | 44 |
|
paulb@35 | 45 | WebStack applications are supported as contexts within WebKit, meaning that a
|
paulb@35 | 46 | certain prefix in the URL determines whether an application is sent a
|
paulb@35 | 47 | particular request.
|
paulb@35 | 48 |
|
paulb@35 | 49 | Each context must be defined in the Webware/WebKit/Configs/Application.config
|
paulb@35 | 50 | file within the 'Contexts' dictionary entry; for example:
|
paulb@35 | 51 |
|
paulb@44 | 52 | 'simple': '/home/paulb/Software/Python/WebStack/examples/Webware/SimpleContext',
|
paulb@35 | 53 |
|
paulb@35 | 54 | Note that the path to the context directory must be absolute, although the
|
paulb@35 | 55 | context directory may reside within WebKit itself such that the path may then
|
paulb@35 | 56 | make use of the special %(WebKitPath)s substitution.
|
paulb@35 | 57 |
|
paulb@44 | 58 | Note also that the name of the context (eg. 'simple') must not be the same as
|
paulb@44 | 59 | the name of any other package used within the application (and possibly any
|
paulb@44 | 60 | other applications in the application server), with the only reasonable
|
paulb@44 | 61 | exception being the context package name itself (eg. 'SimpleContext').
|
paulb@44 | 62 | Otherwise, the existing package will become overridden by the contents of the
|
paulb@44 | 63 | context itself. Therefore, given that the Simple package is used to hold the
|
paulb@44 | 64 | actual application code, it is not wise to use 'Simple' as the context name.
|
paulb@44 | 65 |
|
paulb@35 | 66 | Running the application server:
|
paulb@35 | 67 |
|
paulb@35 | 68 | Change into the WebKit directory within Webware. Then, specifying the
|
paulb@35 | 69 | appropriate PYTHONPATH, invoke the application server. For example:
|
paulb@35 | 70 |
|
paulb@35 | 71 | PYTHONPATH=../../../WebStack:../../../WebStack/examples/Common ./AppServer
|
paulb@35 | 72 |
|
paulb@35 | 73 | The WebStack package must reside on the PYTHONPATH, along with the package
|
paulb@35 | 74 | containing the application itself.
|
paulb@35 | 75 |
|
paulb@35 | 76 | --------
|
paulb@35 | 77 |
|
paulb@35 | 78 | For Webware 0.8.1 or earlier:
|
paulb@35 | 79 |
|
paulb@35 | 80 | Support for WebStack applications is provided by a Webware plug-in which
|
paulb@35 | 81 | associates Webware resources having certain suffixes with certain WebStack
|
paulb@35 | 82 | applications, regardless of the context within which a resource appears. In
|
paulb@35 | 83 | order to make use of such a scheme, a WebStack application would have its
|
paulb@35 | 84 | resources residing in an arbitrary URL "hierarchy", but with each resource
|
paulb@35 | 85 | having the special suffix to indicate that it belongs to that application.
|
paulb@35 | 86 |
|
paulb@35 | 87 | In the case of an application whose chosen suffix is ".xyz", it would be
|
paulb@35 | 88 | possible, for example, to define resources residing at the following URL
|
paulb@35 | 89 | paths:
|
paulb@35 | 90 |
|
paulb@35 | 91 | tasks/my-tasks.xyz
|
paulb@35 | 92 | tasks/outstanding/urgent.xyz
|
paulb@35 | 93 | agenda/today.xyz
|
paulb@35 | 94 |
|
paulb@35 | 95 | This is somewhat counter-intuitive to typical Webware concepts, and it is
|
paulb@35 | 96 | recommended that Webware releases beyond 0.8.1 are used together with the
|
paulb@35 | 97 | appropriate WebStack context mechanisms instead of using this plug-in scheme.
|
paulb@35 | 98 |
|
paulb@35 | 99 | In order to support such behaviour, the patches in the
|
paulb@35 | 100 | WebStack/patches/Webware/WebKit directory must be applied to WebKit:
|
paulb@35 | 101 |
|
paulb@35 | 102 | cd Webware/WebKit
|
paulb@35 | 103 | patch -p0 < ../../WebStack/patches/Webware/WebKit/Application.py-0.8.1.diff
|
paulb@35 | 104 | patch -p0 < ../../WebStack/patches/Webware/WebKit/HTTPRequest.py-0.8.1.diff
|
paulb@35 | 105 |
|
paulb@35 | 106 | Each plug-in, representing a WebStack application, should be visible in the
|
paulb@35 | 107 | Webware root directory. A symbolic link can be used to make each example
|
paulb@35 | 108 | appear; the Simple application being installed as follows:
|
paulb@21 | 109 |
|
paulb@21 | 110 | cd Webware
|
paulb@40 | 111 | ln -s ../WebStack/examples/Webware/SimpleApp
|
paulb@21 | 112 |
|
paulb@116 | 113 | Configuring the application server:
|
paulb@116 | 114 |
|
paulb@116 | 115 | Ensure that the ExtraPathInfo parameter in WebKit/Configs/Application.config
|
paulb@116 | 116 | is set to 0.
|
paulb@116 | 117 |
|
paulb@35 | 118 | Running the application server:
|
paulb@35 | 119 |
|
paulb@19 | 120 | Change into the WebKit directory within Webware. Then, specifying the
|
paulb@19 | 121 | appropriate PYTHONPATH, invoke the application server. For example:
|
paulb@19 | 122 |
|
paulb@19 | 123 | PYTHONPATH=../../WebStack:../../WebStack/examples/Common ./AppServer
|
paulb@19 | 124 |
|
paulb@19 | 125 | The WebStack package must reside on the PYTHONPATH, along with the package
|
paulb@19 | 126 | containing the application itself.
|