Client Side Redirection Applet
From EZProxyWiki
- Submitted: May 4, 2001
- Title: Client-Side Redirection Java Documentation
- Submitted by: Stephen Matich
Contents |
Overview
The CSR was intended to be useful for providing access to web resources from multiple similar urls on a web page, with the idea that users would not have to be aware of where they are connecting from and decide which link to follow based on that knowledge. The applet will decide on the particular url for them so there is just one button or image instead of several. The applet class files are about 8k in size and from limited testing the applet works with the default browser settings on Netscape 3 (Mac), 4.5 (NT4), IE 4 (NT4), 5 (NT4) and 5.5 (NT4). It has not been tested on any other browsers or using the java plug-in. The author Stephen Matich is interested to hear of others' experiences using the applet with other java-browser combinations/environments, and whether you find the applet useful.
The applet was originally developed to complement the University of Waikato Library's use of EZproxy, although at the time of writing it is uncertain whether it will actually be used. However, it may be useful for organisations that have multiple instances of ezproxy and/or for situations in which is desirable to not to send all traffic to a particular url via a single instance of ezproxy. In that case the applet determines which ezproxy instance to use (or whether or not to use one) based on the IP address of the client.
A brief discussion of some 'features' of this applet are presented in the hope that it might assist in deciding if it is useful in a particular case. Firstly the applet does not enforce access via a particular path to a given url, it merely automatically facilitates it where supported. Secondly, it is possible to determine the client IP address using a server based application and to send the client a suitable redirect url based on this. A server based method may produce different results to the applet in cases where the client connects from behind a web proxy or NAT router/firewall. This is because in the server based case the IP address of the client appears to the server to be that of the intermediary, whereas the applet determines the client IP address at the client, which may or may not be desirable. Additionally, as far as a web server is concerned java classes are passive content in the same way that html/images are, an applet also does not require any extra processing or special configuration on the web server, and it doesn't have the potential to compromise the security of the web server for example, in the way a cgi does.
How it works
When initialising, the applet determines the IP address of the client and reads in a number of parameters. For configuration purposes, there are three different types of parameters. These include 1) a single parameter to the configure the applet's gui, 2) a list of parameters that comprise url prefixes, and 3) a list of parameters that are comprised of sets of redirection options. Each redirection option comprises a set of parameters distinguished from other sets by a different number suffix in the parameter name. Within each set the number suffix is common, but the base parameter name will correspond to one of each of the following: an IP address, a subnet mask, a url, and a number corresponding to a prefix parameter name. Each prefix parameter is comprised of a url (such as the url of an ezproxy instance) and the different values are distinguished by a number suffix in the parameter name. The number of url prefixes and redirection parameter sets is not limited by the applet. The applet selects the redirection url from the parameter set whose subnet best matches the client IP. If specified in the redirection parameter set, the applet will also prepend one of the prefix parameter urls to the url of the selected redirection set. When the applet's single gui object (button or image) is clicked, the applet sends the browser to the resulting url. More detail on the syntax of the parameters and a discussion of how they affect the operation of the applet is provided in the Parameters section below.
On the other hand if you don't have java enabled, all you will instead see are two images, and if you don't have a gui browser you will only see a couple of underlined links :(. In this case the applet is configured to send your browser to different urls depending on whether your browser IP is in the 10.0.0.0/8, 172.16.0.0/16, 192.168.0.0/16 or 0.0.0.0 networks (a different place in each instance).
Parameters
The applet is probably not very forgiving if it is misconfigured, which is probably quite easy to do, and you should test it thoroughly before unleashing it on your unsuspecting victims. To see an example of how to properly configure it look at the applet tags in the source of this page. The parameters used to configure the applet can be grouped into three types:
- GUI configuration: a single parameter; the NAME is either IMAGEFILE or BUTTONLABEL. If NAME="BUTTONLABEL" then the applets gui is a button. If NAME="IMAGEFILE" then the gui is a clickable image. The VALUE of the BUTTONLABEL parameter is a string that will be used to label the applets button, and the VALUE of the IMAGEFILE parameter is a string corresponding to a path on the web server for the image to be displayed. Note the WIDTH and HEIGHT parameters in the APPLET tag are required for applets. These set the size of the gui object displayed by the applet, and if the image used is larger or smaller than the applet size the image will be cropped or displayed in the top left hand corner of a larger box respectively.
- URL prefixes: any number of individual prefixes may be specified, each as a seperate parameter. Each parameter is of the form URLPREF#, where # is a positive integer. The only requirement on this list is that each prefix is numbered to form a continuous sequence starting at 1. ie URLPREF1, URLPREF2, URLPREF3 etc... (if the next prefix in this series was URLPREF99, it would be ignored). The VALUE of each parameter is a url. It may be relative or absolute. The third type of parameter that the applet reads will include a parameter whose VALUE may be equal to one of the numbered URLPREFIX# entries, if none of them are referred to then no URLPREF# parameters need be present.
- Redirection set: A set consists of four seperate parameters. The four names of the parameters are IPADDR#, IPMASK#, URL#, USEPREF#, where # is any positive integer starting at 1, but is the same for the four parameters in a set. As with the URLPREFIX parameters, there is no limit on the number of sets, except that they must form a continuous sequence. IPADDR# and IPMASK# are dotted decimal IP octets. The subnetting implementation of this applet should support any subnet mask between 0 and 32 bits wide. For a discussion of how IP subnetting works you will have to look elsewhere, suffice to say that the IPADDR# and IPMASK# parameters are logically and'ed to define a network or IP range. The client IP address may or may not fall within the defined IP range. For explaination purposes, I call the situation where the client IP does lie within the IP range defined by IPADDR# and IPMASK# a 'match'. The way this applet is written, the fewer the number of IP addresses in the range defined by IPADDR# and IPMASK#, the better the match can be. This applet chooses the best match, ie the redirection set that matches the client IP address and that also defines the narrowest range of IP addresses of all the matching redirection sets. Note that the catch-all IPMASK#, 0.0.0.0 includes all IP addresses and will therefore match for every client, and this case will always be the worst case match. A redirection set should be present for this case, unless the other redirection sets listed define the *only* IP ranges that will ever visit your site because this includes everyone else on the internet. The URL# parameter is a string that specifies the url to be used for clients that match this case, it may be relative or absolute. The USEPREF# parameter is the string version of positive integer, the value of which corresponds to the # of a URLPREF# parameter. As an example of how the applet selects the best match consider the case where the client ipaddress is 192.168.1.1 and there are two redirection options. If the first redirection option has IPADDR1=192.168.1.0 and IPMASK1=255.255.255.0 and the second has IPADDR2=192.168.1.0 and IPMASK2=255.255.0.0. Both redirection options will match, but the first defines a 255 host IP range, and the second defines a 65535 host IP range, therefore the first redirection set is the best match.
Getting the applet
The zip file linked below contains the source code and the compiled class files. Please note that the University of Waikato owns the copyright but has made the source available subject to terms of the GNU general public licence. It is a bit of a hack to say the least. You have been warned. Click here to download.
