Refactor OAuth into separate module

[simov]

This is a follow up to my previous PR #1350 Also it might be related to this one #1360

The getParams function is about the generation of OAuth parameters. I think it's pretty straightforward to understand which parameters have defaults, which are excluded, and what parameters are required for the OAuth signature.

The concatParams function is the old buildSortedParams but I though it deserves it's own function, I mean the oa parameter was used from the outer scope, so it was not exactly a function in that sense.

One change in concatParams is that the signature is no longer appended to the end of the string, but that can be changed if it not confront to the spec in some way.

The oauth function is pretty much what's left from the original one, but I think now it's more compact and easy to follow, it even fits on my screen. The getParams and concatParams are called from there, there is only one level of indirection so again it's very easy to follow.

All of the available input args parameters are listed on top of the oauth function. Also right now in Request this module is called like var result = oauth.oauth which is a bit silly, but I couldn't come up with something more reasonable.

At first I thought that returning of a map is not a good idea for the oauth method, but then I liked how it feels, I mean result.transport and result.oauth sounds good to me.

That's all I could think of at the moment.

[nylen]

👍 looks fine to me. I'm not an expert on OAuth (or our OAuth code) but my test scripts against oauthbin.com still pass so I think moving oauth_signature is ok.

I'll merge this in a couple of days if no one objects or beats me to it.

[simov]

@nylen I just enabled the realm parameter for query and body transport types. I saw some examples here so I thought it would be good to make the realm parameter available there. Also fixed the test there as it was relying on regular expression.

About the signature position I read this, so although it might work I decided to stick with the spec.

I tested with a dozen of providers using OAuth1, everything seems to be fine.

[nylen]

Per discussion in #1122 I'm nominating this for $30 bounty. @seanstrom @FredKSchott and anyone else, let me know your thoughts on using this a a guinea pig for bounty :)

[seanstrom]

Im fine with this being a bounty, good work @simov 👍

[simov]

Not needed at all, but if you insist on giving a bounty for this, I'm fine with your decision. As for the unit testing the new modules, that would come too, still we're going to need our system like tests that involves the entire request object. So for now we can safely rely on what we already have as tests, as I'm not changing or adding behavior during this refactoring, after all it is a refactoring :)

[seanstrom]

Oh we will pay you whether you like it or not :).

[nylen]

Bountysource says this issue is closed for some reason. Closing and reopening to see if that fixes it.

[simov]

Do I need account on BountySource?

EDIT: Here is my new shiny account on BountySource https://www.bountysource.com/people/30682-simov in case this can be of any help

[nylen]

yeah, looks like if you log in and go here you may be able to request it:

https://www.bountysource.com/issues/7999758-refactor-oauth-into-separate-module/developers

[simov]

ok, posted my claim here https://www.bountysource.com/issues/7999758-refactor-oauth-into-separate-module/developers

[nylen]

bleh. looks like you are all set to be paid $0. I'll get in touch with bountysource support and see if they can help.

[simov]

Probably I have to enter the amount in my comment?

[nylen]

Reply from Bountysource support:

---

Hey James,

There's some quirkiness regarding how Bountysource handles GitHub Pull Requests at the moment. All bounties should be on open Issues, not pull requests, so that should be disallowed. There are actually two issues that you've highlighted here:

1. We shouldn't allow bounties on PRs -- We want to encourage people to focus on solving open issues, and not attempt to pay to get specific code push through.
2. We shouldn't allow developers to "claim a bounty" when none exists. There are no backers and there's no money to pay out, so claiming it is pointless.

Is there an issue that corresponds to that open PR (or can you create one)? I would suggest putting the bounty on that issue and, when the issue gets closed the developer can claim the bounty. As a backer of the issue you will have the ability to approve/deny the bounty claim.

Sorry about the rather poor experience in this situation, we have some edge cases to clean up :). Hope this answers your questions.

---

@simov you can claim the bounty on #1379.

[nylen]

merging, we'll take care of the bounty at #1379. Thanks @simov