Qual è il modo standard per gestire le chiavi API di Twitter nelle applicazioni desktop GPL?

Durante lo sviluppo di un'applicazione desktop che deve accedere all'API di Twitter, è necessario in qualche modo passare la chiave API (chiave utente specifica dell'applicazione e segreto utente) per l'applicazione all'utente. L'API TOS di Twitter afferma che la chiave API dell'applicazione non può essere pubblicamente disponibile e, se ciò accade, viene ripristinata. Quando tale applicazione è in GPL, il che significa che lo sviluppatore deve fornire il codice sorgente all'utente, in che modo tale utente sarebbe in grado di ottenere la chiave API senza che sia disponibile pubblicamente? C'è un modo standard per gestire questo problema? Grazie.Qual è il modo standard per gestire le chiavi API di Twitter nelle applicazioni desktop GPL?

Modifica: Per chiarire la situazione, stavo memorizzandoli in testo nel mio codice per cree.py per quanto riguarda una decisione consapevole. Ma ieri Twitter team di supporto mi ha contattato che hanno azzerato la mia chiave e il loro ragionamento è stato il seguente:

C. Non dovrebbe sollecitare le chiavi di consumo di un altro sviluppatore o segreti di consumo soprattutto se saranno conservati o utilizzati per le azioni esterne del controllo di quello sviluppatore. Chiavi e segreti compromessi verranno ripristinati da Twitter. Ad esempio, i servizi online che richiedono questi valori per fornire un servizio di "tweet-branding" non sono consentiti. https://dev.twitter.com/terms/api-terms Se le chiavi di un'applicazione sono pubblicate pubblicamente, consente a parti esterne di dirottare l'accesso all'API dell'applicazione. Questo presenta un enorme rischio di abuso e, come tale, abbiamo ripristinato le tue chiavi API. Si prega di assicurarsi che queste chiavi non siano pubblicate di nuovo pubblicamente.

Grazie, Twitter Privacy API

fonte

2011-10-07 Yiannis Kakavas

Beh, se twitter insiste per proteggerti, dovrai interrompere cree.py in due, una parte essendo un server proxy gestito da te e solo attraverso il quale ogni variante cree.py chiede a Twitter. Altrimenti, dovresti avere ognuno che vuole usare cree.py avere il loro mazzo di chiavi – adamo

Beh, erano piuttosto assoluti riguardo al "sistema d'onore" che rompeva i loro TOS. Credo che le loro API, le loro regole. Proxyying tutte le richieste sarebbe ingombrante, suppongo che potrei semplicemente installare un server che alimenta la chiave API dell'applicazione alla prima esecuzione su ciascun client. Ma ci sono abbastanza applicazioni desktop GPL che accedono all'API di Twitter (ad esempio, i client di Twitter), quindi sto cercando pensieri sulla procedura "standard". –

Beh, TTYtter utilizza evidentemente il sistema di onore:

# yes, this is plaintext. obfuscation would be ludicrously easy to crack, 
# and there is no way to hide them effectively or fully in a Perl script. 
# so be a good neighbour and leave this the fark alone, okay? stealing 
# credentials is mean and inconvenient to users. this is blessed by 
# arrangement with Twitter. don't be a d*ck. thanks for your cooperation. 
$oauthkey = (!length($oauthkey) || $oauthkey eq 'X') ? 
     "XXXXXXXXXXXXXXXXXXXXX" : $oauthkey; 
$oauthsecret = (!length($oauthsecret) || $oauthsecret eq 'X') ? 
     "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" : $oauthsecret;

(ho sostituito le chiavi attuali con Xs, per rendere un po 'meno probabile che chiunque si prenderà la briga di abusarne, ma state certi che sono presenti per intero nella fonte reale!)

Inoltre, non vedo nulla nello Rules of the Road in realtà richiede di mantenere queste cose segrete: la cosa più vicina che vedo è l'affermazione "Le chiavi e i segreti compromessi verranno ripristinati da Twitter."; in realtà non dicono mai cosa significhi "compromesso", però.

fonte

2011-10-07 04:13:23 SamB

Ho aggiornato la domanda per chiarire ulteriormente. Stavo usando il sistema d'onore per 7 mesi e stava funzionando, ma ieri il supporto API di Twitter ha deciso che avrebbe dovuto "proteggermi" e reimpostare le mie chiavi. –

Potrei essere denso qui, ma perché non li si memorizza in un file di configurazione, nel registro di Windows ecc e li si preleva da lì? Quindi distribuire l'applicazione senza il file e il gioco è fatto.

fonte

2012-06-15 09:57:46 reiniero

Il problema con questo piano è che richiede ad ogni utente di ottenere la propria chiave API. Che probabilmente non vorranno fare. È una soluzione ragionevole se stai scrivendo una libreria che ti aspetti che gli altri utenti si configurino da sé, ma non così grande se ti aspetti che la maggior parte degli utenti desideri semplicemente scaricare i file binari ed eseguirli. –

È possibile adattare l'applicazione in modo che il proprio uso ottenga il proprio access_token e access_token_secret una volta (ad esempio utilizzando l'autenticazione OOB/PIN), quindi memorizza le credenziali. Da lì in avanti (e al riavvio dell'applicazione), vengono autenticati. – reiniero

Ciò che @me_and ha significato con la chiave API è la chiave del consumatore e il segreto del consumatore, non il token di accesso e il segreto. Come dici tu, il token di accesso e il segreto vengono gestiti tramite l'autenticazione OOB/PIN alla prima esecuzione. Questo non è un problema. Tuttavia, questa domanda riguarda come distribuire e archiviare la chiave del consumatore e il segreto del consumatore nelle applicazioni desktop. –

Forse un'altra soluzione potrebbe essere quella di utilizzare un server, il server interagisce con l'API di Twitter, e il tu richiedere informazioni al server con l'applicazione desktop

Come quella, la chiave API è memorizzata solo sul server e nessun utente può ottenerlo.

fonte

2013-06-22 07:27:34 konfiot

Qual è il modo standard per gestire le chiavi API di Twitter nelle applicazioni desktop GPL?

risposta

Problemi correlati