Play Framework [2.4.x] OpenID and Oauth — using PLAINTEXT for oauth_signature_method

[Gary Hewett]

I've opened this question on StackOverflow: http://stackoverflow.com/questions/31751260/play-framework-2-4-x-openid-and-oauth-using-plaintext-for-oauth-signature-m

I'm mentioning it here as I posted this as a bug fix / feature request on GitHub (https://github.com/playframework/playframework/issues/4924#event-370978560) and had it summarily dismissed with the comment that it needs to be "vetted" as actually needed by the group here.

The work-aournds (kludges) I have to date a complete crap (mutable code being a no no and all...) -- I merely wanted to get it functional so i could work on the balance of the API for a project while I figure out the better (best) way to handle this situation.

Looks like I'll have to write the layer myself for something that perhaps could have been included in the initial OAuth class design as a default parameter. (With some "connection" between the signing of the retrieveRequestToken and retrieveAccessToken methods versus the OAuthCalculator used after the initial handshakes are done).

I have no idea how to get things done within the community but I do believe the OAuth class would serve better if augmented to include these signing methods:

https://github.com/mojodna/oauth-signpost/tree/master/src/main/java/oauth/signpost/signature

Much appreciation to the people that provided the twitter example that I started working from: https://www.playframework.com/documentation/2.4.x/JavaOAuth

(Sorry I have no way of knowing which repository is actually "official" as there are so many of the forking things...)

[Gary Hewett]

I've made an appeal to the vendor for implementing HMAC-SHA1 signing as an option for OAuth requests. 

I've spend days souring the code and short of writing my own library I see no way round the way it is currently implemented. (Everything I might be able to change is at least  2 classes deep and mostly blocked by public static finals. 

The problem with writing my own is just how far back will I need to peal the onion?

Can anyone add ammunition for the appeal to the vendor as to why HMAC-SHA1 should be implemented OR even why PLAINTEXT should not (API is locked to HTTPS in their defence). 

Due to the way OAuth works (the METHOD is part of the param set) they could ADD HMAC-SHA1 support without breaking any existing applications (they have a LOT of apps using them so that would be an instant deal breaker otherwise) 

I've only pushed a measly $1.1M through their systems (using API tokens instead of OAuth) so I'm just a lowly toad and unlikely to get what I need without additional support.

Moving to Play was supposed to make my life as a developer easier :)

[Gary Hewett]

I have a work-able solution... -- watch the stack overflow space if you need it as I'll post it after it's cleaned up.