The esteemed Mark Sapiro has said:
But was the archive 'private' or 'public' (admin Archiving options)
before the problem started?
We're going back to Jan. 11 (when this started), and I'm trying to
remember what I changed then. I suspect that I ran check_perms around
then an fixed what it griped about, and the permissions on the private
directory was one such. Let's assume this was the case (I can easily
check, but I don't think setting the directory permission open really
proves anything. Nonetheless, I should do it to see that it does clear
The scenario plays like this:
On cold entry (no cookies in the browser) go to the archives page from
the main page. User validation screen pops up. Enter username and
password, and you get to the pipermail archives. You can now read those
all day without needing to revalidate.
Now, set up an htdig search, which returns a few pages of hits. Click
on one of those hits, and the validation screen pops up again.
Validate, and the message is displayed. Go back and click on another
hit. The validation screen pops up again, and displays the page after
Trying to display the second page makes the
I assume you mean the second page of hits.
Yes. Htdig will do the search and display a page of returns. Anything
beyond that requires revalidation.
It seems clear to me that the htdig process is not able to find the validation
I don't think that is the issue. It seems to me that the htdig process
finds the cookie the first time, but then removes it. This explains
why you need to revalidate when you try to visit the message, and it
explains why you get mmsearch.py's authorization error when you try to
get the second page of hits.
Yes, it's the second time in. Doing a second search on top of the first
(i.e. changing the htdig search return display and telling it to search
again) gets the error.
I have been reading the code (and Python in a Nutshell).
if not mlist.WebAuthenticate((mm_cfg.AuthUser,
raise _search_exception(listname, 'auth', '-10-')
What I'm seeing is consistent with the "if not" condition. And if this
is the second pass through this, rather than the first, then it implies
that something in the code following is involved. I've included a cut
and paste of exactly what is in the mmsearch.py, and will be doing some
creative code-reading to see if this call differs from other calls to
the same function.
I've located the WebAuthenticate() function in SecurityManager.py and
note that it is used in several places, all of which behave as
One question comes to mind: why are we revalidating here? I'll assume
without having researched it that the entry to the pipermail archives
has its own validation, and in my configuration, you can't get to the
archive search except from that post-validated page.
Theoretically, I suppose I could work around for the moment by simply
commenting out that check, but since something's getting trashed
somwhere, think it better to pursue debugging the problem.
If this were compiled code and not Python, I'd dbx the thing,
but don't know enough about Python to know how to use the debugging
resources. If there's some sort of crash and traceback message, I don't
know where to look for that either.
I'm busy reading the O'Reilly python book on debugging to see where I
might get some hooks into this.
There wouldn't be a traceback in this case.
No, I can see that the code has an exit.
It seems that htdig per se is working fine. It returns the hits. I
think the problem is in mmsearch.py. It checks to be sure it is
authorized for the private archive, and it is. It does the search and
displays the results and somehow in this latter step the cookie is
I'll guess that you're right about the htdig installation. However some
more testing is showing is not that the cookie is being removed, but
that we've got something that's nulling something.
Running with the admin password set, I go from the admin area to the
main list page, then to the archives, where I can read the pipermail
Do an htdig search, get the first page of hits back, and try to look at
one. Anything entered in either the username or password field clears
the block. One character in either field suffices, and it does not have to be
After having gone throught this exercise several times, I can go back to
the admin pages without having to revalidate---the cookie is still set.
Hank van Cleef (vancleef at lostwells.net, hvanclee at nyx.net)
1986 420SEL "A stranger in paradise" (Fremont Co. Wyoming)
1986 GMC 1500 6.2 diesel pickup "Seen one, seen them all"