Archive

Articles taggués ‘OAuth’

Client Twitter en ligne de commande

06/05/2012 un commentaire

Voici un outil très intéressant en invit de commande (CLI), simple à utiliser et qui permet d'automatiser des actions sur Twitter. Merci à son auteur @sferik, porteur du projet sous hébergement GitHub.

L'outil ne remplacera pas Tweet Adder ou Socialomate, ni les meilleurs clients Twitter. Complémentaire à Tyrs, il réjouira les inconditionnels de la ligne de commande.

L'outil, au nom de code t, a été développé en Ruby (versions supportées). Inspiré des commandes SMS de Twitter, il permet de gérer plusieurs comptes et propose une liste importante de commandes très utiles.
 
J'ai installé le client Twitter t sous environnement Ubuntu.
 
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 10.04.4 LTS
Release: 10.04
Codename: lucid
 
Installation du client :
 
$ sudo apt-get install gcc g++ build-essential libssl-dev libreadline5-dev zlib1g-dev linux-headers-generic libsqlite3-dev checkinstall
$ wget ftp://ftp.ruby-lang.org//pub/ruby/1.9/ruby-1.9.3-p0.tar.gz
$ tar -xvzf ruby-1.9.3-p0.tar.gz
$ cd ruby-1.9.3-p0/
$ ./configure –prefix=/usr/local/ruby
$ make
$ checkinstall
 
On désintalle tous les Gems Ruby :
 
$ sudo yes | gem cleanup && gem list | awk '{print $1}' | xargs gem uninstall
 
On installe le Gem t et ses dépendances.
 
$ sudo gem install t
[sudo] password for XXXX: 
Successfully installed t-0.9.3
1 gem installed
Installing ri documentation for t-0.9.3…
Installing RDoc documentation for t-0.9.3…
…
 
On complète le chemin de recherche (PATH) de l'utilisateur :
 
$ echo 'export PATH=$PATH:/usr/local/ruby/bin' >> ~/.bashrc
 
On crée une nouvelle application sur Twitter : http://dev.twitter.com/apps/new
 
On modifie les droits d'accès (onglet –> Settings) en choisissant : Read, Write and Access direct messages
 
On récupére les autorisations (onglet –> Details –> OAuth settings) : 
 
$ t authorize -c Consumer_key -s Consumer_secret
In a moment, you will be directed to the Twitter app authorization page.
Perform the following steps to complete the authorization process:
  1. Sign in to Twitter
  2. Press "Authorize app"
  3. Copy or memorize the supplied PIN
  4. Return to the terminal to enter the PIN
 
Press [Enter] to open the Twitter app authorization page. 4
 
Paste in the supplied PIN: XXXXXX
Authorization successful.
 
 
Les informations concernant le profil utilisateur sont stockées au format YAML dans le home utilisateur ~/.trc (autorisation d'accès 0600). A noter que toute personne ayant accès à ce fichier pourra usurper votre identité sur Twitter.
 
Utilisation du client :
 
La terminologie utilisée dans les commandes change quelque peu de celle employée sous Twitter. L'auteur s'en explique dans sa documentation.
 
Dans ce billet, nous ne listerons pas les nombreux exemples d'utilisation de l'outil. Quelques-uns sont publiés ici.
 
L'outil va permettre de scénariser des envois, en envoyant qu’aux bonnes personnes, en personnalisant le message avec le nom de chaque utilisateur, à une heure bien définie etc.
Le scénario peux-être de définir un message et de programmer (man at) un envoi en "broadcast" à tous vos followers (attention toutefois à l'utilisation abusive de DM).
 
Comment tirer profit de cet outil ? voici un exemple d'utilisation.
 
 
Il me semble que chercher les abonnements d’un utilisateur que l'on suit tout particulièrement est l’un des moyens pour trouver des personnes intéressés par votre thème d'activité. 
 
Le script suivant (à optimiser certainement) :
 
- recherche les abonnements (followings) d'un utilisateur Twitter et les suit automatiquement
- détermine le nombre de personnes à suivre (200)
- détermine un délai aléatoire entre chaque follow (entre 3 et 7 minutes)
- stoppe les invitations lorsque le ratio follow/followed (1/10) est atteint
 
#!/bin/sh
 
ratio=0.1
 
f_ratio ()
{
        count=`t users -l $account | tail -1 | awk '{print $8,$9}'`
        var1=`echo $count | cut -d' ' -f1`
        var2=`echo $count | cut -d' ' -f2`

        res=$(echo "scale=2;$var2/$var1" | bc -l 2>/dev/null)

}
 
echo -n "Followed by Twitter user : "
read username
 
t whois $username > /dev/null 2>&1
EC=$?
if [ $EC -ne 0 ]; then
        echo "User not found"
        exit 0
else
       # select active account
       account=`t accounts | grep -iB1 active | grep -iv active`
 
       if [ -f ~/new_followings ]; then
              rm ~/new_followings
       fi
       t followings -rf $username > ~/followedBy_$username
       t followings > ~/followings
 
       # max 200 users to follow per day (reasonable value)
       for user in  `cat ~/followedBy_$username | grep -iv $account| head -n 200`
       do
              # following to follower ratio reaches 10 to 1
              f_ratio
              if [ $(echo "$res - $ratio" | bc | tr -d .) -lt 0 ]; then
                     echo "Stop sending follows. You're following 10 users for every 1 user following you."
                     exit 0
              else
                     sleep $(( RANDOM%5+3 ))m
                     val=`grep -i $user ~/followings`
                     # if you don't already follow him, you should
                     if [ -z "$val" ]; then
                            t follow $user
                          # he doesn't follow you right now
                          echo $user >> ~/new_followings
                     fi
              fi
       done
fi
On vérifie après quelques jours si les utilisateurs vous suivent en retour et dans le cas contraire, on les désabonne.
 
#!/bin/sh
 
#  list of the people who follow you on Twitter
t followers > ~/followers
for user in  `cat ~/new_followings`
do 
       sleep $(( RANDOM%5+3 ))m
       val=`grep -i $user ~/followers`
       # unfollow non reciprocal follows that were followed
       if [ -z "$val" ]; then
              t unfollow $user
       fi
done

Il faut savoir que la limite imposée par Twitter (https://dev.twitter.com/docs/auth/oauth/faq) est de 350 requêtes authentifiées par heure via le protocole libre OAuth.

Voici le schéma simplifié du processus d'une authentification OAuth :

"Resource owner" représente l'utilisateur propriétaire de la ressource.

"Client" représente l'application qui accède aux ressources protégées de l'utilisateur propriétaire après que des droits d'accès aient été explicitement accordés par ce dernier.

"Authorization Server" représente l'application qui autorise l'application cliente à accéder aux ressources de l'utilisateur. En réponse à une demande d'autorisation, il transmet au client un jeton d'accès.

"Resource Server" représente le serveur qui héberge les ressources protégées de l'utilisateur propriétaire. Le serveur de ressources utilise le jeton d'accès pour le traitement des requêtes.

Categories: Système Tags: , , ,