Notifications X (anciennement Twitter)

Aperçu

• Source: https://x.com/
• Prise en charge des images: Non
• Prise en charge des pièces jointes: Oui
• Limites de caractères des messages:
  • Private Message: 25000
  • Tweet: 280
• Créer votre URL Apprise

Configuration du compte

Vous devez creer un compte developpeur X sur developer.x.com.

Les messages directs X sont un peu plus complexes a configurer que certains autres services de notification. Voici donc un resume rapide de ce qu’il faut savoir et faire pour envoyer des notifications avec cet outil.

Si un Projet et une App Existent Deja

Lors de la creation de votre compte developpeur X, un projet et une application par defaut ont peut-etre deja ete crees. Vous pouvez utiliser cette application ; c’est elle qui permettra l’envoi de vos messages directs.

1. Commencez par regenerer les cles API. Pour cela, ouvrez le nom de l’application dans Projects & Apps dans le menu de gauche, puis allez dans Consumer Keys depuis l’onglet “Keys and tokens”. Une fois generees, copiez-les dans un endroit sur. Il s’agit des Consumer Keys.
   

2. Accordez ensuite les autorisations necessaires pour publier des posts ou envoyer des messages directs. Apres avoir clique sur le nom de l’application dans Projects & Apps, cliquez sur Set up dans la section User authentication settings.
   
   Dans la page User authentication settings, configurez :

   • App permissions
     Selectionnez Read and write si vous souhaitez seulement publier. Si vous voulez envoyer des DMs, choisissez Read and write and Direct message.
   • Type of App
     Selectionnez Web App, Automated App or Bot
   • App info
     Saisissez n’importe quelle URL dans Callback URI / Redirect URL et Website URL. Si vous utilisez Apprise pour publier ou envoyer des DMs, la valeur exacte n’a pas d’importance.

   Une fois tout saisi, cliquez sur Save.

3. Enfin, vous devrez regenerer les jetons d’acces. Cela se fait dans Authentication Tokens depuis l’onglet “Keys and tokens”. Une fois generes, copiez-les dans un endroit sur.
   

Si Aucun Projet ni Aucune App n’Existent

1. Vous devez d’abord creer un projet et une application X, et non une Standalone app, depuis developer.x.com. C’est via cette application X que vous pourrez envoyer vos DMs.
   
   X vous demandera de justifier votre besoin si vous decrivez le but de votre application.

2. Une fois l’application creee, vous verrez les jetons API a l’ecran ; copiez-les dans un endroit sur. Il s’agit des Consumer Keys.
   

3. Accordez ensuite les autorisations necessaires pour publier des posts ou envoyer des DMs. Apres avoir clique sur le nom de l’application dans Projects & Apps, cliquez sur Set up dans la section User authentication settings.
   
   Dans la page User authentication settings, configurez :

   • App permissions
     Selectionnez Read and write si vous souhaitez seulement publier. Si vous voulez envoyer des DMs, choisissez Read and write and Direct message.
   • Type of App
     Selectionnez Web App, Automated App or Bot
   • App info
     Saisissez n’importe quelle URL dans Callback URI / Redirect URL et Website URL. Si vous utilisez Apprise pour publier ou envoyer des DMs, la valeur exacte n’a pas d’importance.

   Une fois tout saisi, cliquez sur Save.

4. Enfin, vous devrez generer les jetons d’acces. Cela se fait dans Authentication Tokens depuis l’onglet “Keys and tokens”. Une fois generes, copiez-les dans un endroit sur.
   

Vous devriez maintenant disposer des 4 jetons suivants prets a l’emploi :

• une Consumer Key, c’est-a-dire une cle API ;
• un Consumer Secret, c’est-a-dire un API Secret ;
• un jeton d’acces ;
• un secret de jeton d’acces.

A partir de la, vous etes pret. Vous pouvez publier des messages publics ou creer des messages directs grace a la variable mode=. Par defaut, le mode Direct Messaging, dm, est utilise.

Syntaxe

La syntaxe valide est la suivante (x://, twitter:// et tweet:// sont tous des alias acceptes) :

• x://{ConsumerKey}/{ConsumerSecret}/{AccessToken}/{AccessSecret}
• x://{ScreenName}@{ConsumerKey}/{ConsumerSecret}/{AccessToken}/{AccessSecret}

Si vous connaissez les cibles a identifier, vous pouvez les viser par leur nom d’utilisateur X, leur ScreenName :

• x://{ConsumerKey}/{ConsumerSecret}/{AccessToken}/{AccessSecret}/{ScreenName}
• x://{ConsumerKey}/{ConsumerSecret}/{AccessToken}/{AccessSecret}/{ScreenName1}/{ScreenName2}/{ScreenNameN}

[!NOTE] Si aucun ScreenName n’est precise, le message direct est envoye par defaut a votre propre compte.

Un post public peut etre reference ainsi :

• x://{ConsumerKey}/{ConsumerSecret}/{AccessToken}/{AccessSecret}?mode=tweet

Détail des Paramètres

Variable	Obligatoire	Description
ScreenName	Oui	Identifiant de votre compte, par exemple l2gnux si votre identifiant est @l2gnux. Vous devez preciser un {userid} ou un {ownerid}.
ConsumerKey	Oui	Consumer Key, c’est-a-dire la cle API.
ConsumerSecret	Oui	Consumer Secret Key, c’est-a-dire l’API Secret Key.
AccessToken	Oui	Jeton d’acces genere depuis la configuration de votre application X.
AccessSecret	Oui	Secret d’acces genere depuis la configuration de votre application X.
Mode	Non	Mode X a utiliser. Les valeurs possibles sont dm pour les messages directs prives et tweet pour publier un message public. Par defaut, dm est utilise.
batch	Non	Par defaut, les images sont regroupees ensemble. Si vous voulez publier une publication par piece jointe, definissez cette valeur sur False.

Paramètres Globaux

Variable	Description
overflow	Ce paramètre peut être défini sur split, truncate ou upstream. Il détermine la manière dont Apprise remet le message que vous lui transmettez. Par défaut, il vaut upstream. 👉 upstream : ne fait aucune modification et transmet le message exactement tel qu’il a été reçu au service. 👉 truncate : veille à ce que le message tienne dans la limite amont documentée par le service. Si plus d’informations sont fournies que la limite définie, l’excédent est tronqué. 👉 split : similaire à truncate, sauf que si le message dépasse la limite amont documentée par le service, il est découpé en plusieurs morceaux plus petits puis envoyés séquentiellement.
format	Ce paramètre peut être défini sur text, html ou markdown. Certains services prennent en charge plusieurs formats de publication du contenu. La valeur par défaut varie selon le service choisi et peut correspondre à l’un de ces trois formats. Vous pouvez facultativement forcer cette option pour vous écarter du comportement par défaut. Si le service ne prend pas en charge plusieurs formats de transmission, ce champ est ignoré.
verify	Les requêtes externes vers des emplacements sécurisés, par exemple via https, utilisent des certificats. Par défaut, Apprise vérifie la validité de ces certificats ; si ce n’est pas le cas, aucune notification n’est envoyée à la source. Dans certains cas, un utilisateur ne dispose pas d’une autorité de certification pour valider la clé ou fait simplement confiance à la source ; dans ce cas, vous pouvez définir ce drapeau sur no. Par défaut, il vaut yes.
cto	Signifie Socket Connect Timeout. Il s’agit du nombre de secondes pendant lesquelles Requests attend que votre client établisse une connexion avec une machine distante, ce qui correspond à l’appel connect() sur la socket. La valeur par défaut est de 4.0 secondes.
rto	Signifie Socket Read Timeout. Il s’agit du nombre de secondes pendant lesquelles le client attend que le serveur envoie une réponse. La valeur par défaut est de 4.0 secondes.
emojis	Active la prise en charge des emojis, par exemple :+1: qui sera traduit en 👍. Par défaut, cette option vaut no. Remarque : selon la configuration côté serveur, l’administrateur peut désactiver globalement la prise en charge des emojis ; mais par défaut, ce n’est pas le cas.
tz	Identifie le fuseau horaire de la base IANA que vous souhaitez utiliser. Par défaut, celui-ci est détecté à partir de la configuration du serveur qui exécute Apprise. Vous pouvez le définir sur des valeurs comme America/Toronto, ou sur tout autre fuseau correctement formaté correspondant à votre région.

Exemples

Envoyer un message direct X a @testaccount :

# Supposons que notre {ConsumerKey} soit T1JJ3T3L2
# Supposons que notre {ConsumerSecret} soit A1BRTD4JD
# Supposons que notre {AccessToken} soit TIiajkdnlazkcOXrIdevi7F
# Supposons que notre {AccessSecret} soit FDVJaj4jcl8chG3
# notre utilisateur est @testaccount
apprise -vv -t "Titre du Message de Test" -b "Corps du Message de Test" \
   twitter://testaccount@T1JJ3T3L2/A1BRTD4JD/TIiajkdnlazkcOXrIdevi7F/FDVJaj4jcl8chG3

Ou

# Supposons que notre {ConsumerKey} soit T1JJ3T3L2
# Supposons que notre {ConsumerSecret} soit A1BRTD4JD
# Supposons que notre {AccessToken} soit TIiajkdnlazkcOXrIdevi7F
# Supposons que notre {AccessSecret} soit FDVJaj4jcl8chG3
# notre utilisateur est @testaccount
apprise -vv -t "Titre du Message de Test" -b "Corps du Message de Test" \
   x://testaccount@T1JJ3T3L2/A1BRTD4JD/TIiajkdnlazkcOXrIdevi7F/FDVJaj4jcl8chG3

Envoyer un post public :

# Supposons que notre {ConsumerKey} soit T1JJ3T3L2
# Supposons que notre {ConsumerSecret} soit A1BRTD4JD
# Supposons que notre {AccessToken} soit TIiajkdnlazkcOXrIdevi7F
# Supposons que notre {AccessSecret} soit FDVJaj4jcl8chG3
apprise -vv -t "Titre du Message de Test" -b "Corps du Message de Test" \
   twitter://testaccount@T1JJ3T3L2/A1BRTD4JD/TIiajkdnlazkcOXrIdevi7F/FDVJaj4jcl8chG3?mode=tweet

Ou

# Supposons que notre {ConsumerKey} soit T1JJ3T3L2
# Supposons que notre {ConsumerSecret} soit A1BRTD4JD
# Supposons que notre {AccessToken} soit TIiajkdnlazkcOXrIdevi7F
# Supposons que notre {AccessSecret} soit FDVJaj4jcl8chG3
apprise -vv -t "Titre du Message de Test" -b "Corps du Message de Test" \
   x://testaccount@T1JJ3T3L2/A1BRTD4JD/TIiajkdnlazkcOXrIdevi7F/FDVJaj4jcl8chG3?mode=tweet