Converted auth to use callable objects instead of tuples.

My attempt to address #275.

This seems a lot more explicit/clean, though I confess that I'm not aware of the considerations that led to the current implementation.

I also think this is a good first step towards implementing OAuth support (#65).


@idangazit I can see you referenced this pull request in the main [OAUTH Feature request](https://github.com/kennethreitz/requests/issues/65).

After reading the full thread thoroughly I can see how @maraujop [already thought about doing a pull request and then decided better](https://github.com/kennethreitz/requests/issues/65#issuecomment-2257820) to move into a separate hook to avoid a potential raise in issues, bugs, etc, in requests until the OAUTH functionality gets stable enough to consider pulling it in.

I think your code is pretty cool as it brings the HEADER authentication into the mix (although less supported by third parties, it's definitely more standard-friendly and much compact to code!). But, like @maraujop and probably like @kennethreitz, I think your code would be better merged and tested within @maraujop's [requests-oauth](https://github.com/maraujop/requests-oauth) hook.

I'm sure he will be happy to add such an awesome feature to the hook!

Cheers,


I actually integrated OAuth into requests [in an early branch within my fork of requests](https://github.com/maraujop/requests/tree/feature/oauth). I implemented it as part of requests because back then (version 0.5.1) there were no hooks and of course, no pluggable auth.

However, now that requests comes with a nicer architecture for third party contributions, I really think that keeping OAUTH out of request will definitely avoid pollution of the bug tracker with unnecesarry issues. After it's stable enough, we can decide if it's core enough to deserve a place within the main project.

@idangazit as we talked today in IRC I am more than happy to merge your implementation of header-OAUTH into my hook. I think having a nice, clean and complete implementation of OAUTH will truly benefit us all! 

Cheers,
Miguel


Per my conversation with @maraujop:

I'm happy with OAuth support being merged wherever, so long as it's merged. I think OAuth is a sufficiently common use-case that requests would be better for having support in the box, so let's say I'm +0 on OAuth in requests, but +1 on it being anywhere that is pip-installable.

First this patch needs to land in requests, though.


@jjmaestro, @maraujop: worth noting that this patch has nothing to do with OAuth, I'm merely saying that it lays a good foundation for OAuth support inside or outside of requests.


@idangazit sure, I can see how this is not OAuth but I read the main issue #275 (where you link your gist about OAuth) then read the Feature Request for OAuth in requests and saw your mention, clicked and kept reading...

Since everything ties together and since this is the place to discuss the potential foundations of OAuth I thought that it would be very interesting to discuss this with @maraujop and to also talk about your implementation of header-based Oauth.

@maraujop's hook is the de-facto OAuth support in requests (definitely the best available) and it's already pip-installable:

pip install requests-oauth

So what about merging this pull request and then putting your gist into a requests-oauth pull request? That way we get the foundations of a better auth support in requests and we get your nice header-based OAuth thus improving the best hook available. Later, you guys can test the shit out the hook and improve it to the point where @kennethreitz can consider if it makes sense to add it to the requests core :)

Win-Win for me!


So, originally, all of the authentication systems used their own handlers that were managed by an AuthManager. It was ugly, and my least favorite part of the codebase. 

If tuples were passed in, they were automatically converted to the appropriate AuthObject class, and all was well.

Now that I'm finally off of urllib2, a complete rewrite of that system occured, and that's why I have the callback-based system now.


That being said, I think we can support both ways properly now that urllib2 is out of the picture.

### Proposal
1. Use AuthObjects once again (like this pull request suggests)
2. Support tuple for basic auth.
3. Build a better mechanism for multi-request authentication. For example, digest auth requires two calls to the server to receive the nonce required to sign the request. OAuth obviously needs to do this as well. Currently, the digest auth is using an hook internally. This is fine, as long as multiple hooks are supported. Currently they are not.


Also, I do plan to have first class support for all forms of oauth inside requests itself. One thing at a time though :)

Currently, the best oauth interface I've used is here:

https://chrome.google.com/webstore/detail/cokgbflfommojglbmbpenpphppikmonn (https://github.com/codeinchaos/rest-console)

![interface](http://i.imgur.com/RK9s8.png)

I'd like to replicate this.


If I have time, I'm planning on writing this.

Interface axes:
- oauth version (1 vs 2)
- signature method (hmac vs plaintext)
- preferred method (header vs query)

xAuth will also have first class support.

Of course, sending requests with only the consumer key/secret needs to be obvious too (for the auth process). This is done poorly everywhere I've seen. Guided workflow (e.g. 'request token url', 'authorize token url') is out of scope— at least at first. I think it heavily contributes to the confusion around oauth. 


Okay, all this sounds awesome, but I'm not clear on the next steps.

I'm -0 on special-casing basic auth tuples, but It wouldn't be a big deal to implement. I'll hit that up later tonight.

Regarding the multi-request auth: seems orthogonal to this. I'm happy to look into ways to make this better, but can we split that work into a separate effort?

Besides the tuple thing, is this patch ready to merge? It doesn't add or remove any major functionality, and after this has landed we can turn our attention to OAuth.

# Regarding OAuth

After looking at all the python OAuth implementations out there, I started cobbling my own together which isn't tied to anybody particular url_/http_ library or requests — basically a spec-compliant generic collection of logic for signing OAuth requests. I'd like to expand that and think it could be useful for requests, but it's also a bit outside the scope of this pull request.

Adding comprehensive, first-class support for OAuth in requests is a bigger effort, let's give that it's own thread :)


I implemented HTTP Basic Auth in tuples as requested. I added a test to the suite to cover both the callable and tuple ways of adding basic auth, and documented the new behavior as well.

Anything more?


Thanks a ton, Idan! 

Enjoy your cake:  :sparkles: :cake: :sparkles: