Netflix: oauth_consumer_key is missing

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create a netflix provider and consumer.
2. Call provider.retrieveRequestToken( consumer, {OAuth.OUT_OF_BAND|
callbackurl} );

What is the expected output? What do you see instead?
I would expect to get back a proper authorization URL to present the user 
to use in a web browser. Instead, I receive:

<status>
  <status_code>
    400
  </status_code>
  <message>
    oauth_consumer_key is missing
  </message>
</status>

What version of the product are you using? On what operating system?
1.2, Windows 7. JDK 1.6.0_18.

Please provide any additional information below.
This is either an issue with Netflix's OAuth implementation or an issue 
with SignPost. I haven't read the OAuth spec, so I'm unsure which is 
incorrect. Regardless, if other services don't break if the consumer key 
is explicitly passed as a parameter, that should probably be default 
behavior.

Original issue reported on code.google.com by arcanef...@gmail.com on 12 Mar 2010 at 9:19

[GoogleCodeExporter]

I've seen people using Signpost with Netflix (there used to be a problem with 
blank 
tokens prior to version 1.2, but that was fixed). Can you please post 
executable code 
which I can use to reproduce this problem?

Please also try using the latest snapshot version (1.2.1-SNAPSHOT), which I've 
put on 
download yesterday.

Original comment by m.kaepp...@gmail.com on 13 Mar 2010 at 12:24

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

This is using 1.2.1-SNAPSHOT. Perhaps I'm tripped up in that Netflix requires 
additional parameterization to work with signpost, perhaps? This seems contrary 
to 
the goal that is an open standard. I used Twitter and another service provider, 
and 
both seem to work with 6 or so lines of code. Netflix is either nonstandard, or 
I'm 
unsure what's going on.

Code:
public static void main( String[] args ){
OAuthProvider netflixProvider = new 
DefaultOAuthProvider("http://api.netflix.com/
oauth/
request_token",
                "http://api.netflix.com/oauth/request_token", 
"https://
api-user.netflix.com/oauth/login");
OAuthConsumer netflixConsumer = new 
DefaultOAuthConsumer("6yt4ngc2rphvs6zvzj2zmkk5", 
"feHpMtQuat");
        OAuthConsumer consumer = netflixConsumer;
        OAuthProvider provider = netflixProvider;
        String authUrl = provider.retrieveRequestToken(consumer, "http://
stefankendall.com:8080/test.jsp");
        System.out.println("AuthURL: " + authUrl);
}

Original comment by arcanef...@gmail.com on 13 Mar 2010 at 5:02

[GoogleCodeExporter]

Thanks, I can reproduce this. This is indeed specific to Netflix, they seem to 
expect 
an oauth_consumer_key and application_name be part of the URL used to invoke 
their 
authorization page.

This is not demanded by the standard, but I believe it's free for the service 
provider to define any additional parameters required for this step.

Upon retrieving the request token, simply add this line of code to your 
application:

        authUrl = OAuth.addQueryParameters(authUrl, OAuth.OAUTH_CONSUMER_KEY, 
CONSUMER_KEY, "application_name", APPLICATION_NAME);

I'll close this ticket as invalid, since it's not a bug in Signpost, but feel 
free to  
reopen if you still have problems which you thing are related to the library, 
and not 
Netflix.

I have also added an example project for Netflix to 
http://github.com/kaeppler/signpost-examples

Original comment by m.kaepp...@gmail.com on 13 Mar 2010 at 7:40

• Changed state: Invalid

[GoogleCodeExporter]

This works swimmingly, although it upsets me that vendors can specify specific 
values, 
breaking any hope for cross-compatibility and a single code path for 
authentication.

The netflix example will definitely help those in the future, I think. Thanks 
for 
responding quickly and working to maintain this awesome library.

Original comment by arcanef...@gmail.com on 15 Mar 2010 at 6:15

[GoogleCodeExporter]

I couldn't agree more, especially since in this example both parameters seem 
completely unnecessary, because

a) the consumer key is already being sent as part of the message signature 
string in 
the previous step, and could be easily retrieved here using the token (there 
must be 
a mapping somewhere in their database linking the current token to a consumer)

b) if the provider has the consumer key (which identifies a consumer, i.e. an 
application), it should be equally trivial to look up the application name

but what can you do...

Original comment by m.kaepp...@gmail.com on 15 Mar 2010 at 6:24