Hack 91 Use IRC from a Web Page Without Java

Use IRC from any browser—even mobile devices that don't support Java!

Many reasons may stop you from using a normal IRC client—maybe you can't install one on the computer or device you're using, or maybe a firewall blocks your access to IRC. Alternatively, you may want to provide an easy way for web page visitors to get to your IRC channel.

CGI:IRC provides a nearly full featured IRC client in a web browser. It makes use of JavaScript and DHTML features if they are available. The main omissions are support for scripting, DCC chat, and file transfers, but that's not the end of the world.

You will need a web server that can run Perl CGI scripts and, more importantly, supports Unix domain sockets. This rules out Windows, but Linux, any BSD, and even Mac OS X should work fine. The web server will also need to be able to connect to IRC.

The following instructions assume you are using Apache, as it is the most common web server in use. However, CGI:IRC should work on any web server that supports CGI.

How does it work? CGI:IRC makes use of a streaming connection to the web server. This is a special HTTP request that never ends and sends data as it becomes available. This means the bandwidth usage is kept to a minimum because the page is not constantly being refreshed. This doesn't work with all browsers and proxies—two of the most common programs that currently have problems with streaming are the Novell BorderManager proxy and Apple's Safari browser. It is also possible the server will not support streaming. For example, mod_gzip on Apache will not work unless the CGI script is excluded from compression.

14.7.1 Installing CGI:IRC

Download CGI:IRC from its web site at http://cgiirc.sourceforge.net, and extract the files to somewhere convenient. The two main steps to installing CGI:IRC are setting up the configuration and uploading the files to the web server.

Two configuration files are supplied with CGI:IRC. One is limited to a single channel and server and has fewer options. The other will allow users to connect to any server and contains a greater number of options. If you want to use the full configuration file, copy cgiirc.config.full over cgiirc.config. You can also copy and paste lines from the full configuration into the smaller one to make the configuration easier to manage. The file format follows fairly standard conventions. A line beginning with a # is a comment, while other lines set various options to specific values.

The main settings to configure are the server, the channel, and where the images are stored. The default_server and default_channel options should be set to the server you want to connect to and the channel you want to join. If you want to join multiple channels, you can specify a comma-separated list of channel names.

If Apache is configured to use the ExecCGI option (so you can run CGI scripts from anywhere), the default setup will work fine with the images. However, if it is configured with ScriptAlias (where you have a separate cgi-bin directory), the images will have to be put elsewhere. The place they are put must be able to display static files, and image_path in the CGI:IRC configuration file will need to be updated to point to this location. For example, if you put the images directory at the root of a virtual host, image_path would be /images. The key thing to remember is that image_path is what is sent to the browser, so this should not contain a full local filesystem path.

Apart from the images, all the files should be uploaded into the same directory. It is recommended that you put them inside a directory called cgiirc, as this makes it easier to see which files belong to CGI:IRC. If you use a local server, you just need to move the files into the correct location rather than uploading them. How you upload the files does not matter—you can use FTP/SFTP to the server or any other method that is convenient. You should upload all of the text files in ASCII mode; otherwise, they may not run correctly on the server. Conversely, make sure you upload the images in binary mode.

Once you have uploaded the files, it is a good idea to check the permissions on the .cgi files: irc.cgi, nph-irc.cgi, and client-perl.cgi. They need to have at least read and execute permissions for user, group, and other, that is, r-xr-xr-x. If you aren't sure what the current permissions are, you can either use your FTP client to change the permissions of the files to r-xr-xr-x or log in to the web server and type the following into the shell:

% chmod 755 *.cgi

Hopefully, all the necessary files will now be on the server and have the correct permissions. If all has gone well, when you visit the location of irc.cgi (for example, http://localhost/cgi-bin/cgiirc/irc.cgi), you will see the login page shown in Figure 14-6.

Figure 14-6. The CGI:IRC login page

Once you have logged in, you'll see something similar to the screenshot in Figure 14-7. The layout is similar to most graphical IRC clients. Along the top is a list of the channels you are in, with the text color indicating the activity in the window. The buttons on the right will access the online help, open the options, and close the current window. On the right you see the user list. Double-clicking on a name will open a query to let you send private messages. The rest of the screen should be fairly obvious; the only other thing that needs explaining is the << symbol, which causes CGI:IRC to display some extra buttons to allow the input of colors and formatting characters.

Figure 14-7. CGI:IRC running in a web page

There are some limitations in CGI:IRC. Because CGI:IRC acts as a client, connections from it appear to be coming from the web server's address. This allows it to get past firewalls, but, unfortunately, if several clients are connecting from the same address, some IRC servers will refuse to accept additional connections beyond a certain limit. The other main limitation is that it is written in Perl and uses CGI, so quite a lot of memory is used per user. This isn't too much of an issue for single users using it to get past firewalls, but for a web site with lots of users, it isn't ideal.

—David Leadbeater