proposed change to handling of boto auth plugin framework when multiple plugins are found supporting requested capability

[Michael Schwartz]

Hi,

The boto auth plugin framework currently raises the TooManyAuthHandlerReadyToAuthenticate exception if more than one plugin is found ready to authenticate with the requested auth capability at the time a request is made. Originally Google implemented that exception approach to prevent unpredictable behavior in case of mis-configured auth plugins.

In practice, this kind of mis-configuration hasn't been the problem we thought it might be. First of all, I believe it can't happen in AWS, because the auth plugins for AWS each implement disjoint capabilities. As further evidence, Mitch noted in a discussion about this handling in December "I've never seen this error come up before".

The error *does* happen occasionally in Google cloud services, because there are multiple auth handlers each of which declares support for the 's3' capability (an OAuth2 handler and a service account auth handler, in addition to the standard HMAC v1 handler included in boto). And for this case we now want to change the handling, per the idea I proposed in the December discussion: Rather than raising an exception, we want the plugin framework to pick the last plugin that was loaded that's ready to auth with the specified capability (which will thus be the last in a path of config files, like /etc/boto.cfg and ~/.boto). The idea is that this approach allows customers to set up shared configs (e.g., setting up a service account plugin in /etc/boto.cfg), and then have end users customize with individual user credentials in ~/.boto.

I heard no objection at the time I proposed this change (and one +1 of the idea), so I have now implemented the suggestion. I made this change in a fork, and sent a pull request so boto users can see it. I'm pretty sure (for the reasons noted above) that it will not have negative consequences, but since the auth plugin framework is centrally involved in boto operations I wanted to give the community a chance to look and comment before I commit this change to the develop branch.

Thanks,

Mike Schwartz

[Mitchell Garnaat]

Hi Mike -

I have no objection to this approach.  I wondered whether we might want to some sort of explicit prioritization associated with each plugin rather than relying on the order of loading but that might complicate things more than is necessary.  I'll leave that up to you, I think, since at the moment the only time this situation arises is with Google Cloud Storage.

Mitch

[Michael Schwartz]

Thanks Mitch.

I think I'd like to start with the simpler approach (prioritization based just on load order), and wait on adding explicit prioritization until/unless it turns out someone has a problem with the simpler approach.

Mike