Transparent List Access

Members enter the list server web interface without entering email address or password while improving security.

The ultimate goal should be to make access to the end user web interface completely transparent. As long as member's are limited to one email address and the web interface is available only as a private part of the web site, this is achievable. By definition, only authenticated users are accessing private web pages. As long as an unequivocal link is made between user names and their member record, anything that is needed, including email address can be retrieved when it is needed.

Users no longer need to provide email addresses and optional passwords. Instead the system uses the REMOTE_USER environmental variable to determine who is running the script, retrieves their information and passes it to Lyris formatted as necessary. Even if the user manually created a list member record with a password before the transparent interface was developed, at the point that a user wants to enter the list, the script knows which list it is and can get their email address. With these pieces the program can use the API to get the user's password and return it to Lyris as required by the web interface.

Web site passwords, and the passwords for different lists, are completely independent of each other. After users simply forgetting their web site passwords, the most frequent end user support issue I encountered was users not being able to keep straight the difference between the web site password, which in ATLA's case was obtained via HTTP basic authentication and the passwords for the lists. When trying to enter the web interface to lists, even when the user correctly entered their email address rather than their ATLA NET user name, many users still entered their ATLA NET password, rather than leaving the list password blank, causing Lyris to display an error message.

One thing that a transparent interface needs to be particularly careful about is distinguishing between current list members and non members. It would simplify programming if the script just made everyone who used the web interface a member of the list but this would be a major mistake, as simply viewing a web page would cause unsuspecting users to get large volumes of unwanted email. While transparent access can take current members of the list directly into the list user pages, it has to distinguish non list members and clearly explain the options and consequences. Non members need to be able to choose between visiting the list and joining the list. In either case, after the options are explained, selecting should involve no more than a button click as the script will automatically create a new member with the default options. The list options page needs to be relocated to the main list use screen since the entry screen will no longer exist. A leave or unsubscribe option also needs to be relocated here.

Another advantage to the transparent approach is that it significantly reduces the ease with which one list member may post messages to the list as another member. While the email interface won't accept messages that are not From: a current member, the web interface has a hole that even non technical users can exploit. It allows any list member who knows the email address of any other list member, i.e., anyone who has posted to the list, to enter the list as that person, unless that email address and list membership is protected by a password. At ATLA we were not concerned with this because our standard security involved a significant degree of extra logging. By placing a function call to our security module in the Lyris Perl scripts, every use of each Lyris function was automatically logged. Had a situation ever occurred where one member posted using another's email address, it would have taken only a few minutes of log comparison to identify the culprit.

Top of Page - Site Map

Copyright © 2000 - 2014 by George Shaffer. This material may be distributed only subject to the terms and conditions set forth in http://GeodSoft.com/terms.htm (or http://GeodSoft.com/cgi-bin/terms.pl). These terms are subject to change. Distribution is subject to the current terms, or at the choice of the distributor, those in an earlier, digitally signed electronic copy of http://GeodSoft.com/terms.htm (or cgi-bin/terms.pl) from the time of the distribution. Distribution of substantively modified versions of GeodSoft content is prohibited without the explicit written permission of George Shaffer. Distribution of the work or derivatives of the work, in whole or in part, for commercial purposes is prohibited unless prior written permission is obtained from George Shaffer. Distribution in accordance with these terms, for unrestricted and uncompensated public access, non profit, or internal company use is allowed.