Of course, it's not quite as simple as this because we don't actually know what a given users preference exclusions are at the time of writing the code. We've therefore got to retrieve that information from their authentication record, be it a lease or a permanent address-based authentication. In earlier chapters we encountered the conf_get_attr function that can be used to get answers from the configuration file. There is an almost identical mechanism for getting access to the authentication file called auth_get_attr.

To make use of the auth_get_attr function, we need to provide it with a key with which to look up the authentication record we want. At present we're keying this on the IP version 4 address of the client computer to which we're talking although additional methods are due to be added in time. When running under the Apache 2 web server, we are provided with the address of the client computer via an environment variable called REMOTE_ADDR. We pass this to the auth_get_attr function with the prefix "ipv4-" to indicate the type of address we're passing. The object we need to request from the authentication record is called prefexcl.

Assuming that our client machine is has the IP Version 4 address of 192.168.1.136 we'd therefore effectively pass the request to auth_get_conf as:

$exclusions = auth_get_conf( "ipv4-192.168.1.136", "prefexcl" );

Of course in fact we're not going to hard code the IP address into our Perl or PHP script, so the actual code we write will look more like this in perl:

$exclusions = auth_get_conf( "ipv4-".$ENV{"REMOTE_ADDR"}, "prefexcl" );

and in PHP it'll look like this:

$exclusions = $wacs->auth_get_attr( "ipv4-".$_SERVER['REMOTE_ADDR'],
		"prefexcl");

Once we've excuted this function call, the variable exclusions will contain something like "L,B" - the more observant amongst you will realise that while being what we need to know, it's not yet phrased in a way that SQL will accept as a list to be passed to an in() clause. We need to quote each of the values independantly and separate them by commas.

Now that we have the preference exclusions list for our current user, we need to translate this into a form that SQL will accept as a query condition. The following code segment in perl does this for you:

$exclusions =~ s/\s//g;   # remove excess spaces
$exclusions =~ s/,/','/g; # quote them
$sqlquery .= "and (scatflag not in ('".$exclusions."') or ".
	          "scatflag is null) ";

You will see that we're here appending to a variable called sqlquery which is assumed to already contain the necessary select, from and where clauses for the search we wish to carry out. The same basic code implemented in PHP will look like:

$exclusions = preg_replace( '/\s/','', $exclusions );
$exclusions = preg_replace( '/,/',"','", $exclusions );
$sqlquery .= "and (scatflag not in ('".$exclusions."') or ".
	          "scatflag is null) ";

	Note
	One optimisation you can, probably should make, is to do this at the start of your program if you're going to write multiple database queries and place it in a global variable. The answer to the authentication file query is going to be unchanged for the time that this program will be drawing it's web page or whatever it does.

There are of course occasions when you don't want to make use of the preference exclusions mechanism, in particular when you're handling saved searches where you assume that if the set is included within the results returned that that is what the user desires. It's also generally a good idea to indicate somewhere on the page you generate that preference exclusions have been applied when displaying this particular group of sets. While the user can change their preference exclusions at any time, it's unlikely to be that prominent that all of them will realise how to do so immediately.