Come posso memorizzare la chiave utente OAuth v1 e il segreto per un client Twitter desktop open source senza rivelarlo all'utente?

Ho trovato una risposta che rispecchia il percorso che stavo considerando andando su hueniverse . L'articolo Oltre il flusso di reindirizzamento web OAuth , offre alcuni suggerimenti, uno di loro è un URL web che trasmette il processo di scambio di token. Devo trovare un modo per autenticare correttamente che la mia app è ciò che richiede l'autenticazione a questa pagina proxy. Tuttavia, è possibile.

Potrei sbagliarmi, ma se impacchetti i tasti con l'app desktop o mobile, open source o meno, è possibile accedervi. Se servizi come Twitter e Tumblr ci obbligano a utilizzare l'API OAuth, abbiamo due opzioni:

• imposta un servizio proxy di autenticazione per ogni app
• raggruppa le chiavi con l'app

Il primo è più difficile e costoso, non necessariamente mantenibile per le piccole e open source. Quest'ultimo significa che l'app può essere bloccata, una volta che gli spammer hanno rubato le chiavi. Poiché Twitter e Tumblr non offrono ancora un'opzione migliore e avvitano tutti i client desktop, inclusi i client Open Source, c'è una proposta per distribuisce le chiavi" Big Fish "e le usa come fallback .

Infine, c'è un'opzione per forzare ogni utente a ottenere le chiavi API.

Sezione 4.6 di RFC 5849 , che definisce OAuth 1, afferma che il segreto del consumatore non è mai stato inteso per l'utilizzo da parte dei consumatori desktop, nonostante l'uso di Twitter nella pratica. Come ha sottolineato Nelson Elhage in " Caro Twitter ", Twitter può e fa terminare le chiavi dei consumatori dei client desktop , a condizione che il cliente non sia troppo grande per fallire. Ma ci sono due soluzioni alternative per consentire l'uso di OAuth 1 in un'applicazione desktop o mobile.

Un modo è quello di proxy l'intero protocollo Twitter attraverso un server che gestisci. In questo modo, il segreto dell'utente rimane sul tuo server. Questa è la soluzione alternativa consigliata da Dick Hardt , editor della specifica OAuth 1. Questa soluzione alternativa non affronta il costo del funzionamento di questo server.

L'altro modo, come suggerito in un post di Raffi Krikorian allo sviluppo di Twitter parlare gruppo di Google e un post di Chris Steipp ad una mailing list di Wikipedia, è quello di "fare in modo che ogni utente registri la propria copia dell'applicazione desktop come proprio consumatore". Quindi l'utente copia e incolla la chiave del consumatore e il segreto del consumatore appena registrati nella tua applicazione. Il manuale della tua applicazione dovrebbe quindi includere istruzioni dettagliate su come registrare una nuova applicazione sul sito degli sviluppatori di Twitter. Questa limitazione ufficiale ha alcuni problemi pratici:

• Il tuo cliente dovrà affrontare uno svantaggio dell'usabilità rispetto a noti clienti proprietari.
• Il modulo per creare una nuova app non sembra offrire un modo per precompilare i campi richiesti. Ciò significa che dovrai aggiornare la procedura di registrazione nel tuo manuale ogni volta che Twitter cambia la procedura per la registrazione di un'app.
• L'accordo con gli sviluppatori richiede che gli utenti abbiano raggiunto l'età legale per stipulare un contratto vincolante. Ciò significa che un utente della tua applicazione di età compresa tra 13 e 17 anni deve avere un genitore accettare l'accordo per conto dell'utente.
• La Politica per gli sviluppatori di Twitter proibisce le applicazioni di registrazione di massa e il "nome squatting", che definisce come "invio di più applicazioni con la stessa funzione con nomi diversi. " Non sono a conoscenza di precedenti in merito al fatto che Twitter abbia trattato utenti non collegati che hanno registrato copie separate di un'applicazione come "nome squatter".

Risponderò, ma ti avverto che non mi sono occupato di questo da solo, sto uscendo dalle migliori pratiche e dalle esperienze pertinenti esistenti;

Non me ne preoccuperei troppo. Se il tuo client è open source, allora avranno comunque accesso alla fonte, e provare a controllare ciò che fanno con il tuo programma va comunque contro la natura dell'open source (anche se, cosa importante, ciò che stai cercando di fare fa non ).

Se qualcuno ha abbastanza conoscenze per eseguire il debug del tuo programma ed estrarre la tua chiave, probabilmente sapranno come fare di più e potresti davvero perdere tempo a cercare di bloccare ulteriormente.

Per precauzione, cambierei le chiavi ogni tanto (se possibile), ma se tutto ciò che possono fare è fingere di essere il tuo programma piuttosto che non sembrare troppo serio per me.

Completa divulgazione, non ho familiarità con le API di Twitters, le API di twitterizer, i requisiti di OAuth, o qualsiasi altra cosa che ho detto possa sembrare discutibile;)

La chiave del consumatore e il segreto sono legati all'applicazione e non all'utente. Con questo in formazione, il fornitore OAuth sa con quale applicazione sta trattando. Il resto, Access token e secret sarà ottenuto dopo che i primi passi sono stati fatti.

Vedi questo post del blog per ulteriori informazioni in quanto mostra come il protocollo funziona.