Allow override of token and secret on a per-call basis.

[judgej]

At the moment, a single Guzzle client can be set up with this handler, and the operation of the handler can be enabled or disabled by passing the auth parameter to a request send: oauth1 turns it in and null turns it off.

I would like to go one step further, and allow an oauth_token and oauth_token_secret to be passed into the request as options. These should allow the token and secret to be set for that request, and to override the values given to the OAuth1 object when it was created.

Why? It's about making token refreshing more invisible to the application. When a HTTP request is made, it may fail if the token has expired. This can be caught, a fresh token requested, then the HTTP request fired off again. The application should not have to get involved in the logic of this, except for being signalled to persist the new token and secret.

Now, at the moment, to resent the request with new tokens, a new OAuth handler needs to be created. Then a new handler stack. Then a new Guzzle client. This is all done at a very low level where the full configuration used to create all these things may not be known. What's more, the Guzzle client and the OAuth1 handler are immutable, and do not have any with* methods for cloning with a few configuration changes, so we have no workaround.

I'm using this with Xero in the context of a Partner Application. The way OAuth straps itself across every level of API access at he moment, instead of staying nicely in one or two layers, makes for very messy applications. I'm trying to get the OAuth functionality (request and token refreshes) to stay close to where the Guzzle requests are sent.

Is this something that would be acceptable to submit? Useful to anyone else? Am I just missing something - maybe OAuth is neat and easy-peasy, and I'm somehow making it messy and difficult?

[judgej]

Looking at the Guzzle documentation here:

http://docs.guzzlephp.org/en/stable/request-options.html#auth

It looks like the auth parameter is supposed to be an array anyway, and not a string. All the overriding parameters could go into that.

Edit: or a string, after reading again. Still, an array is supported and recommended for whatever parameters the auth handler needs.