Two-legged oAuth authentication method

Would love to see this.

This looks great.

This approach re-uses existing mechanisms and checks for authentication type 'consumer' instead of 'token'.
Tested with Drupal 7
Unfortunately, while there's a form to edit this already present, I've no idea how it's supposed to be called.

apologies for the conflicting patch with above, but I've spent the last week building this by slowly testing REST and XMLRPC across some - it turns out buggy - tools. If anyone is interested in a python test or a jsAuth-based test (Titanium/Appcentre mobile dev) I'd love to post them.

How were you able to use oAuth without this patch?

#1154420: Readd support for rich options for resources - needed by auth mechanism

I couldn't use patch #5 - I manually updated the record to test it. So either combine #4 with the readd patch - or consider them separate parts, I'd think.
I myself wouldn't use the first patch - while the form looks like it's nice, it adds a second path of logic that isn't as obvious unless you've spent a few days reading OAuth documents.

As I understand it:
- Three legged (token) OAuth - B gives A a key, A signs into B, gets asked to confirm, B sends A a token via callback (or oob - but I don't know how this will work in drupal) and A uses token to communicate.
- Two legged (consumer key) OAuth - B gives A a key, A signs into B using key and allowed access as per that key on that account.

I'm using the second because I'm working with phone apps, where the token method isn't reasonable without some way of passing the token back out-of-band.

Oh, my test client is at this point

The first patch 'modifies' the path based on a second rule. Basically : if the value is set, bypass endpoint configuration and force two-legged. While it's probably easier to set up, it makes the logic a bit more complicated. It's not likely to break anything - unless one was using something other than token authentication on the endpoint (currently not possible without manually updating database).
Also, should there be any further auth mechanisms set up, it makes it a bit harder to spot where to add them. From what I can tell, the original forms for endpoint auth were (note, there's nothing that says how they work): unsigned_consumer, consumer, token
where it defaulted to token if none were present. The specs don't suggest any more will be added, so perhaps simplifying to 'two legged' or 'three legged' might be the way to go.

Really, the first patch is the faster to get "to operational". Use it where one wants a special case where "two legged OAuth" is intended as only or primary.
I hope my feedback helps explain why I took the route I did.

It sounds to me like one way is, an end all be all for the specific endpoint, and the second is for individual resources/methods.

I don't feel like we should combine the patches between this node and #1154420 b/c one is certainly a functionality request for services and the other is certain and oAuth fix for services. While they are btw needed for this to work its not needed.
What I need from you guys is to tell me the exact things you need in order for this two work.

Im fine with combining the two patches here as I understand both use cases. More granular settings need to override the overall setting etc.

And lastly we need to make sure it all works so Im all down for helping and Im gonna start by finishing #1154420: Readd support for rich options for resources - needed by auth mechanism.

Unfortunatly I don't think this will make it into 3.1 as were going to release that very soon.

I like #2 in the list of items on comment #13 :P

I've come up with a better approach for what I was working with - this doesn't conflict with the readd work, although I'm not entirely sure what the readd work is supposed to do. On mine, it does nothing.

So this patch combines my previous one with a menu to configure it.
It appears on services under "authentication"

under 'context' is added 'authorization' and 'required authentication' - allowing for two-legged, three-legged and potentially 'none', as well as other mechanisms if anyone dreams up any. (ignoring unsigned_consumer for now)

tested with services-3.1

I think this looks great.and it seems to work from my quick overview.

Im happy with committing #15 once its been ported to D6.

Here's an attempt at a D6 version of the patch. I haven't got any services installations under D6, so it's relatively untested.

Looks good.

RTBC

Rerolling patch from #15 to play nicely with Drush make.

Oops. Wrong patch; _this one_ should work with Drush.

@jobeirne we have policy of fixing in d7 and then backporting - I have tidied up the patch in #18 and committed that. If you could re-roll a patch that makes the changes required for drush make we will certainly look to get them committed, this way we end up with a patch that is kept in sync across the 2 versions.

Patch in #18 has been committed.

The issue was that patches for d6 and d7 didn't apply cleanly with git apply then I assume. (I not a drush make user). Marking the issue as fixed if there are problems shout!