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 - -
Description: - - - -export-handler url handler &key (match :prefix) (method t) (stage -:response) -export-handler-list url handlers &key (match :prefix) (method t) (stage :response) - -url - a URL object - -Those response stages in full: - -1) :authentication - who does the user say he is? Is he correct? -2) :authorization - is the user allowed to see this resource? -3) :response - send the resource back or do whever else is appropriate - at this stage for the request method -4) :log - do anything else that can be done after the stream to the - browser window is closed - -n) :error - if a Lisp ERROR is thrown during any of the preceding, run - 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. - -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? - - rmfile ./doc/exports.txt }