Hé Habr !
Pour moi, cette phrase s'apparente à bonjour tout le monde, depuis que je suis enfin arrivé à ma première publication. J'ai longtemps reporté ce moment merveilleux, car il n'y avait rien à écrire, et je ne voulais pas non plus sucer quelque chose qui avait déjà été sucé plusieurs fois. En général, pour ma première publication, je voulais quelque chose d'original, utile aux autres et contenant une sorte de défi et de résolution de problèmes. Et maintenant je peux partager ça. Parlons maintenant de tout dans l'ordre.
Entrée
Tout a commencé il y a quelque temps, j'ai téléchargé Linux Mint sur mon ordinateur de travail. Beaucoup de gens savent probablement que Pidgin avec le plugin Sipe est un remplacement tout à fait approprié de Microsoft Lync (maintenant appelé Skype for business) pour les systèmes Linux. En raison des spécificités de mon travail, je dois souvent participer à des conférences SIP, et lorsque j'étais travailleur Windows, accéder aux conférences était élémentaire : on reçoit une invitation par mail, on clique sur le lien de connexion, et on est prêt à partir .
Lors du passage au côté obscur de Linux, tout est devenu un peu plus compliqué : bien sûr, vous pouvez également vous connecter à des conférences dans Pidgin, mais pour ce faire, vous devez sélectionner l'option Rejoindre la conférence dans le menu des propriétés de votre compte SIP et dans la fenêtre qui s'ouvre, insérez un lien vers la conférence ou saisissez le nom de l'organisateur et l'identifiant de confidentialité. Et après un certain temps, j'ai commencé à penser : « est-il possible de simplifier cela d'une manière ou d'une autre ? Ouais, vous pourriez vous demander, pourquoi diable avez-vous besoin de ça ? Je préfère m'asseoir sur Windows et ne pas m'épater.
Étape 1 : Recherche
"Si vous avez un caprice en tête, vous ne pouvez pas l'assommer avec un pieu", a déclaré Nekrasov dans son ouvrage "Qui vit bien en Russie".
Ainsi, une fois que l’idée m’est venue à l’esprit, après un certain temps, la première idée de mise en œuvre est née. Tout semblait simple - vous devez intercepter l'accès aux liens — installez un processus d'application Web locale sur votre voiture à l'adresse 127.0.0.1 et dans /etc/hosts, ajoutez une entrée statique pour le domaine de l'entreprise par lequel vous entrez dans la conférence, pointant vers localhost. Ensuite, ce serveur Web doit traiter le lien qui lui est parvenu et le transférer d'une manière ou d'une autre dans Pidgin (je dirai tout de suite qu'à ce stade, je ne savais toujours pas du tout comment le lui donner). La solution, bien sûr, sent les béquilles, mais nous sommes des programmeurs, les béquilles ne nous font pas peur (merde).
Puis, par hasard, j'ai ouvert le lien d'invitation dans Google Chrome (et j'utilise généralement toujours Mozilla Firefox). Et à ma grande surprise, la page Web avait l'air complètement différente - il n'y avait pas de formulaire pour saisir les données utilisateur et immédiatement après avoir accédé à la page, il y avait une demande d'ouverture de quelque chose via xdg-open. Juste pour m'amuser, je clique sur « oui » et un message d'erreur apparaît : le lien lync15:confjoin?url=https://meet.company.com/user/confid ne peut pas être ouvert. Hmm. De quel type de xdg-open s'agit-il et de quoi a-t-il besoin pour que de tels liens s'ouvrent ? Une lecture post-mortem de la documentation a révélé qu'il s'agit d'un gestionnaire d'interface graphique qui permet d'exécuter des applications associées soit avec des protocoles pour le schéma uri, soit avec des types de fichiers spécifiques. Les associations sont configurées via un mappage de type MIME. Nous voyons donc que nous recherchons une application correspondante pour un schéma d'URI nommé lync15 et le lien est transmis à xdg-open, qui devrait ensuite, en théorie, le transmettre à une application responsable de ce type de lien. Ce que nous n’avons bien sûr pas dans notre système. Si ce n’est pas le cas, que font-ils dans le monde open source ? C'est vrai, nous l'écrirons nous-mêmes.
Une immersion plus poussée dans le monde de Linux et surtout dans l'étude du fonctionnement du shell graphique (environnement de bureau, DE), d'ailleurs, j'ai Xfce dans Linux Mint, a montré que les applications et le type MIME qui y sont associés sont généralement écrits directement dans fichiers de raccourci avec l'extension .desktop. Eh bien, pourquoi pas, je crée un simple raccourci d'application, qui devrait simplement lancer un script bash et afficher l'argument qui lui est transmis sur la console, je ne fournis que le fichier de raccourci lui-même :
[Desktop Entry]
Name=Lync
Exec=/usr/local/bin/lync.sh %u
Type=Application
Terminal=false
Categories=Network;InstantMessaging;
MimeType=x-scheme-handler/lync15;
Je lance xdg-open depuis la console, en passant le même lien qui vient du navigateur et... décevant. Encore une fois, il indique qu'il ne peut pas traiter le lien.
Il s'avère que je n'ai pas mis à jour le répertoire des types MIME associés à mon application. Cela se fait avec une simple commande :
xdg-mime default lync.desktop x-scheme-handler/lync15
qui édite simplement le fichier ~/.config/mimeapps.list.
Tentative numéro 2 avec l'appel xdg-open - et encore une fois échec. Rien, les difficultés ne nous effraient pas, mais alimentent seulement notre intérêt. Et armés de toute la puissance de bash (c'est-à-dire du traçage), nous plongeons tête première dans le débogage. Il est important de noter ici que xdg-open n'est qu'un script shell.
bash -x xdg-open $url
En analysant le résultat après le traçage, il devient un peu clair que le contrôle est ensuite transféré à exo-ouvert. Et c'est déjà un fichier binaire et il est plus difficile de comprendre pourquoi il renvoie un code retour infructueux lorsqu'on lui passe un lien dans un argument.
Après avoir parcouru les composants internes de xdg-open, j'ai découvert qu'il analyse divers paramètres environnementaux et transmet le contrôle soit à certains outils d'ouverture de liens de fichiers spécifiques à un DE particulier, soit qu'il dispose d'une fonction de secours. open_générique
open_xfce()
{
if exo-open --help 2>/dev/null 1>&2; then
exo-open "$1"
elif gio help open 2>/dev/null 1>&2; then
gio open "$1"
elif gvfs-open --help 2>/dev/null 1>&2; then
gvfs-open "$1"
else
open_generic "$1"
fi
if [ $? -eq 0 ]; then
exit_success
else
exit_failure_operation_failed
fi
}
Je vais rapidement intégrer ici un petit hack avec analyse de l'argument passé et si notre sous-chaîne spécifique s'y trouve lync15 :, alors on transfère immédiatement le contrôle à la fonction open_générique.
Tentative numéro 3 et pensez-vous que cela a fonctionné ? Ouais, maintenant, bien sûr. Mais le message d'erreur a déjà changé, c'est déjà un progrès - maintenant il me disait que le fichier n'était pas trouvé et sous forme de fichier il m'a écrit le même lien passé en argument.
Cette fois, il s'est avéré que c'était une fonction is_file_url_or_path, qui analyse le lien de fichier transmis à l'entrée : file:// ou le chemin d'accès au fichier ou autre chose. Et la vérification n'a pas fonctionné correctement en raison du fait que notre préfixe (schéma d'URL) comporte des nombres et que l'expression régulière ne vérifie que le jeu de caractères composé de :alpha: points et tirets. Après avoir consulté la norme rfc3986 pour identifiant de ressource uniforme Il est devenu clair que cette fois, Microsoft ne violait rien (même si j'avais une telle version). Seule la classe de caractères :alpha: contient uniquement des lettres de l'alphabet latin. Je change rapidement le chèque régulier en alphanumérique. C'est fait, vous êtes incroyable, tout commence enfin, le contrôle après toutes les vérifications est donné à notre application de script, notre lien s'affiche sur la console, tout est comme il se doit. Après cela, je commence à soupçonner que tous les problèmes avec exo-open sont également dus à la validation du format du lien en raison des nombres dans le schéma. Pour tester l'hypothèse, je change l'enregistrement de type MIME de l'application en un simple schéma Lync et voilà - tout fonctionne sans remplacer la fonction open_xfce. Mais cela ne nous aidera en rien, car la page web pour accéder à la conférence crée un lien avec lync15.
Ainsi, la première partie du voyage est terminée. Nous savons comment intercepter un appel de lien, puis il doit être traité et transmis d'une manière ou d'une autre dans Pidgin. Afin de comprendre comment cela fonctionne en interne lors de la saisie de données via un lien dans le menu « rejoindre une conférence », j'ai cloné le dépôt Git du projet Sipe et me suis préparé à me replonger dans le code. Mais ensuite, heureusement, j'ai été attiré par les scripts du catalogue contribution/dbus/:
- sipe-rejoindre-la-conférence-avec-uri.pl
- sipe-rejoindre-la-conférence-avec-organisateur-et-id.pl
- sipe-call-phone-number.pl
- SipeHelper.pm
Il s'avère que le plugin Sipe est disponible pour l'interaction via dbus (bus de bureau) et à l'intérieur des scripts il y a des exemples de participation à une conférence via un lien, soit via le nom et l'identifiant de configuration de l'organisateur, soit vous pouvez lancer un appel via sip . C'est exactement ce qui nous manquait.
Étape 2. Implémentation d'un gestionnaire de jointure automatique
Puisqu'il existe des exemples prêts à l'emploi dans Pearl, j'ai décidé d'utiliser simplement sipe-rejoindre-la-conférence-avec-uri.pl et modifiez-le un peu à votre convenance. Je peux écrire en Pearl, donc cela n’a pas posé de difficultés particulières.
Après avoir testé le script séparément, j'ai écrit son appel dans le fichier lync.desktop. Et c'était une victoire ! En accédant à la page de participation à la conférence et en autorisant l'exécution de xdg-open, la fenêtre contextuelle de la conférence de Pidgin s'ouvrirait automatiquement. Comme je me suis réjoui.
Encouragé par le succès, j'ai décidé de faire de même pour mon navigateur principal, Mozilla Firefox. Lorsque vous vous connectez via le fox, une page d'autorisation s'ouvre et tout en bas il y a un bouton rejoindre en utilisant Office Communicator. C'est elle qui a retenu mon attention. Lorsque vous cliquez dessus dans le navigateur, vous accédez à l'adresse :
conf:sip:{user};gruu;opaque=app:conf:focus:id:{conf-id}%3Frequired-media=audio
à quoi il me dit gentiment qu'il ne sait pas comment l'ouvrir et, peut-être, je n'ai pas d'application associée à un tel protocole. Eh bien, nous avons déjà vécu cela.
J'enregistre rapidement mon application de script également pour le schéma uri conf et... rien ne se passe. Le navigateur ne cesse de se plaindre du fait qu’aucune application ne gère mes liens. Dans ce cas, appeler xdg-open depuis la console avec des paramètres fonctionne parfaitement.
"Définir un gestionnaire de protocole personnalisé dans Firefox" - Je suis allé en ligne avec cette question. Après avoir parcouru plusieurs discussions sur stackoverflow (et où serions-nous sans lui), il semble que la réponse ait été trouvée. Vous devez créer un paramètre spécial dans about: config (bien sûr en remplaçant foo par conf) :
network.protocol-handler.expose.foo = false
Nous le créons, ouvrons le lien et... pas de chance. Le navigateur, comme si de rien n'était, dit qu'il ne connaît pas notre application.
Je lis la documentation officielle sur l'enregistrement d'un protocole de Mozilla, il existe une option pour enregistrer des associations dans le bureau gnome lui-même (en remplaçant foo par conf, bien sûr) :
gconftool-2 -s /desktop/gnome/url-handlers/foo/command '/path/to/app %s' --type String
gconftool-2 -s /desktop/gnome/url-handlers/foo/enabled --type Boolean true
Je m'inscris, j'ouvre le navigateur... et encore la barbe.
Ici, une ligne de la documentation attire mon attention :
La prochaine fois que vous cliquerez sur un lien de type protocole foo, il vous sera demandé avec quelle application l'ouvrir.
— Semyon Semenych
- Ahh
Nous ne cliquons pas sur le lien, mais la page Web change simplement window.location via javascript. J'écris un simple fichier html avec un lien vers le protocole conf, je l'ouvre dans le navigateur, je clique sur le lien - Yos ! Une fenêtre s'ouvre nous demandant dans quelle application nous devons ouvrir notre lien, et là, nous avons déjà notre application Lync dans la liste - nous l'avons honnêtement enregistrée de toutes les manières possibles. Là, dans la fenêtre, il y a une case à cocher « mémoriser le choix et toujours ouvrir les liens dans notre application », cochez-la, cliquez sur ok. Et c'est la deuxième victoire : la fenêtre de la conférence s'ouvre. Dans le même temps, l'ouverture de conférences fonctionne non seulement lorsque vous cliquez sur un lien, mais également lorsque vous passez de la page de participation dont nous avons besoin à la conférence.
Puis j'ai vérifié, en supprimant les paramètres réseau.protocol-handler.expose.conf n'a en rien affecté le fonctionnement du protocole chez Fox. Les liens ont continué à fonctionner.
Conclusion
J'ai téléchargé tout mon travail sur le référentiel GitHub ; les liens vers toutes les ressources seront à la fin de l'article.
Je serai intéressé de recevoir les commentaires de ceux qui souhaitent utiliser mon travail. Je dois immédiatement noter que j'ai effectué tout le développement uniquement pour mon système Linux Mint, donc certaines autres distributions ou ordinateurs de bureau peuvent ne pas fonctionner dans cette version. Ou plutôt, j'en suis même presque sûr, car je n'ai patché qu'une seule fonction dans xdg-open qui concerne uniquement mon DE. Si vous souhaitez ajouter la prise en charge d'autres systèmes ou ordinateurs de bureau, écrivez-moi des demandes d'extraction sur Github.
L’ensemble du projet a duré 1 soirée.
Liens:
Source: habr.com