Syntax: + +
export-server server + +
Arguments and Values: + +
server - a SERVER object. See server-class.lisp + +
Description: + +Registers server with Araneida, so that we know how to answer +requests for it. The same registration list is also used for +output-apache-conf + +
Syntax: + +
export-handler url handler &key (match :prefix) (method +t) (stage :RESPONSE) + +
export-handler-list urls handler &key (match :prefix) (method +t) (stage :RESPONSE) + +
Arguments and Values: + +
url - a URL object. See url-class.lisp + +
handler - a function of two arguments, returning T (handled) or NIL + (try something else) + +
handlers - a list of handler functions, called in sequence until one + of them returns T + +
match - :exact - try this handler when url exactly matches that requested + :prefix - try when url is a prefix of that requested + +
method - A list of keywords corresponding to HTTP/1.0 methods + (:get :post :put :delete etc), or T meaning match all methods + +
stage - response stage to call this at - see below hunk ./doc/exports.txt 59 - -export-server server +
Description: hunk ./doc/exports.txt 61 -server - a SERVER object. See server-class.lisp hunk ./doc/exports.txt 68 -handler - a function of two arguments, returning T (handled) or NIL - (try something else) -handlers - a list of handler functions, called in sequence until one - of them returns T -match - :exact - try this handler when url exactly matches that requested - :prefix - try when url is a prefix of that requested -method - A list of some of the elements (:get :post :put :delete etc) - or T meaning match all methods -stage - response stage to call this at - see below hunk ./doc/exports.txt 72 -2) :authorization - is the user Allowed to see this resource? +2) :authorization - is the user allowed to see this resource? hunk ./doc/exports.txt 79 - this. Don't call this otherwise + this. Don't otherwise + +Producing output: + +Usually the :response stage is the one that gets to send back a +response. However, any earlier stage can send one if it wants +(usually in an atypical situation) and close the stream. If the +stream is closed, we skip directly to the :log stage when the current +stage is done. + +Authentication and authorization: + +Identities (usernames, basically) are unique per realm + +:authentication handler is responsible for checking that the supplied +credentials are correct for the given identity in the given URL space. +It will only produce a page if the credentials were not supplied or +don't match the claimed identity (and might not necessarily even then) + +:authorization handler has to check if the requested action is allowed +to the given identity when connecting from the given host name (though +note that IP-based authorization is not implemented currently - no +point as the proxy loses all the relevant information for us) + +For example + +0) To use the HTTP authentication methods, make sure that your URL +space corresponds to an HTTP realm. You need an :authentication +handler that digs for the request header's Authorization: line and +shoves a suitable user identifier into (request-user ) or hands out +the appopriate 40x error. A null :authorization handler will produce +a behaviour like the apache "require valid-user" directive, or you +could actually write a handler that checked this to confine it +further. + +1) cookie-based authentication, where the user's browser supplies a +cookie that we previously sent him. Our :authentication handler +checks the supplied cookie against our internal records, filling in +the (request-user ) slot if it matches. Our :authorization handler +just checks if (request-user ) is one of the users allowed here, and +prints a helpful error page if not. + +2) ident-based authentication - you don't want to use this for +anything serious but in a secure intranet environment it might be +appropriate. Suggested implementation route would involve getting +apache to do the actual lookup as (a) it won't block, and (b) you'll +only end up identing the apache daemon if you do it yourself anyway. + +Note + +1) that we don't care what you put in the request-user slot provided +that your :authentication and :authorization handlers both agree on +it. It could be a username, user id, CLOS object defining a user, or +whatever. hunk ./doc/exports.txt 134 +2) When IP-based access control becomes possible, it could conceivably +be used at authentication _or_ authorization stage. We might decide +for example that all requests from pc10.foo.com are from John Smith +(authenticate te request as from "John Smith") or we might decide that +all administrator requests must come from localhost - authentication +is identifying the remote user whereas authorization is checking that +he's "administrator" and connected from localhost. Clear? }