When the external program wants to supply ConferenceRoom with a new list of username/password pairs, it should rename the file containing that list to webpass.new in the db directory. The file should be renamed, not generated in place. Otherwise, the web server cannot know when the file is complete and will read partial files, causing users to be locked out and CPU time to be wasted. The web server will assimilate the new list of username/passwords within about two minutes.
To mark a file as a secure file, create a file in the same directory as that file, with the same base name, but a .secure on the end. So, to secure default.htm create a file called default.htm.secure in the same directory. The file's contents are unimportant. It can be empty, it simply must exist (and be readable by the web server). Note that for UNIX builds, the file name must be entirely lower case, including any directories it is in below htdocs.
If you wish to secure the java client, we recommend that you make your default.htm file link to a secure web page. That way the user name and password are entered before the java client attempts to load. This will prevent problems from browsers whose java engines don't know how to prompt for a password. To secure the java client, we recommend securing cr.zip, cr.cab, and ConferenceRoom.class.
You should create a web page in the data (WIN32) or htdocs (UNIX) directory called cliauth.htm explaining how you get a username/password. This page will be displayed to anyone who fails to authenticate. Do not make the page too large. There is a special replacement variable you can use in this page, if you wish to -- %reject% will replace to the reason the connection was rejected.
There are also two special replacement variables you can use in secured pages. %|a_user% and %|a_pass% will replace to the user name and password they authenticated with. You may wish to use the user name as the 'real name' for the java client. If you wish to use these replacement variables in the .prm file, you should secure it as well. This will allow you to use the person's username as their nickname or real name.
Planned for future versions of the web server are better integration between these passwords and ConferenceRoom's client classes or services nickname passwords. Also planned is better logging of access to password protected pages. Support for checking IRC clients through the same mechanism is also planned.
Note that enabling password protection has a performance penalty on builds before 1.6.5d. The web server now has to check for the existance of .secure files on each access and negative caching was not implemented until 1.6.5d.