2015-01-22 4 views
7

Goalaccesso LinkedIn API REST senza front-end (ad esempio OAuth2 redirect)

preleveranno gli aggiornamenti di una società salvarli in locale in un compito sfondo

Problema

questo dovrebbe essere fatto come un servizio di back-end senza alcuna interazione con l'utente. Potremmo fornire un account utente da utilizzare, ma l'autenticazione è un problema: non c'è letteralmente nessuno che risponda al reindirizzamento OAuth e non ci sia un URL di reindirizzamento pubblico da configurare, poiché si tratta di un servizio in background.

C'è un modo per accedere all'API senza avere un URL di reindirizzamento o un utente reale?

risposta

3

È possibile ottenere un token di accesso iniziale in un flusso di front end regolare, per te come sviluppatore di app tu stesso come utente di LinkedIn. Una volta ottenuto ciò, è possibile memorizzarlo nel back-end e utilizzarlo per 60 giorni per ottenere l'accesso alle API di LinkedIn.

Dopo 60 giorni è necessario aggiornare il token come documentato in: https://developer.linkedin.com/documents/handling-errors-invalid-tokens

Purtroppo LinkedIn non (ancora) supporta un flusso di aggiornamento autonomo, dove la vostra applicazione può ottenere un nuovo token di accesso con la presentazione di un token di aggiornamento su un backchannel. Quindi lo sviluppatore dovrà aggiornare il token di accesso con un login manuale ogni 2 mesi.

+0

Oh bene, questo è probabilmente il motivo per cui ho ricevuto sia la chiave API che il token e il segreto segreto utente AND OAuth dopo aver registrato la mia applicazione? –

+0

Dopo la prima fase di autenticazione sei pronto per andare sottoterra. Almeno fino a quando non sarà necessario eseguire nuovamente l'autenticazione (non so se LinkedIn abbia bisogno di questo, un altro fornitore che uso ti costringe a riacquistare l'autenticazione dopo un anno, i token possono essere aggiornati fino a quel momento). –

+0

Grazie, lo proverò e accetterò la tua risposta! –

1

Bene, è ancora tutto HTTP e HTML, quindi in effetti non vi è alcun motivo reale per mostrare la finestra di dialogo OAuth a un utente, a patto che sia possibile rimuovere le parti necessarie nella finestra di autenticazione HTML e inviare una risposta valida torna al server, usando il nome utente e la password dell'utente (che puoi ottenere da lui o salvalo tu stesso in un file di configurazione se sei tu).

Si noti che potrebbe esserci un problema legale se LinkedIn richiede di mostrare effettivamente la finestra di dialogo, oltre a questo, non c'è alcuna necessità tecnica.

+0

Perché il downvote? Sebbene ciò non sembri "la cosa giusta da fare", è valido da un concetto interno in cui automatizzi il tuo marketing, ad esempio attraverso la tua pagina di LinkedIn. –

+1

1. Sconfigge lo scopo di OAuth in cui le credenziali dell'utente non dovrebbero essere esposte al client/app 2. se LinkedIn volesse farlo, avrebbe offerto il flusso delle credenziali della password del proprietario della risorsa; 3. rende impossibile l'aggiornamento ad altre e l'autenticazione a più fattori 4. è fragile poiché dipende da Linkedin che non modifica il flusso di login 5. ecc. –

+0

@HansZ .: Che cos'è l'app, né un client? OP afferma chiaramente che viene eseguito in background, forse non esiste un'interfaccia utente! Forse c'è solo un database o un'altra fonte per scrivere in ... –