¿Cuál es la forma estándar de manejar las claves API de Twitter en las aplicaciones de escritorio GPL?

Al desarrollar una aplicación de escritorio que necesita acceder a la API de Twitter, se debe pasar de alguna manera la clave de API (clave de consumidor y secreto de consumidor de aplicación específica) para la aplicación al usuario. Los TOS de API de Twitter indican que la clave de la API de la aplicación no puede estar públicamente disponible y, si eso sucede, la restablecen. Cuando esa aplicación está bajo GPL, lo que significa que el desarrollador necesita proporcionar el código fuente al usuario, ¿cómo podría ese usuario obtener la clave API sin que esté disponible públicamente? ¿Hay una forma estándar de manejar este problema? Gracias.¿Cuál es la forma estándar de manejar las claves API de Twitter en las aplicaciones de escritorio GPL?

Editar: Para aclarar la situación, estaba almacenándolos en texto sin formato en mi código para cree.py en cuanto a una decisión consciente. Pero ayer el equipo de soporte de Twitter se puso en contacto conmigo que han reseted mi llave y su razonamiento fue el siguiente:

C. Usted no debe solicitar claves de consumo de otro desarrollador o secretos de consumo, especialmente si van a ser almacenados o usados con acciones fuera del control de ese desarrollador. Las claves y secretos comprometidos serán reiniciados por Twitter. Por ejemplo, los servicios en línea que solicitan estos valores para proporcionar un servicio de "tweet-branding" no están permitidos. https://dev.twitter.com/terms/api-terms Si las claves de una aplicación se publican públicamente, permite a las partes externas secuestrar el acceso a la API de la aplicación. Esto presenta un enorme riesgo de abuso y, como tal, hemos restablecido sus claves API. Asegúrese de que estas claves no se vuelvan a publicar públicamente.

Gracias, Twitter Política de API

Fuente

2011-10-07 Yiannis Kakavas

Bueno, si Twitter insiste en protegerte, deberás dividir cree.py en dos, una parte es un servidor proxy mantenido por ti y solo a través del cual cada variante de cree.py pregunta a twitter. De lo contrario, debes tener a cada uno que quiera usar cree.py tener su conjunto de claves – adamo

. Bien, fueron absolutamente absolutos sobre el "sistema de honor" rompiendo sus TOS. Supongo que su API, sus reglas. Proxingar todas las solicitudes sería engorroso, supongo que podría simplemente configurar un servidor que alimente la clave API de la aplicación en la primera ejecución de cada cliente. Pero hay suficientes aplicaciones de escritorio GPL que acceden a la API de Twitter (es decir, clientes de Twitter), así que estoy buscando ideas sobre el procedimiento "estándar". –

Bueno, TTYtter, evidentemente, utiliza el sistema de honor:

# 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;

(que han reemplazado a las teclas reales con Xs, para que sea un poco menos probable que ¡cualquiera se tomará la molestia de abusar de ellos, pero puede estar seguro de que están presentes en su totalidad en la fuente real!)

Además, no veo nada en el Rules of the Road en realidad requiriendo para mantener estas cosas en secreto: lo más parecido que veo es la declaración "Las claves y secretos que están en peligro serán reiniciados por Twitter"; Sin embargo, en realidad nunca dicen qué significa "comprometido".

Fuente

2011-10-07 04:13:23 SamB

Actualicé la pregunta para aclarar más. Estaba usando el sistema de honor durante 7 meses y funcionaba, pero ayer, el apoyo de la API de Twitter decidió que debería "protegerme" y restableció mis claves. –

Podría ser denso aquí, pero ¿por qué no los almacena en un archivo de configuración, el registro de Windows, etc. y los obtiene de allí? Luego, distribuya la aplicación sin el archivo, y listo.

Fuente

2012-06-15 09:57:46 reiniero

El problema con este plan es que requiere que cada usuario obtenga su propia clave de API. Lo cual es probable que no quieran hacer. Es una solución razonable si está escribiendo una biblioteca que espera que otros usuarios se configuren a sí mismos, pero no tanto si espera que la gran mayoría de sus usuarios simplemente quiera descargar los binarios y ejecutarlos. –

Puede adaptar su aplicación para que su uso obtenga su access_token y access_token_secret una vez (por ejemplo, usando la autenticación OOB/PIN) y luego almacene las credenciales. Desde allí en adelante (y al reiniciar la aplicación), están autenticados. – reiniero

Lo que significa @me_and wih API key es la clave del consumidor y el secreto del consumidor, no el token de acceso ni el secreto. Como dices, el token de acceso y el secreto se manejan a través de la autenticación OOB/PIN en la primera ejecución. Esto no es un problema. Sin embargo, esta pregunta se trata de cómo distribuir y almacenar la clave del consumidor y el secreto del consumidor en aplicaciones de escritorio. –

Quizás otra solución sería utilizar un servidor, el servidor interactúa con la API de Twitter, y de la que solicite información a su servidor con su aplicación de escritorio

Al igual que, la clave de la API solamente se almacena en el servidor , y ningún usuario puede obtenerlo.

Fuente

2013-06-22 07:27:34 konfiot

¿Cuál es la forma estándar de manejar las claves API de Twitter en las aplicaciones de escritorio GPL?

Respuesta

Cuestiones relacionadas