When using EZproxy with server-based, co-browsing, virtual reference system, it may be desirable or necessary to change the login process used by EZproxy.
For example, assume your existing user.txt file looks like this:
cgiuser:cgipass:cgi=http://auth.yourlib.org/cgi-bin/ezproxy.cgi?
but that your CGI script is somehow incompatible with your virtual reference server. Also assume that your virtual reference server connects from IP addresses between 192.168.1.15 and 192.168.1.20. You might alter your user.txt file to look like this:
virtref:secret:ip=192.168.1.15-192.168.1.20,login=vr.htm cgiuser:cgipass:cgi=http://auth.yourlib.org/cgi-bin/ezproxy.cgi?
This new line states that if EZproxy receives a request from a computer at an IP address between 192.168.1.15 and 192.168.1.20, then the login process should look in EZproxy's docs subdirectory for a file named vr.htm and send it as the login form. The use of login=vr.htm also indicates that EZproxy should ignore processing the rest of user.txt, which prevents the second line from ever redirecting users to your CGI login process.
To create your vr.htm file, go to your docs subdirectory and copy the login.htm file to vr.htm, then edit the vr.htm file with your favorite HTML editor.
The presence of virtref:secret: makes the username virtref with the password secret valid for requests that come from the virtual reference server, so this is the information that will need to be entered in the login page when this page appears during the virtual reference process.
The practical result of this line is the appearance of the vr.htm login page when the co-browsing server is used to access EZproxy, the complete avoidance of any normal login process, and the authorization of the a special username and password that is only valid from co-browsing sessions.
Please note that the sequence of lines in user.txt is crucial. If you reversed the entries to:
cgiuser:cgipass:cgi=http://auth.yourlib.org/cgi-bin/ezproxy.cgi? virtref:secret:ip=192.168.1.15-192.168.1.20,login=vr.htm
the first line would result in all incoming entries being redirected to your CGI process, effectively disabling the second line from having any impact at all.