Let's review the following: WebBoard users log in under two possible "authentication" modes.  Under basic authentication, a grey pop-up box is used to log in: this box is under the control of the user's browser, and the user may save his or her password by using a checkbox on the pop-up.  The browser passes the login name and password to the server in encrypted form, thus preventing hackers from "intercepting" web packets.  Under cookie authentication, users log in through a normal browser window, and a cookie is used to declare their login status.  The login name and password are passed to the server without encryption, and if the user chooses to save their password, this value is saved on the user's computer as an unencrypted cookie.  Under WebBoard 4, the logoff button only clears performs any necessary "marking read" updating, and sends the user to the logoff URL.  For WebBoard 5 and 6, the user is sent to a page that explains some, but not all of the consequences of logging off under basic authentication, and which gives the user the chance to clear his or her cookies under cookie authentication.  The information on this page doesn't appear to vary, regardless of whether the user has actually saved his or her password under cookie authentication, and/or visited one or both types of boards.

This system provides you with a strategy that takes into account whether or not the user had accessed boards of either or both types, and one that clearly informs the user of their options at logoff time, in plain English.  For example, the terms "basic authentication" and "cookie authentication" aren't used, when communicating with the user.

This code is freeware.  You use it at your own risk.  No warrany of fitness for use or any other form of guarantee inheres.

To better explain the processing, I need to clarify a few facts.

For simplicity, I'll refer to boards as no-auth boards (i.e. those that use no authentication, basic boards (i.e. those that use basic authentication), and cookie boards (i.e. those that use cookie authentication).

• The user has accessed a cookie board during this browser session if and only if: the WB-Pass cookie is defined.

  This makes it easy to determine whether or not a user has accessed a cookie board.

  Under WebBoard 5 and 6, the WB-Save cookie will be set, if and only if the user has checked the "save password" box during the last cookie board login.

• It's harder to determine whether or not the user has accessed a basic board during this browser session, particularly for "no frames" users.

  If the user has never accessed a cookie board, or goes to a basic board before going to any cookie board, then this system will always know.  That's because it can detect whether or not the board is a no-auth board, and if the WB-Pass cookie isn't set, then it follows that the board must be a basic board.

  For frames users, the frameset is redefined to include a hidden frame: the URL "loginagain" is loaded in that hidden frame.  For cookie boards, the regular login page (login.html) will come up in that hidden frame, but for basic boards, the page loginagain.html will come up in that hidden frame.

  However for "no frames" users, my system can't always be certain about whether or not they've accessed a basic board, unless they access this board before accessing any cookie boards during the current browser session, and they don't have a saved password cookie.

  (Unfortunately, the tag script call authmodeld doesn't seem to return a value which is accessible to either of the default open scripting languages, so it can't be used.  And while direct database access would settle the question, I try to avoid this in my systems, since system administrators tend to be rather protective of their databases.)

• In order to assist the system, there's an additional "variables" file that you configure: this file carries two flags that indicate: (1) whether all basic boards have the logoff system code installed; and (2) whether any "ordinary users" have access to basic boards.  By "ordinary users," I mean those who aren't WebBoard administrators, virtual board managers of the current board, or anyone else who's sophisticated enough to know what they're doing when it comes to logging off.

  These values are G_AllBdsFlag (set to 1 iff all basic boards have the logoff system installed, otherwise 0); and G_AnyBasicFlag (set to 1 if ordinary users of this board have access to basic boards, else 0).

• For reasons that will become clear later on, the "logoff" button's functionality is removed for guests on cookie boards, as well as for everyone on "no auth" boards.

  One might quibble about the wisdom of this choice: a stronger implementation would simply use database access to determine the type of board.

Here's what the system actually does when the user clicks on the "logoff" button.

• First, we attend to the business of marking messages read.

  For frames users, the profile editing page (useredit.html) is loaded in the hidden frame.  This page looks at the previously defined variables, the user profile (is the "automatically mark messages read" option on?), as well as the <WB-NEWMSGS> tag.

  For "no frames" users, the frameset help?lg_nf (lg_nf.html on the help subfolder) is loaded.  It will in turn load useredit.html in the hidden "extra" frame of this frameset, while loading help?lg_wait (lg_wait.html on the help subfolder) in the visible frame of this frameset.  That page instructs the user to wait.

  If the user has requested to "automatically mark messages read" and there are new messages, then markread?0 is loaded in the hidden frame (i.e. to mark all messages in all conferences as read).

  Otherwise, the processing ends after loading useredit.

• Useredit or markread will terminate in one of three possible ways.  Consider the first case, in which no cookie boards have been accessed during this browser session (and the user hasn't saved their password during the last access to a cookie board).

  First, if no cookie boards have been accessed, an alert will pop up.  This alert will advise the user to close all browser windows, and remind the user how to reverse the effect of checking the "Save this password in your password list" box in the pop-up.  (That message actually varies, depending on whether the user's browser is IE or NS).  After the user clicks on "OK", the user will be sent to the logoff URL.

• If useredit or markread detect that no basic boards have been accessed, then the user will get the choice between going to the logoff URL without clearing their cookies, or after doing so.

  If WB-Save cookie is set, we'll remind the user that s/he had previously saved the password, and that it will be UNsaved if s/he wants to clear cookies.  This is done via a confirmation box, and after clicking on either "OK" or "Cancel," the user will be sent to the logoff URL.  (Note that the WB-Save cookie doesn't appear in WebBoard 4.)

• Useredit and markread are sensitive to a third option: what if the user has definitely acessed both basic and cookie boards; or the user has definitely accessed cookie boards, and it can't be determined whether or not basic boards have been accessed.

  When are we certain that the user has accessed a a basic board during this browser session?

  First, if the user is a frames user, and G_AllBdsFlag is 1, then we know for sure that basic board access would have been detected (since "loginagain.html" would've been loaded in the hidden frame).  Also, if the WB-Pass cookie doesn't exist, then the user must have accessed a basic board (since s/he couldn't have accessed a cookie board, because "no auth" boards lack a logoff option).

  However, if the WB-Pass cookie exists, and G_AnyBasicFlag is 0, we also assume that there are no basic boards.

  If we can't tell whether a basic board has been accessed, it must be the case that: (1) the WB-Pass cookie was always defined (the topics page will notice if this cookie is undefined, and set another cookie which indicates that a basic board was definitely accessed); (2) there are basic boards accessible to users of this board (i.e. the G_AnyBasicFlag is 1); and (3) either the user is a "no frames" user (we can always detect the access of a basic board for frames users, if all boards carry the logoff system's HTML files), or there is at least one board which doesn't have the logoff system HTML files installed (i.e. G_AllBdsFlag is 0).

  Note that condition (1) in the previous paragraph can occur if the user previously saved their password on a cookie board, closed all their browser windows, and refrained from accessing cookie boards in subsequent browser sessions.  This scenario can't be distinguished from the case in which the user has accessed both varieties of boards during the same browser session.

  In the even that the user has accessed a cookie board during this browser session (or has a saved cookie from a previous browser session), and may have accessed a basic board during this browser session, we display the following page:

  

  If the WB-Save cookie is defined (that means that the user has saved their password on cookie boards), then the text will vary accordingly.  The text will also vary accordingly, depending on whether we're certain that the user has accessed a basic board during this browser session.

  After clicking on one of the two links in the second table, the user will be sent to the logoff URL.

  Note that if the user selects the second link, their WB-User and WB-Pass cookies will be cleared.  Therefore, if they later access a cookie board, they'll have to provide their login name and password again ... even if they haven't closed all browser windows, and even if they'd previously checked the "save password" box on WebBoard's login page.

  Note also that this page clearly explains the consequence of checking the "save password" box when logging into a basic board, and how the user can "un-do" this state of affairs.

  This page doesn't use language that's likely to confuse most users: instead, it describes the two types of boards in simple terms.

  Finally: this page comes up only when there's no way to avoid this level of complexity.  (See the previous processing cases.)

If you've customized any of the WebBoard pages that are in my install, you'll have to either propagate your customizations to my pages, or propagate my alterations to your customized pages.

Here's a list of each file, along with the role it plays in the various operations:

For simplicity, I'll refer to boards as basic boards (i.e. those that use basic authentication), and cookie boards (i.e. those that use cookie authentication).

DEST should have the folder name of your main WebBoard HTML folder; probably: c:\\webboard\\html, if you're running it from the server.

Note that double backslashes are required to separate folder names.

For more information about folder names, please see my DOS primer.

WebBoard 6 users: the "modern" layout isn't supported.  If you wish to use it, you'll have to make the corresponding modifications to layout2.html, topics2.html, and nftoolbar2.html.  If you wish, you may contact me, and I'll make them for you.

Please supply me with as much information as you can about your server, your version of WebBoard, any browser or Operating System that was involved, including the WebBoard Server's Operating System  (9x, NT, 2K, XP?).  Also, please provide any configuration files, or customized WebBoard files that you were using.  Keep in mind that I might actually have to have the opportunity to try what you were doing, in order to diagnose the problem.

BTW, I don't gaurantee to answer all e-mail or fix all bugs, etc.  Please remember that this is freeware, and that my time and resources are limited.

That said, I've put a lot of work into designing, coding, testing, and documenting this product, and I'm probably going to be fairly interested in any comments anyone has, fixing any bugs, and/or extending the scope to applications that strike me as being potentially valuable to a large number of users.

Naturally, if you're willing to hire me to make changes for your special-purpose application, I'm certainly willing to consider your offer.  My standard rate is $75/hr., but I may charge less if the work is to be done for a small business (less than 25 employees), or a nonprofit organization (in the latter case, I might even do it on a gratis basis  :-)  I may also consider charging you nothing if you're suggesting an improvement that I feel is of value to a large number of other users.

You can find out more about me, including references, and a list of clients/projects at: http://www.rs-freeware.org/rog.

Other people pointed out to me that the previous release of this system (which merely cleared the cookies) was woefully insufficient ... they shall remain nameless, as per their request.