1.1 --- a/docs/AUTH.txt Fri Apr 08 22:33:56 2005 +0000
1.2 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000
1.3 @@ -1,82 +0,0 @@
1.4 -Authentication in WebStack
1.5 ---------------------------
1.6 -
1.7 -There are two principal methods of introducing authentication and applying
1.8 -access control to WebStack applications:
1.9 -
1.10 - * Use of authenticators, where the "remote user" is set in the
1.11 - server/framework environment and tested in the application.
1.12 -
1.13 - * Use of the WebStack.Resources.LoginRedirect and WebStack.Resources.Login
1.14 - modules.
1.15 -
1.16 -Application-wide Authenticators
1.17 --------------------------------
1.18 -
1.19 -First, set up the usage of such authentication mechanisms in the
1.20 -server/framework environment. For example, introduce Auth directives in your
1.21 -Apache configuration (see docs/ModPython/NOTES.txt) or protected folders in
1.22 -your Zope instance (see docs/Zope/NOTES.txt).
1.23 -
1.24 -Then, define an authenticator when deploying your application; this
1.25 -authenticator will respond with a decision when prompted by the server or
1.26 -underlying framework, either allowing or denying access for the user whose
1.27 -identity has been presented to the server/framework.
1.28 -
1.29 -In this mechanism, authenticators rely on authentication information from the
1.30 -server/framework and have a "global" effect on access to the application.
1.31 -
1.32 -LoginRedirect and Login Modules
1.33 --------------------------------
1.34 -
1.35 -The LoginRedirect and Login modules provide a single sign-on environment for
1.36 -WebStack applications. Unlike the authenticator-only approach, each
1.37 -application or part of an application utilising this mechanism must be wrapped
1.38 -inside a LoginRedirectResource object which determines whether a given
1.39 -transaction contains information identifying the application's user.
1.40 -
1.41 -Should sufficient information be present in the transaction, the user is
1.42 -allowed to access the application and is identified in the normal way (ie. the
1.43 -Transaction object's get_user method). Otherwise, a redirect occurs to a login
1.44 -screen provided by a LoginResource object which then presents a login form to
1.45 -be completed by the user.
1.46 -
1.47 -The LoginResource object verifies the identity of the user, testing the
1.48 -supplied credentials against the credentials database specified in the
1.49 -deployment of the resource. Upon successful authentication, the user is
1.50 -redirected back to the application, which should let the user gain access.
1.51 -
1.52 -Some server/framework environments do not permit automatic redirection back to
1.53 -the application, notably Apache/mod_python. In such cases, a success screen is
1.54 -presented to the user with a link to the application they were attempting to
1.55 -access.
1.56 -
1.57 -In this mechanism, authenticators are employed, but only to verify the
1.58 -credentials of users when LoginResource or LoginRedirectResource objects are
1.59 -accessed.
1.60 -
1.61 -Anonymous Access
1.62 -----------------
1.63 -
1.64 -With application-wide authenticators, anonymous access to resources and
1.65 -applications can be difficult to permit alongside access by specific users,
1.66 -mostly because servers and frameworks which employ HTTP authentication schemes
1.67 -do so globally for a given application.
1.68 -
1.69 -With the LoginRedirect and Login modules, it is possible to declare a
1.70 -particular request parameter which must be present in the URL used to access a
1.71 -particular application for the client to be given anonymous access.
1.72 -Consequently, anonymous users are then identified specially with a special
1.73 -username that can also be configured.
1.74 -
1.75 -Logout Functions
1.76 -----------------
1.77 -
1.78 -With application-wide authenticators, a logout function may not be available
1.79 -if the server/framework has been configured to use HTTP authentication
1.80 -schemes, since no such function is defined for such schemes.
1.81 -
1.82 -With the LoginRedirect and Login modules, it is possible to declare a
1.83 -particular request parameter which must be present in the URL used to access a
1.84 -particular application for the client to be logged out. A special logout
1.85 -confirmation URL may also be configured.
2.1 --- a/docs/DEPLOY.txt Fri Apr 08 22:33:56 2005 +0000
2.2 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000
2.3 @@ -1,29 +0,0 @@
2.4 -When deploying an application, it is possible to use a one-shot deploy
2.5 -function for certain frameworks. The deploy function is called as follows:
2.6 -
2.7 -deploy(resource)
2.8 -deploy(resource, authenticator) # where authenticators are used
2.9 -
2.10 -For some frameworks, an address may be specified:
2.11 -
2.12 -deploy(resource, address=(host_string, port_integer))
2.13 -deploy(resource, authenticator, address=(host_string, port_integer))
2.14 -
2.15 -Framework Address Information
2.16 ---------- -------------------
2.17 -
2.18 -BaseHTTPRequestHandler Supported
2.19 -CGI N/A
2.20 -Twisted Supported (host_string is ignored)
2.21 -WSGI N/A
2.22 -
2.23 -The other frameworks do not support the deploy function due to the way
2.24 -applications are typically integrated into the various server mechanisms:
2.25 -
2.26 -Framework Deployment Details
2.27 ---------- ------------------
2.28 -
2.29 -JavaServlet Applications are packaged specially
2.30 -ModPython Applications must expose certain functions
2.31 -Webware Applications must expose certain classes
2.32 -Zope Applications must expose certain functions/classes
3.1 --- a/docs/PATH.txt Fri Apr 08 22:33:56 2005 +0000
3.2 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000
3.3 @@ -1,13 +0,0 @@
3.4 -Path Semantics in WebStack
3.5 ---------------------------
3.6 -
3.7 - get_path_info
3.8 - -------------
3.9 -BaseHTTPRequestHandler Same as path (correct)
3.10 -CGI Path beyond resource (correct)
3.11 -Java Servlet API Path beyond context (correct)
3.12 -mod_python Path beyond resource (correct)
3.13 -Twisted Same as path (correct)
3.14 -Webware <= 0.8.1 Not supported (needs ExtraPathInfo support)
3.15 -Webware > 0.8.1 Path beyond context (correct)
3.16 -Zope 2.7.2-0 Same as path (correct)
4.1 --- a/docs/anatomy.html Fri Apr 08 22:33:56 2005 +0000
4.2 +++ b/docs/anatomy.html Fri Apr 08 23:09:33 2005 +0000
4.3 @@ -1,61 +1,58 @@
4.4 -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
4.5 +<?xml version="1.0" encoding="iso-8859-1"?>
4.6 +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
4.7 + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
4.8 <html xmlns="http://www.w3.org/1999/xhtml">
4.9 <head>
4.10 <title>Anatomy of a WebStack Application</title>
4.11 - <meta name="generator"
4.12 - content="amaya 8.1a, see http://www.w3.org/Amaya/">
4.13 - <link xmlns:xlink="http://www.w3.org/1999/xlink" href="styles.css"
4.14 - rel="stylesheet" type="text/css">
4.15 + <meta name="generator" content="amaya 8.1a, see http://www.w3.org/Amaya/" />
4.16 + <link href="styles.css" rel="stylesheet" type="text/css" />
4.17 </head>
4.18 +
4.19 <body>
4.20 <h1>Anatomy of a WebStack Application</h1>
4.21 -<p>The simplest way to think of a Web application is as just some code
4.22 -which
4.23 -gets run every time an HTTP request arrives at a specific network
4.24 -address and
4.25 -which produces an HTTP response. Without WebStack, such code often
4.26 -needs to
4.27 -be tailored to the software which causes it to be run, but with
4.28 -WebStack you
4.29 +
4.30 +<p>The simplest way to think of a Web application is as just some code which
4.31 +gets run every time an HTTP request arrives at a specific network address and
4.32 +which produces an HTTP response. Without WebStack, such code often needs to
4.33 +be tailored to the software which causes it to be run, but with WebStack you
4.34 just need to do this:</p>
4.35 <ol>
4.36 - <li>Write some application code which uses the WebStack API - this
4.37 -code can be run within any of the supported environments.</li>
4.38 + <li>Write some application code which uses the WebStack API - this code can
4.39 + be run within any of the supported environments.</li>
4.40 <li>Write some simple adapter or "glue" code - this code makes the
4.41 -application work with each of the environments that you want to use and
4.42 -should be much smaller in size than the application code.</li>
4.43 + application work with each of the environments that you want to use and
4.44 + should be much smaller in size than the application code.</li>
4.45 </ol>
4.46 -<p>Most of the time, you need only to think about the first activity
4.47 -(writing
4.48 -against the WebStack API).<br>
4.49 +
4.50 +<p>Most of the time, you need only to think about the first activity (writing
4.51 +against the WebStack API).<br />
4.52 </p>
4.53 +
4.54 <h2>A Very Simple Example</h2>
4.55 -In the simplest case, you just need to produce a Python class which
4.56 -takes
4.57 +In the simplest case, you just need to produce a Python class which takes
4.58 this form:
4.59 -<pre>class MyResource:<br><br> "This is a resource - something which defines the behaviour of an application."<br><br> def respond(self, trans):<br> [Examine the transaction, decide what the user wants to do.]<br> [Perform some kind of action with the information supplied.]<br> [Produce some kind of response which tells the user what happened.]</pre>
4.60 -<p>The parts of the pseudo-code in the above text which aren't valid
4.61 -Python
4.62 -(ie. the bits in square brackets) will use various WebStack API calls
4.63 -to look
4.64 -at what the user specified in the request and to send information back
4.65 -to the
4.66 -user in the response.<br>
4.67 +<pre>class MyResource:<br /><br /> "This is a resource - something which defines the behaviour of an application."<br /><br /> def respond(self, trans):<br /> [Examine the transaction, decide what the user wants to do.]<br /> [Perform some kind of action with the information supplied.]<br /> [Produce some kind of response which tells the user what happened.]</pre>
4.68 +
4.69 +<p>The parts of the pseudo-code in the above text which aren't valid Python
4.70 +(ie. the bits in square brackets) will use various WebStack API calls to look
4.71 +at what the user specified in the request and to send information back to the
4.72 +user in the response.<br />
4.73 </p>
4.74 +
4.75 <p>WebStack applications consist of resource classes which contain the
4.76 -application code. In the above example, the only thing we need to
4.77 -consider is what our code does, not how resource objects are created
4.78 -and invoked (that is done in the adapter code). In more complicated
4.79 -applications, there may be a need to create our own resource objects
4.80 -explicitly, but this is not particularly interesting to think about at
4.81 -this point - see <a href="paths-filesystem.html">"Treating the Path
4.82 -Like a Filesystem"</a> for a discussion of multiple resource objects.<br>
4.83 +application code. In the above example, the only thing we need to consider is
4.84 +what our code does, not how resource objects are created and invoked (that is
4.85 +done in the adapter code). In more complicated applications, there may be a
4.86 +need to create our own resource objects explicitly, but this is not
4.87 +particularly interesting to think about at this point - see <a
4.88 +href="paths-filesystem.html">"Treating the Path Like a Filesystem"</a> for a
4.89 +discussion of multiple resource objects.<br />
4.90 </p>
4.91 +
4.92 <h2>Design Considerations</h2>
4.93 -<p>When writing an application, we must consider a number of factors
4.94 -which
4.95 -have an impact on the code (and other things) that we will need to
4.96 -provide as
4.97 +
4.98 +<p>When writing an application, we must consider a number of factors which
4.99 +have an impact on the code (and other things) that we will need to provide as
4.100 part of the finished product or service.</p>
4.101 <ul>
4.102 <li><a href="paths.html">URLs and Paths</a></li>
5.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000
5.2 +++ b/docs/deploying.html Fri Apr 08 23:09:33 2005 +0000
5.3 @@ -0,0 +1,78 @@
5.4 +<?xml version="1.0" encoding="iso-8859-1"?>
5.5 +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
5.6 + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
5.7 +<html xmlns="http://www.w3.org/1999/xhtml">
5.8 +<head>
5.9 + <title>Deploying a WebStack Application</title>
5.10 + <meta name="generator" content="amaya 8.1a, see http://www.w3.org/Amaya/" />
5.11 + <link href="styles.css" rel="stylesheet" type="text/css" />
5.12 +</head>
5.13 +
5.14 +<body>
5.15 +<h1>Deploying a WebStack Application<br />
5.16 +</h1>
5.17 +
5.18 +<p>When deploying an application, it is possible to use a one-shot deploy
5.19 +function for certain frameworks. The <code>deploy</code> function is called
5.20 +as follows:</p>
5.21 +<pre>deploy(resource)
5.22 +deploy(resource, authenticator) # where authenticators are used</pre>
5.23 +
5.24 +<p>For some frameworks, an address may be specified:</p>
5.25 +<pre>deploy(resource, address=(host_string, port_integer))
5.26 +deploy(resource, authenticator, address=(host_string, port_integer))</pre>
5.27 +
5.28 +<table border="1" cellpadding="5" cellspacing="0">
5.29 + <tbody>
5.30 + <tr>
5.31 + <th>Framework</th>
5.32 + <th>Address Information</th>
5.33 + </tr>
5.34 + <tr>
5.35 + <td>BaseHTTPRequestHandler</td>
5.36 + <td>Supported</td>
5.37 + </tr>
5.38 + <tr>
5.39 + <td>CGI</td>
5.40 + <td>Ignored</td>
5.41 + </tr>
5.42 + <tr>
5.43 + <td>Twisted</td>
5.44 + <td>Supported (<code>host_string</code> is ignored)</td>
5.45 + </tr>
5.46 + <tr>
5.47 + <td>WSGI</td>
5.48 + <td>Ignored</td>
5.49 + </tr>
5.50 + </tbody>
5.51 +</table>
5.52 +
5.53 +<p>The other frameworks do not support the deploy function due to the way
5.54 +applications are typically integrated into the various server mechanisms:</p>
5.55 +
5.56 +<table border="1" cellpadding="5" cellspacing="0">
5.57 + <tbody>
5.58 + <tr>
5.59 + <th>Framework</th>
5.60 + <th>Deployment Details</th>
5.61 + </tr>
5.62 + <tr>
5.63 + <td>JavaServlet</td>
5.64 + <td>Applications are packaged specially</td>
5.65 + </tr>
5.66 + <tr>
5.67 + <td>ModPython</td>
5.68 + <td>Applications must expose certain functions</td>
5.69 + </tr>
5.70 + <tr>
5.71 + <td>Webware</td>
5.72 + <td>Applications must expose certain classes</td>
5.73 + </tr>
5.74 + <tr>
5.75 + <td>Zope</td>
5.76 + <td>Applications must expose certain functions/classes</td>
5.77 + </tr>
5.78 + </tbody>
5.79 +</table>
5.80 +</body>
5.81 +</html>
6.1 --- a/docs/index.html Fri Apr 08 22:33:56 2005 +0000
6.2 +++ b/docs/index.html Fri Apr 08 23:09:33 2005 +0000
6.3 @@ -1,38 +1,41 @@
6.4 -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
6.5 +<?xml version="1.0" encoding="iso-8859-1"?>
6.6 +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
6.7 + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
6.8 <html xmlns="http://www.w3.org/1999/xhtml">
6.9 <head>
6.10 <title>Creating Web Applications with WebStack</title>
6.11 - <meta name="generator"
6.12 - content="amaya 8.1a, see http://www.w3.org/Amaya/">
6.13 - <link xmlns:xlink="http://www.w3.org/1999/xlink" href="styles.css"
6.14 - rel="stylesheet" type="text/css">
6.15 + <meta name="generator" content="amaya 8.1a, see http://www.w3.org/Amaya/" />
6.16 + <link href="styles.css" rel="stylesheet" type="text/css" />
6.17 </head>
6.18 +
6.19 <body>
6.20 <h1>Creating Web Applications with WebStack</h1>
6.21 -<p>This set of documents describes the process of making a Web
6.22 -application
6.23 +
6.24 +<p>This set of documents describes the process of making a Web application
6.25 using the WebStack framework.</p>
6.26 +
6.27 <h2>Setting Up</h2>
6.28 +
6.29 <p>First of all, let us assume that the WebStack distribution has been
6.30 unpacked and now sits in the <code>WebStack-0.9</code> directory.</p>
6.31 -<p>Before we begin, we must make sure that the WebStack package is
6.32 -available
6.33 +
6.34 +<p>Before we begin, we must make sure that the WebStack package is available
6.35 to Python. The easiest way to do this is to change into the
6.36 <code>WebStack-0.9</code> directory and to run the <code>setup.py</code>
6.37 script provided with the version of Python you are going to be using
6.38 (possibly as a privileged user like <code>root</code>):</p>
6.39 -<pre>cd WebStack-0.9<br>python setup.py install</pre>
6.40 -<p>If you don't want to install WebStack in this way, or if you can't
6.41 -do so
6.42 -because you don't have <code>root</code> privileges, you can just make
6.43 -sure
6.44 +<pre>cd WebStack-0.9<br />python setup.py install</pre>
6.45 +
6.46 +<p>If you don't want to install WebStack in this way, or if you can't do so
6.47 +because you don't have <code>root</code> privileges, you can just make sure
6.48 that the <code>WebStack-0.9</code> directory sits on the
6.49 <code>PYTHONPATH</code>.</p>
6.50 +
6.51 <h2>About WebStack Applications</h2>
6.52 <ul>
6.53 <li><a href="anatomy.html">Anatomy of a WebStack Application</a></li>
6.54 - <li><a href="deploying.html">Deploying a WebStack Application</a><br>
6.55 - </li>
6.56 + <li><a href="securing.html">Securing a WebStack Application</a></li>
6.57 + <li><a href="deploying.html">Deploying a WebStack Application</a></li>
6.58 </ul>
6.59 </body>
6.60 </html>
7.1 --- a/docs/paths-filesystem.html Fri Apr 08 22:33:56 2005 +0000
7.2 +++ b/docs/paths-filesystem.html Fri Apr 08 23:09:33 2005 +0000
7.3 @@ -1,10 +1,11 @@
7.4 -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
7.5 -<html>
7.6 +<?xml version="1.0" encoding="iso-8859-1"?>
7.7 +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
7.8 + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
7.9 +<html xmlns="http://www.w3.org/1999/xhtml">
7.10 <head>
7.11 - <meta http-equiv="Content-Type" content="text/html">
7.12 <title>Treating the Path Like a Filesystem</title>
7.13 - <meta name="generator" content="amaya 8.1a, see http://www.w3.org/Amaya/">
7.14 - <link href="styles.css" rel="stylesheet" type="text/css">
7.15 + <meta name="generator" content="amaya 8.1a, see http://www.w3.org/Amaya/" />
7.16 + <link href="styles.css" rel="stylesheet" type="text/css" />
7.17 </head>
7.18
7.19 <body>
8.1 --- a/docs/paths-opaque.html Fri Apr 08 22:33:56 2005 +0000
8.2 +++ b/docs/paths-opaque.html Fri Apr 08 23:09:33 2005 +0000
8.3 @@ -1,27 +1,25 @@
8.4 -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
8.5 +<?xml version="1.0" encoding="iso-8859-1"?>
8.6 +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
8.7 + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
8.8 <html xmlns="http://www.w3.org/1999/xhtml">
8.9 <head>
8.10 <title>Using the Path as an Opaque Reference into an Application</title>
8.11 - <meta name="generator"
8.12 - content="amaya 8.1a, see http://www.w3.org/Amaya/">
8.13 - <link xmlns:xlink="http://www.w3.org/1999/xlink" href="styles.css"
8.14 - rel="stylesheet" type="text/css">
8.15 + <meta name="generator" content="amaya 8.1a, see http://www.w3.org/Amaya/" />
8.16 + <link href="styles.css" rel="stylesheet" type="text/css" />
8.17 </head>
8.18 +
8.19 <body>
8.20 <h1>Using the Path as an Opaque Reference into an Application</h1>
8.21 +
8.22 <p>Since many Web applications have complete control over how paths are
8.23 -interpreted, the form of the path doesn't necessarily have to follow
8.24 -any
8.25 -obvious structure as far as users of your application is concerned.
8.26 -Here's an
8.27 +interpreted, the form of the path doesn't necessarily have to follow any
8.28 +obvious structure as far as users of your application is concerned. Here's an
8.29 example:</p>
8.30 <pre>/000251923572ax-0015</pre>
8.31 -<p>However, many would argue that such obscure references, whilst
8.32 -perfectly
8.33 -acceptable to machines, would make any application counter-intuitive
8.34 -and very
8.35 -difficult to reference. Sometimes, application developers do not want
8.36 -people
8.37 +
8.38 +<p>However, many would argue that such obscure references, whilst perfectly
8.39 +acceptable to machines, would make any application counter-intuitive and very
8.40 +difficult to reference. Sometimes, application developers do not want people
8.41 "bookmarking" resources or functions within an application, and so such
8.42 concerns don't matter to them.</p>
8.43 </body>
9.1 --- a/docs/paths-services.html Fri Apr 08 22:33:56 2005 +0000
9.2 +++ b/docs/paths-services.html Fri Apr 08 23:09:33 2005 +0000
9.3 @@ -1,25 +1,27 @@
9.4 -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
9.5 +<?xml version="1.0" encoding="iso-8859-1"?>
9.6 +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
9.7 + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
9.8 <html xmlns="http://www.w3.org/1999/xhtml">
9.9 <head>
9.10 <title>Treating the Path Mostly Like a Filesystem</title>
9.11 - <meta name="generator"
9.12 - content="amaya 8.1a, see http://www.w3.org/Amaya/">
9.13 - <link xmlns:xlink="http://www.w3.org/1999/xlink" href="styles.css"
9.14 - rel="stylesheet" type="text/css">
9.15 + <meta name="generator" content="amaya 8.1a, see http://www.w3.org/Amaya/" />
9.16 + <link href="styles.css" rel="stylesheet" type="text/css" />
9.17 </head>
9.18 +
9.19 <body>
9.20 <h1>Treating the Path Mostly Like a Filesystem</h1>
9.21 +
9.22 <p>...but really using it to broadly identify different resources or
9.23 services. In this approach, we take a path like this...</p>
9.24 <pre>/tools/viewer</pre>
9.25 +
9.26 <p>...and interpret it as being a request for a certain function of the
9.27 -application. Often, this approach is used because it matches some
9.28 -aspect of
9.29 +application. Often, this approach is used because it matches some aspect of
9.30 how the application is actually organised. Consider this example:</p>
9.31 <pre>/cgi-bin/script.pl</pre>
9.32 +
9.33 <p>This kind of thing generally appears in URLs because of the way the
9.34 -application concerned has been deployed - CGI programs live in a
9.35 -particular
9.36 +application concerned has been deployed - CGI programs live in a particular
9.37 place and are accessed using a special path "prefix".</p>
9.38 </body>
9.39 </html>
10.1 --- a/docs/paths.html Fri Apr 08 22:33:56 2005 +0000
10.2 +++ b/docs/paths.html Fri Apr 08 23:09:33 2005 +0000
10.3 @@ -1,10 +1,11 @@
10.4 -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
10.5 -<html>
10.6 +<?xml version="1.0" encoding="iso-8859-1"?>
10.7 +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
10.8 + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
10.9 +<html xmlns="http://www.w3.org/1999/xhtml">
10.10 <head>
10.11 - <meta http-equiv="Content-Type" content="text/html">
10.12 <title>URLs and Paths</title>
10.13 - <meta name="generator" content="amaya 8.1a, see http://www.w3.org/Amaya/">
10.14 - <link href="styles.css" rel="stylesheet" type="text/css">
10.15 + <meta name="generator" content="amaya 8.1a, see http://www.w3.org/Amaya/" />
10.16 + <link href="styles.css" rel="stylesheet" type="text/css" />
10.17 </head>
10.18
10.19 <body>
10.20 @@ -37,7 +38,7 @@
10.21 concentrate on the path because the address doesn't usually tell you anything
10.22 you don't already know. What you need to do is to interpret the path
10.23 specified in the request in order to work out which resource or service the
10.24 -request is destined for.<br>
10.25 +request is destined for.<br />
10.26 </p>
10.27
10.28 <div class="WebStack">
10.29 @@ -60,7 +61,7 @@
10.30 One thing to be aware of in the code of an application is which part of a
10.31 path refers to the location of the application in a server environment and
10.32 which refers to some resource within the application itself. Consider this
10.33 -path:<br>
10.34 +path:<br />
10.35
10.36 <pre>/folder/application/resource</pre>
10.37 Let us say that the application was deployed in a Zope server instance inside
10.38 @@ -86,8 +87,7 @@
10.39 </dl>
10.40 </div>
10.41
10.42 -<h2>Approaches to Path Interpretation<br>
10.43 -</h2>
10.44 +<h2>Approaches to Path Interpretation</h2>
10.45
10.46 <p>There are various differing approaches to the problem of interpreting
10.47 paths to resources within Web applications, but these can mostly be divided
10.48 @@ -116,5 +116,53 @@
10.49 </tr>
10.50 </tbody>
10.51 </table>
10.52 +
10.53 +<h2>Path Info Support in Server Environments</h2>
10.54 +
10.55 +<p>The following table summarises the support for paths within applications
10.56 +amongst the supported server environments or frameworks within WebStack:</p>
10.57 +
10.58 +<table border="1" cellspacing="0" cellpadding="5">
10.59 + <tbody>
10.60 + <tr>
10.61 + <th>Framework</th>
10.62 + <th>Behaviour/Level of Support</th>
10.63 + </tr>
10.64 + <tr>
10.65 + <td>BaseHTTPRequestHandler</td>
10.66 + <td>Same as path (correct)</td>
10.67 + </tr>
10.68 + <tr>
10.69 + <td>CGI</td>
10.70 + <td>Path beyond resource (correct)</td>
10.71 + </tr>
10.72 + <tr>
10.73 + <td>Java Servlet API</td>
10.74 + <td>Path beyond context (correct)</td>
10.75 + </tr>
10.76 + <tr>
10.77 + <td>mod_python</td>
10.78 + <td>Path beyond resource (correct)</td>
10.79 + </tr>
10.80 + <tr>
10.81 + <td>Twisted</td>
10.82 + <td>Same as path (correct)</td>
10.83 + </tr>
10.84 + <tr>
10.85 + <td>Webware</td>
10.86 + <td><= 0.8.1: Not supported (needs <code>ExtraPathInfo</code>
10.87 + support)<br />
10.88 + > 0.8.1: Path beyond context (correct)</td>
10.89 + </tr>
10.90 + <tr>
10.91 + <td>WSGI</td>
10.92 + <td>Path beyond resource (correct)</td>
10.93 + </tr>
10.94 + <tr>
10.95 + <td>Zope</td>
10.96 + <td>Path beyond resource (correct)</td>
10.97 + </tr>
10.98 + </tbody>
10.99 +</table>
10.100 </body>
10.101 </html>
11.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000
11.2 +++ b/docs/securing.html Fri Apr 08 23:09:33 2005 +0000
11.3 @@ -0,0 +1,101 @@
11.4 +<?xml version="1.0" encoding="iso-8859-1"?>
11.5 +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
11.6 + "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
11.7 +<html xmlns="http://www.w3.org/1999/xhtml">
11.8 +<head>
11.9 + <title>Securing a WebStack Application</title>
11.10 + <meta name="generator" content="amaya 8.1a, see http://www.w3.org/Amaya/" />
11.11 + <link href="styles.css" rel="stylesheet" type="text/css" />
11.12 +</head>
11.13 +
11.14 +<body>
11.15 +<h1>Securing a WebStack Application</h1>
11.16 +
11.17 +<p>Making sure that Web applications are "secure" involves many different
11.18 +aspects of application design, deployment and administration. This document
11.19 +covers only the usage of the authentication features of the WebStack API.</p>
11.20 +
11.21 +<h2>Authentication in WebStack</h2>
11.22 +
11.23 +<p>There are two principal methods of introducing authentication and applying
11.24 +access control to WebStack applications:</p>
11.25 +<ul>
11.26 + <li>Use of authenticators, where the "remote user" is set in the
11.27 + server/framework environment and tested in the application.</li>
11.28 + <li>Use of the <code>WebStack.Resources.LoginRedirect</code> and
11.29 + <code>WebStack.Resources.Login</code> modules.</li>
11.30 +</ul>
11.31 +
11.32 +<h3>Application-Wide Authenticators</h3>
11.33 +
11.34 +<p>First, set up the usage of such authentication mechanisms in the
11.35 +server/framework environment. For example, introduce <code>Auth</code>
11.36 +directives in your Apache configuration (see
11.37 +<code>docs/ModPython/NOTES.txt</code>) or protected folders in your Zope
11.38 +instance (see <code>docs/Zope/NOTES.txt</code>).</p>
11.39 +
11.40 +<p>Then, define an authenticator when deploying your application; this
11.41 +authenticator will respond with a decision when prompted by the server or
11.42 +underlying framework, either allowing or denying access for the user whose
11.43 +identity has been presented to the server/framework.</p>
11.44 +
11.45 +<p>In this mechanism, authenticators rely on authentication information from
11.46 +the server/framework and have a "global" effect on access to the
11.47 +application.</p>
11.48 +
11.49 +<h3>LoginRedirect and Login Modules</h3>
11.50 +
11.51 +<p>The <code>LoginRedirect</code> and <code>Login</code> modules provide a
11.52 +"single sign-on" environment for WebStack applications. Unlike the
11.53 +authenticator-only approach, each application or part of an application
11.54 +utilising this mechanism must be wrapped inside a
11.55 +<code>LoginRedirectResource</code> object which determines whether a given
11.56 +transaction contains information identifying the application's user.</p>
11.57 +
11.58 +<p>Should sufficient information be present in the transaction, the user is
11.59 +allowed to access the application and is identified in the normal way (ie.
11.60 +the <code>get_user</code> method on the transaction object). Otherwise, a
11.61 +redirect occurs to a login screen provided by a <code>LoginResource</code>
11.62 +object which then presents a login form to be completed by the user.</p>
11.63 +
11.64 +<p>The <code>LoginResource</code> object verifies the identity of the user,
11.65 +testing the supplied credentials against the credentials database specified
11.66 +in the deployment of the resource. Upon successful authentication, the user
11.67 +is redirected back to the application, which should let the user gain
11.68 +access.</p>
11.69 +
11.70 +<p>Some server/framework environments do not permit automatic redirection
11.71 +back to the application, notably Apache/mod_python. In such cases, a success
11.72 +screen is presented to the user with a link to the application they were
11.73 +attempting to access.</p>
11.74 +
11.75 +<p>In this mechanism, authenticators are employed, but only to verify the
11.76 +credentials of users when <code>LoginResource</code> or
11.77 +<code>LoginRedirectResource</code> objects are accessed.</p>
11.78 +
11.79 +<h3>Anonymous Access</h3>
11.80 +
11.81 +<p>With application-wide authenticators, anonymous access to resources and
11.82 +applications can be difficult to permit alongside access by specific users,
11.83 +mostly because servers and frameworks which employ HTTP authentication
11.84 +schemes do so globally for a given application.</p>
11.85 +
11.86 +<p>With the <code>LoginRedirect</code> and <code>Login</code> modules, it is
11.87 +possible to declare a particular request parameter which must be present in
11.88 +the URL used to access a particular application for the client to be given
11.89 +anonymous access. Consequently, anonymous users are then identified specially
11.90 +with a special username that can also be configured.</p>
11.91 +
11.92 +<h3>Logout Functions</h3>
11.93 +
11.94 +<p>With application-wide authenticators, a logout function may not be
11.95 +available if the server/framework has been configured to use HTTP
11.96 +authentication schemes, since no such function is defined for such
11.97 +schemes.</p>
11.98 +
11.99 +<p>With the <code>LoginRedirect</code> and <code>Login</code> modules, it is
11.100 +possible to declare a particular request parameter which must be present in
11.101 +the URL used to access a particular application for the client to be logged
11.102 +out. A special logout confirmation URL may also be configured.</p>
11.103 +</body>
11.104 +</html>