[Mailman-Users] htdig authorization problem

[Mark Sapiro]

Hank van Cleef wrote:

>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 fault).


What I'm trying to determine here is if the authorization in
mmsearch.py has 'always' been broken and it was only noticed because
the archive was changed from 'public' (not requiring authorization) to
'private', or if it worked before and stopped working.



>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).  
>
>mmsearch.py has 
>        if mlist.archive_private:
>            if not mlist.WebAuthenticate((mm_cfg.AuthUser,
>                                             mm_cfg.AuthListModerator,
>                                             mm_cfg.AuthListAdmin,
>                                             mm_cfg.AuthSiteAdmin),
>                                            '', ''):
>                raise _search_exception(listname, 'auth', '-10-')


Yes. This code says "you can't be here if you don't have the cookie".
The first time through you have the cookie and all is good. If you
then go to a message, you don't have the cookie, but that code allows
you to reauthorize, so you get it again, but you had to reauthorize.
If you come through mmsearch.py a second time, you have no cookie and
you get the exception.


>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 don't see the cut and paste, but I have the patch code, so I don't
need it.


>I've located the WebAuthenticate() function in SecurityManager.py and
>note that it is used in several places, all of which behave as
>expected.
>> 
>One question comes to mind: why are we revalidating here?


To prevent you from just going directly to an mmsearch URL and
searching without authorization. We don't attempt to reauthorize here,
because if you are playing by the rules, you are already authorized.
We just check.


>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.  


If you are playing by the rules.


>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.  


You don't want to comment out the check because it will allow
unauthorized users to search the archive by invoking mmsearch
directly. They won't be able to view the messages, but they can get
information from the search results.


>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
>archives repeatedly.


Good, but I'm not sure that's relevant to the problem.


>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
>alphanumeric.   


Puzzling, but what then is the exact URL that the search results page
links to for the message.


>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.


If the cookie isn't being removed, then perhaps there is something in
your web server specific to the URLs that don't work that is not
passing the cookie to the environment. This now seems very likely, and
would explain why you can reauthorize with 'invalid' data.

Look at
<http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq04.045.htp>
and
<http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq04.065.htp>
and see if there are any clues there.

For example are the non-working and only the non-working URLs http
scheme that's being redirected to an https scheme URL in your web
server.

-- 
Mark Sapiro <msapiro at value.net>       The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan