Perché non posso generare un token oauth valido utilizzando l'arricciatura da riga di comando per l'API di LinkedIn?

Question

Durante il test dell'API di LinkedIn e il tentativo di creare un pacchetto smart Meteor JS per l'autenticazione con il provider OAuth di LinkedIn, ho eseguito un roadblock totale.

In seguito these directions, sono stato in grado di generare con successo un oauth_token per l'uso in una richiesta di autorizzazione, sotto forma di:

https://www.linkedin.com/uas/oauth/authorize?oauth_token={oauth_token} 

Quando mettere che nel browser con il token generato da uno script Ruby che si presenta così:

require 'oauth' 

api_key = '{linkedin api key}' 
api_secret = '{linkedin api secret}' 

configuration = { :site => 'https://api.linkedin.com', 
          :authorize_path => '/uas/oauth/authenticate', 
          :request_token_path => '/uas/oauth/requestToken', 
          :access_token_path => '/uas/oauth/accessToken' } 

consumer = OAuth::Consumer.new(api_key, api_secret, configuration) 

request_token = consumer.get_request_token 
puts request_token.params[:oauth_token] 

posso quindi facilmente scaricare il token come parametro querystring nel browser, utilizzando il sopra URI, e vedere la finestra di dialogo autorizzazioni LinkedIn.

La finestra di autenticazione LinkedIn che viene visualizzata con un token valida:

Purtroppo, quando si tenta di scrivere una richiesta ricciolo nella riga di comando, il oauth_token che viene generato non riesce quando viene utilizzato in quello stesso URL. In effetti, risulta che linkedin risponde con un errore 500 e il browser mostra una finestra di errore standard di 500. La risposta arriva senza ulteriori dettagli:

Ecco il codice che è simile a quello che avevo realizzato nel mio ricciolo richiesta di linkedin per una nuova oauth_token:

alex@alex-mac accounts-linkedin (fixes_for_meteor_0_5_4)* $ cat linkedin_oauth_gen.sh 

curl -X POST https://api.linkedin.com/uas/oauth/requestToken --verbose --header 'Authorization: OAuth oauth_nonce="0d9a3e40660811e2bcfd0800200c9a66",oauth_timestamp="1359019570",oauth_version="1.0",oauth_signature_method="HMAC-SHA1",oauth_consumer_key="{oauth_consumer_key}",oauth_signature="{oauth_signature}"' 

Vale la pena notare che che avevo usato LinkedIn's OAuth test console per generare l'intestazione Autorizzazione.

Questo è importante, perché ho lo stesso problema quando si tenta di implementare funzionalità simili nel mio pacchetto smart Meteor JS.

La mia domanda principale, tuttavia, è il motivo per cui nel mondo posso farlo con il codice ruby ​​sopra, ma quando si usa un semplice comando di ricciolo, il token non sembra essere generato validamente (o semplicemente LinkedIn non vuole per onorarlo) ...

Answer 1

Come al solito, il diavolo è il più piccolo dei dettagli.

Per risolvere questo problema, ho utilizzato il sempre meraviglioso Charles Proxy per spiare le richieste che il mio script ruby ​​stava facendo tramite la libreria oauth.

Come si è scoperto c'erano due questioni distinte con quanto stavo cercando di fare richieste da curl e da meteora che ho scoperto per spiare la richiesta di rubino successo, mentre guardando indietro al mio codice e scherzi con il oauth_callback Autorizzazione parametro header per decodificare il problema.

Uno di questi problemi, o in combinazione, ha causato la generazione di un token oauth non valido e non riconoscibile. Invece di restituire un 401, linkedin ha generato un token! Ahimè, questo gettone era inutile.

Ecco 2 distinti intestazioni richiesta di autorizzazione che falliscono (con motivi dopo ogni):

Authorization: OAuth oauth_body_hash="2jmj7l5rSw0yVb%2FvlWAYkK%2FYBwk%3D", oauth_callback="http%3A%2F%2Flocalhost%3A3000%2F_oauth%2Flinkedin%3Fclose", oauth_consumer_key="*********", oauth_nonce="SJ3DSTHLh0T4UcqzYOUOqubIeWN9FERCePm5ro35EY", oauth_signature="*********", oauth_signature_method="HMAC-SHA1", oauth_timestamp="1359081520", oauth_version="1.0" 

In questo primo esempio, il problema è che il parametro oauth_callback ha un parametro querystring valido. Si scopre che avere un parametro di stringa di query come ?close senza un valore, come in ?close=true, provoca la completa rimozione della richiesta. Ancora non so esattamente perché, ma sembra che sia così.

Authorization: OAuth oauth_body_hash="2jmj7l5rSw0yVb%2FvlWAYkK%2FYBwk%3D", oauth_callback="http%3A%2F%2Flocalhost%3A3000%2F_oauth%2Flinkedin%3Fclose", oauth_consumer_key="*********", oauth_nonce="SJ3DSTHLh0T4UcqzYOUOqubIeWN9FERCePm5ro35EY", oauth_signature="*********", oauth_signature_method="HMAC-SHA1", oauth_timestamp="1359081520", oauth_version="1.0" 

In questo secondo esempio, il problema è che oauth_callback ha localhost nel suo dominio. Si scopre che alcuni provider oauth, di cui linkedin è uno, non amano i nomi host nel parametro oauth_callback (vs FQDN o indirizzi IP). Mi fa capire perché Dobbiamo usare 127.0.0.1. Non c'è una buona ragione, ma solo è. Lame, ma vero.

Questo funziona:

Authorization: OAuth oauth_body_hash="2jmj7l5rSw0yVb%2FvlWAYkK%2FYBwk%3D", oauth_callback="http%3A%2F%2F127.0.0.1%3A3000%2F_oauth%2Flinkedin%3Fclose%3Dtrue%26state%3D0e314d0d-a5ca-40ca-8fcd-caa1cfce3ed4", oauth_consumer_key="*********", oauth_nonce="0KBnMSMI8NNk1cXn0YyTRpUnPdnqAX7F06KEloh9bs", oauth_signature="*********", oauth_signature_method="HMAC-SHA1", oauth_timestamp="1359082177", oauth_version="1.0" 

Nota: ho sostituito oauth_consumer_key e oauth_signature valori con ********* per ovvi motivi di proteggere le chiavi e la rimozione della possibilità di reverse engineering del mio segreto.