[Yum] HTTP basic auth patch (was Re: Basic auth fails in 1.97, works in previous versions)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I'm in the process of working in the patch you submitted.  I have a
couple of comments, and a question for the list.

Let me start with the question because that's likely of the most
general interest: What happens when you do both authenticated
connections AND failover/mirroring?  Specifically, what happens if you
want to have two servers in a failover list with different
username/password, or one's public?

If we deal with this by having options in the config file, you're
sorta screwed.  If the info is buried in the url, then you can do it
PER url.  I can think of three real options, in order of increasing
technical pain and complexity.

1) allow options only - build up the url where needed (ftp, etc)

2) allow url-embedding only - for the new http stuff, that would
   require pulling them out of the url and dealing with them
   correctly.

3) allow both - url-embedded info overriding option info.  This way,
   if you have all the same auth info, just use the options.  If
   they're different, then encode them in the urls.  This is the best
   of both world for users, and worst of both worlds for the coders.

Thoughts?

On Tue, May 20, 2003 at 12:49:46AM -0500, Joe Cooper wrote:
> I've attached a patch that adds HTTP basic auth to yum 1.97 using the 
> urllib2 HTTPBasicAuthHandler.  It adds three new configuration file 
> directives (user, password, and realm).  All three appear to be required 
> for the urllib2 auth support to work (I would so love to kill the realm 
> directive but I can find no documentation that explains how to get by 
> without it, and a couple of hours of testing and searching resulted only 
> in frustration--if anyone has a clue on this point, I'd be very happy to 
> hear it).

Joe, I've done this... sorta.  I've derived from
urllib2.HTTPPasswordMgr and overridden find_user_password so that
there is a "default" realm.  Anything added with realm=None will get
put there.

> I haven't added in the FTP support yet, but it is harmless to all of the 
> other schemes (file and ftp), as far as I know.
> 
> I've tested all of the yum commands against a server that does require 
> and a server that does not require authentication and they all work, but 
> I'm sure it is still buggy.

The biggest change that I've made is that you do not need to rebuild
the handler every time you get a file.  It is sufficient simply to add
the username/password/realm to the existing handler.  With that
change, the part that happens inside urlgrab is reduced to:

    if username and password and http_auth_handler and scheme == 'http':
        http_auth_handler.add_password(realm, host, user, password)

> One comment, which is probably more of a statement of my Python 
> ignorance than a useful criticism:  The keepalive bit at the top of 
> urlgrabber forces some extra extraneous checks into the auth code, 
> because it doesn't guarantee that an opener comes into existence.  This 
> seems like it could lead to bugs.  If the way the keepalive setup works 
> changes, auth setup breaks...I'm probably in the wrong on this, but I 
> couldn't figure out a way to check for the existence of the opener 
> object (and believe me I tried).  I guess another try/except, of some 
> sort, might be the solution to this.

The above helps a lot, of course.  Basically, I set up the auth stuff
FIRST.  After that, you're guaranteed to have an opener (as long as
it's python 2).  Then keepalive just does .add_handler as you were
doing later.

> I'm just posting for comments, as I plan to add FTP support before I 
> start campaigning for Seth to add this to the real yum.  But I welcome 
> any criticisms, as long as you've got a better way and tell me what it 
> is.  ;-)

I'd still be interested in your ftp code.  I'm holding off on working
on that until I get some replies to my question.  If you're interested
in seeing the actual code, I'll send it to you.  Otherwise, I'm going
to wait to see which way folks want to go before committing.

					-Michael
-- 
  Michael Stenner                       Office Phone: 919-660-2513
  Duke University, Dept. of Physics       mstenner@xxxxxxxxxxxx
  Box 90305, Durham N.C. 27708-0305


[Index of Archives]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]

  Powered by Linux