Oliver posted about his 'newconfirm' patch to make the confirmation tokens
random way back in January and I've noticed that when my list members try
to zubscribe to multiple lists at the same time using his patch, only one
of the requests goes through successfully. The rest fail.
I believe the reason to be that the way it generates the keys isn't robust
enough. If the time hasn't changed since the last key was generated, it
will make two keys with the same number. Since it loads the keys into a
hash each time it reads them in, the next time it reads the key file, it
will write out one containing *only* the last of the duplicate keys.
Thus, when the person sends the key in, they get zubbed to the last list
they chose, but none of the others.
I'm not sure how to go about fixing it, but I think the best thing would
be to use a global variable that initially has an undefined value. Once
you generate a key, you store it into this variable. Each time you
generate a key, you check against the global variable. If they're equal,
increment your key and try again. Furthermore, it should
check the file for a key with that ID before it appends it.
Hopefully, my analysis of the situation is correct and this is all I'll
have to do to fix the confirmations. I had to merge the patches by hand
into my 1.94.3 copy of Majordomo. Unfortunately, the patches weren't
applied until after I applied about 15 other patches. I should be able to
get one together against a vanilla copy of Majordomo, though. Also, I
added a new feature that prints a URL for you to jump to and have a script
that fires off an e-mail to Majordomo on your behalf. The script must run
on the same machine as Majordomo and have access to the keys file, but it
works beautifully. I also changed the documentation to reflect the
different confirmation system.
Chael
--
Chael Hall, nowhere@chaos.taylored.com
Gossamer USA - http://gossamer.x-philes.com/
Follow-Ups:
|
|
