aboutsummaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorgoodale <goodale@1faa4e14-9dd3-4be0-9f0e-ffe519881164>2000-09-15 12:45:27 +0000
committergoodale <goodale@1faa4e14-9dd3-4be0-9f0e-ffe519881164>2000-09-15 12:45:27 +0000
commit9ca8518895939d3ae82c937bed7f2b545a9f9e39 (patch)
tree6a4f12a4f4c472bffac1dbffb2b5a877bf2c0beb /doc
parent3c4f4b1e6a1de4d6e16a70af4d11fc11ddb11da9 (diff)
Made parallel aware.
Added stuff for parameter steering. See doc/Steering.txt. Added stuff for HTTP Basic authentication. See doc/Auth.txt. Tom git-svn-id: http://svn.cactuscode.org/arrangements/CactusConnect/HTTPD/trunk@9 1faa4e14-9dd3-4be0-9f0e-ffe519881164
Diffstat (limited to 'doc')
-rw-r--r--doc/Auth.txt104
-rw-r--r--doc/Steering.txt30
2 files changed, 134 insertions, 0 deletions
diff --git a/doc/Auth.txt b/doc/Auth.txt
new file mode 100644
index 0000000..9587b4f
--- /dev/null
+++ b/doc/Auth.txt
@@ -0,0 +1,104 @@
+ /*@@
+ @file Auth.txt
+ @date Fri Sep 15 14:05:49 2000
+ @author Tom Goodale
+ @desc
+ Description of http authentication interface interface.
+ @enddesc
+ @version $Header$
+ @@*/
+
+There is an HTTP authentication interface, which is accessed by
+including http_Auth.h.
+
+This provides two functions:
+
+int HTTP_AuthAddUser(const char *database,
+ const char *name,
+ const char *password,
+ const char *encryption_scheme);
+
+which allows databases of users and passwords to be created.
+
+The encryption scheme says how the password which is being passed in
+is encrypted. Currently supported schemes are 'none' for plaintext,
+or 'crypt' for a password encrypted using crypt(3), such as is produced
+by the unix passwd command, plus many other tools. The use of
+crypt(3) relies on Cactus determining that the function exists. Other
+encryption systems are easily added.
+
+This allows the password stored in parameter files or displayed on a
+web page to be encrypted.
+
+The other function is
+
+int HTTP_AuthenticateBasic(httpRequest *request,
+ const char *database);
+
+which takes an HTTP request, and a password database, and sees if the
+'Authorization' header field declares a user and password which are in
+the database. This function supports the 'Basic' authentication
+scheme supplied by HTTP/1.0.
+
+This function has three possible return codes.
+
++1 - the Authorization header was missing.
+0 - header there. User and password match.
+-1 - header there. User and password don't match.
+
+Usage:
+------
+
+Create a set of users and password in a database, e.g.
+
+ HTTP_AuthAddUser("developers","goodale","foo","none");
+
+which declares a database called 'developers' and adds a user
+'goodale; with password 'foo' which is plaintext. An equivalent
+declaration would have been
+
+HTTP_AuthAddUser("developers","goodale","fSzQC4Ssz0ab.","crypt");
+
+if the configuration supports crypt(3) passwords.
+
+Then when a page comes in, one does
+
+ notauthorised = HTTP_AuthenticateBasic(request, "users");
+
+ if(!notauthorised)
+ {
+ /* Access allowed */
+ strcpy(message,"HTTP/1.0 200 Ok\r\n");
+
+ write(request->filedes, message, strlen(message));
+
+ strcpy(message,"WWW-Authenticate: Basic realm=\"foo\"\r\n");
+
+ write(request->filedes, message, strlen(message));
+
+ strcpy(message,"Content-Type: text/html\r\n\r\n");
+
+ write(request->filedes, message, strlen(message));
+
+ ...
+ }
+ else
+ {
+ /* Access not allowed. */
+ strcpy(message,"HTTP/1.0 401 Unauthorized\r\n");
+
+ write(request->filedes, message, strlen(message));
+
+ strcpy(message,"WWW-Authenticate: Basic realm=\"foo\"\r\n");
+
+ write(request->filedes, message, strlen(message));
+
+ strcpy(message,"Content-Type: text/html\r\n\r\n");
+
+ write(request->filedes, message, strlen(message));
+
+ ...
+ }
+
+ Additionally you could check whether 'notauthorised' = +1 or -1 and
+in the latter case log some message about a failed access request.
diff --git a/doc/Steering.txt b/doc/Steering.txt
new file mode 100644
index 0000000..26053ec
--- /dev/null
+++ b/doc/Steering.txt
@@ -0,0 +1,30 @@
+ /*@@
+ @file Steering.txt
+ @date Fri Sep 15 14:05:49 2000
+ @author Tom Goodale
+ @desc
+ Description of parameter steering interface.
+ @enddesc
+ @version $Header$
+ @@*/
+
+There is a parameter steering interface, which is accessed by
+including http_Steer.h.
+
+This defines two functions:
+
+
+int HTTP_SteerQueue(const char *thorn,
+ const char *parameter,
+ const char *value);
+
+which schedules a parameter to be steered, and
+
+int HTTP_SteerDispatch(void);
+
+which broadcasts the data to other processors and then
+steers all the parameters which were queued.
+
+This is to allow steering requests to be queued up over several
+iterations, and then broadcast at once, which should reduce the
+number of barriers called by the code.