This chapter is from the book
This chapter is from the book
This chapter is from the book
Administration and Security
No system is a good system if it can't be administered. The days when "Netiquette" made it a point of honor to be polite and integrate oneself into the community are long gone. Nowadays it's common to be exposed to hacks, harassment, and other forms of attacks—and unfortunately, most of them don't stay at the verbal level. There's hardly anything to say against digging for security leaks and other holes in an application or network system. Constantly exploiting them, however, is worthy of condemnation, yet a lot of people consider it "fun." This demands an external interface, running independently of the main system, which allows full control over all of the application's data and users. In terms of a chat system, this means that we need to be able to kick users, moderate their messages, and secure chat rooms.
Note: Not all features listed here are implemented into the code on the CD-ROM. The basic administration system is complete and fully functional, but we'd like you to exercise and extend the code base with the features you feel appropriate. If you haven't made significant extensions to larger applications, we honestly urge you to gain the experience now.
The question for our chat program is this: Where do we fit in the administration? We have a few possibilities:
-
At network level: We could filter users connecting to the server.
-
At PHP level: We could prevent users from logging into the chat.
-
At database level: We could discard messages from users from the database.
-
At IRC level: We could use IRC's native network administration features.
Network Level
Securing at network level only allows two possibilities: letting a connection through or not. This could be realized using a firewall or other possibilities of IP masking. This method is limited, complicated, insecure, and in general not what we want.
PHP/Web Server Level
Securing at the Web server level basically allows connection to the server but restricts clients from logging in using password protection (or different methods of authentication). Basically it again boils down to letting a connection through or not, which is not really satisfying.
However, this method can be used to emulate user bans. The common bans for IRC, namely K-lines and G-lines (local and global bans of users), cannot be used with a Web-based chat system, as all connections originate from the Web server. The only ban-able address would be the address of the Web server, which would completely ban the whole interface from the network. To still be able to filter out special users, connections should be evaluated at the PHP level.
Database Level
The database level is a totally different approach. Clients are allowed to log in and chat, but their messages and session information are filtered in the database. Either an external tool or the chat code itself would check for the user to be allowed to say or do something and, based on this info, allow his/her messages to be inserted into the database—or not. But this strategy requires a very tight integration into the main chat code, is not very flexible (and kind of clumsy), and is inelegant to implement.
IRC Level
IRC provides native administration features built into the server code and network protocol (we hope you read the RFC and are familiar with these possibilities). Administration can even be done by regular users. Three levels are available:
-
Channel operators. These operators have administrative control over channels. They can kick users, "mute" them, ban them, make other users into operators, and such (this level is available to all users).
-
IRC operators. These operators have administrative control over the network (but not channels). They can kill users from the net, ban them, establish network links, and so on (this level is only available to special users).
-
Services. Services have administrative control over channels but no control over the network, and are not able to perform like regular users. They also require a special login procedure (this level is only available to special users and is meant for automated clients).
As you can see, administration at IRC level can be done using a client running separately from the main chat system. A separate client with IRC operator and channel operator status would give the ideal combination of features that we need an administration system to have. Basically, only IRC operator status is needed initially, since as soon as the administration client has gained IRC operator status, it can gain channel operator status everywhere by killing all users from a channel. This is not a very nice method, but more effective and versatile than patching the IRC server code to give IRC operators equal rights to channel operators.