On Fri, 7 Jan 2000, Chuq Von Rospach wrote:
> What I've decided to do for now is to move the archives from FTP to
> HTTP, on an Apache server, and then to write an apache
> authentification module. When you try to access the archives, you'd
> have to give your e-mail address, and you'll be validated in only if
> that e-mail address is a subscribed user. That puts the archives at
> the same level of security as the list itself -- they can only be
> accessed by someone who has gone through the subscription validation
> process (so by definition, they can get your e-mail simply by reading
> the list). It locks out anyone who isn't subscribed, so it locks out
> anyone you've kicked off the list or who isn't willing to give you a
> valid e-mail (assuming subscriptions are mailback-validated).
I have been working on writing a mod_auth_listar, which will check the
HTTP user/pass against an e-mail and a web interface password (since
Listar does allow passwords for the web interface, though I think the
cookie method is more secure). I don't want to use just the e-mail, since
then if you knew even one e-mail of someone on the list, you could harvest
all the others... though I don't want to require people to set a web
password just to access the archives. I have been considering an
intermediate login page that would create a Listar authentication cookie,
but that is starting to just get frighteningly wrong.
> anyone see any problems with this? I didn't want Yet Another
> Password, and it seems to me an authentification scheme that ties
> into the subscriber database is the easiest way to close off access
> without significantly raising complexity for the end user. Anyone see
> any real flaws here?
Other than the one I point out, no. But say someone forwards a message
from the list and you take the 'From' field in the forwarded message,
enter that in the 'E-mail' login portion of your web authentication box,
and voila, given one e-mail you can harvest all. It is still a better
approach than simply leaving them open to the world, though.
--
Jeremy Blackman - [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
Lithtech Team, Monolith Productions -- http://www.lith.com
Listar Developer -- http://www.listar.org
