test

Sun Java System Web Server 7.0 NSAPI Developer's Guide

Chapter 3 Examples of Custom SAFs and Filters

This chapter provides examples of custom Sever Application Functions (SAFs) and filters for each directive in the request-response process. You may wish to use these examples as the basis for implementing your own custom SAFs and filters. For more information about creating your own custom SAFs, see Chapter 1, Creating Custom Server Application Functions and for information about creating your own filters, see Chapter 2, Creating Custom Filters.

Before writing custom SAFs, you should be familiar with the request-response process and the role of the configuration file obj.conf. See the Sun Java System Web Server 7.0 Administrator’s Configuration File Reference for information on the obj.conf file.

Before writing your own SAF, check to see if an existing SAF serves your purpose. The predefined SAFs are discussed in the Sun Java System Web Server 7.0 Administrator’s Configuration File Reference.

For a list of the NSAPI functions for creating new SAFs, see Chapter 5, NSAPI Function and Macro Reference.

This chapter has the following sections:

Examples Bundled With the Server

The install_dir/samples/nsapi directory contains examples of source code for SAFs.

You can use the example.mak (Windows) or Makefile (UNIX) makefile in the same directory to compile the examples and create shared libraries containing the functions in all of the example files.

To test an example, load the examples shared library into the server by adding the following directive in the Init section of magnus.conf:


Init fn=load-modules 
     shlib=examples.so/dll
     funcs=function1,...,functionN

The shlib parameter specifies the path to the shared library (for example, ../../samples/nsapi/examples.so), and the funcs parameter specifies the functions to load from the shared library.

If the example uses an initialization function, be sure to specify the initialization function in the funcs argument to load-modules, and also add an Init directive to call the initialization function.

For example, the PathCheck example implements the restrict-by-acf function, which is initialized by the acf-init function. The following directive loads both these functions:

Init fn=load-modules
     shlib="path"  
     funcs=acf-init,restrict-by-acf

The following directive calls the acf-init function during server initialization:

Init fn=acf-init file=extra-arg

To invoke the new SAF at the appropriate step in the response handling process, add an appropriate directive in the object to which it applies, for example:

PathCheck fn=restrict-by-acf

After adding new Init directives to magnus.conf, you always need to restart the Web Server to load the changes, since Init directives are only applied during server initialization.

AuthTrans Example

This simple example of an AuthTrans function demonstrates how to use your own custom ways of verifying the user name and password that a remote client provided is accurate. This program uses a hard-coded table of user names and passwords and checks a given user's password against the one in the static data array. The userdb parameter is not used in this function.

AuthTrans directives work in conjunction with PathCheck directives. Generally, an AuthTrans function checks if the user name and password associated with the request are acceptable, but it does not allow or deny access to the request; it leaves that to a PathCheck function.

AuthTrans functions get the user name and password from the headers associated with the request. When a client initially makes a request, the user name and password are unknown so the AuthTrans function and PathCheck function work together to reject the request, since they can’t validate the user name and password. When the client receives the rejection, the usual response is for it to present a dialog box asking the user for their user name and password, and then the client submits the request again, this time including the user name and password in the headers.

In this example, the hardcoded-auth function, which is invoked during the AuthTrans step, checks if the user name and password correspond to an entry in the hard-coded table of users and passwords.

Installing the AuthTrans Example

To install the function on the Web Server, add the following Init directive to magnus.conf to load the compiled function:

Init fn=load-modules 
     shlib="path" 
     funcs=hardcoded-auth

Inside the default object in obj.conf, add the following AuthTrans directive:


AuthTrans fn=basic-auth 
          auth-type="basic" 
          userfn=hardcoded-auth
          userdb=unused

Note that this function does not actually enforce authorization requirements, it only takes given information and tells the server if it is correct or not. The PathCheck function require-auth performs the enforcement, so add the following PathCheck directive as well:

PathCheck fn=require-auth 
          realm="test realm" 
          auth-type="basic"

The source code for this example is in the auth.c file in the install_dir/samples/nsapi/directory.

NameTrans Example

The ntrans.c file in the samples/nsapi subdirectory of the server root directory contains source code for two example NameTrans functions:

Note –

A NameTrans function is used primarily to convert the logical URL in ppath in rq->vars to a physical path name. However, the example discussed here, explicit_pathinfo, does not translate the URL into a physical path name; it changes the value of the requested URL. See the second example, https_redirect, in ntrans.c for an example of a NameTrans function that converts the value of ppath in rq->vars from a URL to a physical path name.

The explicit_pathinfo example allows URLs to explicitly include extra path information for use by a CGI program. The extra path information is delimited from the main URL by a specified separator, such as a comma.

For example:

http://server-name/cgi/marketing,/jan/releases/hardware

In this case, the URL of the requested resource (which would be a CGI program) is http://server-name/cgi/marketing, and the extra path information to give to the CGI program is /jan/releases/hardware.

When choosing a separator, be sure to pick a character that is never used as part of the real URL.

The explicit_pathinfo function reads the URL, strips out everything following the comma, and puts it in the path-info field of the vars field in the request object (rq->vars). CGI programs can access this information through the PATH_INFO environment variable.

One side effect of explicit_pathinfo is that the SCRIPT_NAME CGI environment variable has the separator character tacked onto the end.

NameTrans directives usually return REQ_PROCEED when they change the path, so that the server does not process any more NameTrans directives. However, in this case we want name translation to continue after we have extracted the path info, since we have not yet translated the URL to a physical path name.

Installing the NameTrans Example

To install the function on the Web Server, add the following Init directive to magnus.conf to load the compiled function:

Init fn=load-modules 
     shlib="path" 
     funcs=explicit-pathinfo

Inside the default object in obj.conf, add the following NameTrans directive:

NameTrans fn=explicit-pathinfo 
          separator=","

This NameTrans directive should appear before other NameTrans directives in the default object.

The source code for this example is in the ntrans.c file in the install_dir/smaples/nsapi/directory.

PathCheck Example

The example in this section demonstrates how to implement a custom SAF for performing path checks. This example simply checks if the requesting host is on a list of allowed hosts.

The Init function acf-init loads a file containing a list of allowable IP addresses with one IP address per line. The PathCheck function restrict_by_acf gets the IP address of the host that is making the request and checks if it is on the list. If the host is on the list, it is allowed access; otherwise, access is denied.

For simplicity, the stdio library is used to scan the IP addresses from the file.

Installing the PathCheck Example

To load the shared object containing your functions, add the following line in the Init section of the magnus.conf file:

Init fn=load-modules 
     shlib="path"
     funcs=acf-init, restrict-by-acf

To call acf-init to read the list of allowable hosts, add the following line to the Init section in magnus.conf. (This line must come after the one that loads the library containing acf-init).

Init fn=acf-init 
     file=fileContainingHostsList

To execute your custom SAF during the request-response process for some object, add the following line to that object in the obj.conf file:

PathCheck fn=restrict-by-acf

The source code for this example is in pcheck.c in the install_dir/samples/nsapi/directory.

ObjectType Example

The example in this section demonstrates how to implement html2shtml, a custom SAF that instructs the server to treat a .html file as a .shtml file if a .shtml version of the requested file exists.

A well-behaved ObjectType function checks if the content type is already set, and if so, does nothing except return REQ_NOACTION.


if(pblock_findval("content-type", rq->srvhdrs))
    return REQ_NOACTION;

The primary task an ObjectType directive needs to perform is to set the content type (if it is not already set). This example sets it to magnus-internal/parsed-html in the following lines:


/* Set the content-type to magnus-internal/parsed-html */
pblock_nvinsert("content-type", "magnus-internal/parsed-html",
                rq->srvhdrs);

The html2shtml function looks at the requested file name. If it ends with .html, the function looks for a file with the same base name, but with the extension .shtml instead. If it finds one, it uses that path and informs the server that the file is parsed HTML instead of regular HTML. Note that this requires an extra stat call for every HTML file accessed.

Installing the ObjectType Example

To load the shared object containing your function, add the following line in the Init section of the magnus.conf file:

Init fn=load-modules
     shlib="path" 
     funcs=html2shtml

To execute the custom SAF during the request-response process for some object, add the following line to that object in the obj.conf file:

ObjectType fn=html2shtml

The source code for this example is in otype.c in the install_dir/samples/nsapi/ directory.

Output Example

This section describes an example NSAPI filter named example-replace, which examines outgoing data and substitutes one string for another. It shows how you can create a filter that intercepts and modifies outgoing data.

Installing the Output Example

To load the filter, add the following line in the Init section of the magnus.conf file:


Init fn="load-modules" 
     shlib=yourlibrary
     NativeThread="no"

To execute the filter during the request-response process for some object, add the following line to that object in the obj.conf file:


Output fn="insert-filter" 
       type="text/*" 
       filter="example-replace" 
       from="iPlanet" to="Sun ONE"

The source code for this example is in the replace.c file in the install_dir/samples/nsapi/ directory.

Service Example

This section discusses a very simple Service function called simple_service. All this function does is send a message in response to a client request. The message is initialized by the init_simple_service function during server initialization.

For a more complex example, see the file service.c in the examples directory, which is discussed in More Complex Service Example.

Installing the Service Example

To load the shared object containing your functions, add the following line in the Init section of the magnus.conf file:


Init fn=load-modules 
     shlib=yourlibrary 
     funcs=simple-service-init,simple-service

To call the simple-service-init function to initialize the message representing the generated output, add the following line to the Init section in magnus.conf. (This line must come after the one that loads the library containing simple-service-init.)


Init fn=simple-service-init
     generated-output="<H1>Generated output msg</H1>"

To execute the custom SAF during the request-response process for some object, add the following line to that object in the obj.conf file:

Service type="text/html" 
        fn=simple-service

The type="text/html" argument indicates that this function is invoked during the Service stage only if the content-type has been set to text/html.

The source code for this example is in the service.c file in the install_dir/samples/nsapi directory.

More Complex Service Example

The send-images function is a custom SAF that replaces the doit.cgi demonstration available on the iPlanet home pages. When a file is accessed as /dir1/dir2/something.picgroup, the send-images function checks if the file is being accessed by a Mozilla/1.1 browser. If not, it sends a short error message. The file something.picgroup contains a list of lines, each of which specifies a file name followed by a content-type (for example, one.gif image/gif).

To load the shared object containing your function, add the following line at the beginning of the magnus.conf file:

Init fn=load-modules shlib=yourlibrary funcs=send-images

Also, add the following line to the mime.types file:

type=magnus-internal/picgroup exts=picgroup

To execute the custom SAF during the request-response process for some object, add the following line to that object in the obj.conf file (send-images takes an optional parameter, delay, which is not used for this example):


Service method=(GET|HEAD) type=magnus-internal/picgroup fn=send-images

The source code for this example is in the service.c file in the install_dir/samples/nsapi directory.

AddLog Example

The example in this section demonstrates how to implement brief-log, a custom SAF for logging only three items of information about a request: the IP address, the method, and the URI (for example, 198.93.95.99 GET /jocelyn/dogs/homesneeded.html).

Installing the AddLog Example

To load the shared object containing your functions, add the following line in the Init section of the magnus.conf file:

Init fn=load-modules 
     shlib=yourlibrary 
     funcs=brief-init,brief-log

To call brief-init to open the log file, add the following line to the Init section in magnus.conf. (This line must come after the one that loads the library containing brief-init.)

Init fn=brief-init 
     file=/tmp/brief.log

To execute your custom SAF during the AddLog stage for some object, add the following line to that object in the obj.conf file:

AddLog fn=brief-log

The source code for this example is in addlog.c file in the install_dir/samples/nsapi directory.

Quality of Service Example

The code for the qos-handler (AuthTrans) and qos-error (Error) SAFs is provided as an example in case you want to define your own SAFs for quality of service handling.

For more information about predefined SAFs, see the Sun Java System Web Server 7.0 Administrator’s Configuration File Reference.

Installing the Quality of Service Example

Inside the default object in obj.conf, add the following AuthTrans and Error directives:


AuthTrans fn=qos-handler
...
Error fn=qos-error code=503

The source code for this example is in the qos.c file in the samples/nsapi subdirectory of the server root directory.