IRC Hacks [Electronic resources] نسخه متنی

Hack 91 Use IRC from a Web Page Without Java

Use IRC from any browsereven mobile
devices that don't support Java!

Many reasons may stop you from using a
normal IRC clientmaybe 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 proxiestwo 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 matteryou
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