[Python-bugs-list] [ python-Bugs-468948 ] urllib2, basic authentication, & 302

[noreply@sourceforge.net]

Bugs item #468948, was opened at 2001-10-07 21:19
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=468948&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jeffrey C. Ollie (jcollie)
Assigned to: Jeremy Hylton (jhylton)
Summary: urllib2, basic authentication, & 302

Initial Comment:
I've found a bug in how urllib2 handles 
authentication.  The crux of the problem is that the 
AbstractBasicAuthHandler.__current_realm is basically 
a global variable.  I discovered the bug because I 
needed to use HTTP basic authentication and the HTTP 
If-Modified-Since header.  Since the HTTP server 
returns a 302 error if the requested URL has not 
changed the line of code that resets 
AbstractBasicAuthHandler.__current_realm  back to None 
never gets executed because an exception will be 
raised when the retrieval is retried.  I suspect that
this bug would also cause problems in multi-threaded 
code.  The digest authentication appears to have 
similar problems.

The solution that I found is to get rid of the 
__current_realm attribute and prevent infinite retries 
by checking for the presence of an Authenticate: header
in the request object that exactly matches the 
Authenticate: header that would be added.

The bug exists in 2.1.1, 2.2a4 and the current CVS.

Patch attached.

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-11-09 08:49

Message:
Logged In: YES 
user_id=31392

Fixed in rev. 1.24 of urllib2.py, including changes to
digest authentication.


----------------------------------------------------------------------

Comment By: Jeffrey C. Ollie (jcollie)
Date: 2001-10-09 19:54

Message:
Logged In: YES 
user_id=37310

I haven't tried the patch yet but I think that it would fix 
the bug in the case of a single-threaded program.  However, 
with a multi-threaded program I think that my patch for 
this problem is superior because it doesn't rely on a 
property shared by all of the threads that use the same 
opener object.  Of course, my patch assumes that a request 
object is used only by one thread but I think that that's a 
safer assumption.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-10-09 19:17

Message:
Logged In: YES 
user_id=31392

Does the patch in bug #451295 fix your problem?


----------------------------------------------------------------------

Comment By: Jeffrey C. Ollie (jcollie)
Date: 2001-10-09 10:21

Message:
Logged In: YES 
user_id=37310

Oops, that patch that I attached is reversed, use -R!


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=468948&group_id=5470