[Yum] HTTP basic auth patch (was Re: Basic auth fails in 1.97, works in previous versions)
joe at swelltech.com
Thu May 22 03:36:56 UTC 2003
Michael Stenner wrote:
> 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?
I haven't been following the failover thing at all. So with failover,
there can be multiple baseurl entries per serverid?
> 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)
This is where I've been going, obviously, because Seth pointed me in
that direction, and I had no strong objections to it. (BTW-Seth, was
there a reason to switch to urllib2, instead of urllib, other than just
that it is newer? It seems unnecessarily complicated and new-fangled
for what yum has to do, while urllib is dead simple. But I'm a Python
newbie, so I'm not allowed to hold strong opinions.)
> 2) allow url-embedding only - for the new http stuff, that would
> require pulling them out of the url and dealing with them
This wouldn't be that hard. The complexity that results is made up for
by the simpler FTP case (in the FTP case, with user and password
directives, we have to build up the embedded URL). It also has the
minor benefit of keeping the same syntax that currently works in earlier
urllib-based yum versions. I lean towards this being the Right Way for
> 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.
I'd really rather not see two ways to deal with auth info. It is
inconsistent for the user, harder to program, and provides no benefits
to the user that I can think of. I hold a strong opinion on this one,
just from a user perspective. Pick one way, and use it universally for
all types of server auth info.
I'll also mention that from perspective of developers of GUIs, multiple
syntaxes for the same thing make life more difficult than necessary and
bugs in the GUI/docs/etc. more likely. I say this from the perspective
of one planning to add yum support to Webmin's Software Packages module
in the next week or two.
> 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
> 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.
Yeah, I was talking to someone via IRC the other day (thanks Tres!)
about this, and he seemed to think the HTTPPasswordMgrWithDefaultRealm
would do what I want without even having to override anything. I
couldn't figure out how to make this one go when I was working on it
over the weekend, but I can only safely plead ignorance rather than
claim the documentation is lacking significantly, though that would be
my first instinct were it a language I know better.
>>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)
This makes sense. I noticed that quite a lot of stuff was persistent
between calls to retrygrab, once I was finished with the bulk of the
work. I don't understand why they are persistent yet, but now that I
see that they are this kind of approach makes more sense.
>>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.
Ok. That's a better way, indeed. Thanks for pointing it out.
>>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
> 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.
Go ahead and send over what you've got and I'll add FTP support
tomorrow. It sounds like your changes make things a little cleaner than
my implementation, and I'll be happy to be rid of the weird reliance on
the keepalive stuff never changing.
I'll also do some more experimentation with the
HTTPPasswordMgrWithDefaultRealm class to see if I can make it go.
Joe Cooper <joe at swelltech.com>
Web caching appliances and support.
More information about the Yum