Bonjour, Habr!
Pour moi, cette phrase s'apparente à bonjour au monde, puisque j'ai enfin atteint ma première publication. J'ai repoussé ce merveilleux moment pendant longtemps, car il n'y avait rien à écrire, mais je ne voulais pas non plus aspirer ce qui était déjà aspiré dans un tas de 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 cela. Maintenant, tout d'abord.
Entrée
Tout a commencé avec le fait qu'il y a quelque temps je me suis lancé Linux Mint sur un ordinateur qui fonctionne. Beaucoup savent probablement que Pidgin avec le plugin Sipe est un remplacement tout à fait approprié pour Microsoft Lync (maintenant appelé Skype pour les entreprises) pour les systèmes Linux. En raison des spécificités du travail, je dois souvent participer à des conférences gorgées, et lorsque le boulanger était là, l'entrée à la conférence était élémentaire: nous recevons une invitation par mail, cliquez sur le lien de connexion, nous sommes prêts à l'intérieur.
Lors du passage au
côté obscur de Linux, les choses se sont un peu compliquées: il y a bien sûr une entrée Pidgin à la conférence, mais pour cela, vous devez sélectionner l'option de rejoindre la conférence dans le menu dans les propriétés de votre compte SIP et insérer un lien vers la conférence dans la fenêtre qui s'ouvre ou entrez le nom de l'organisateur et conf id. Et après un certain temps, j'ai commencé à penser: "Est-il possible de simplifier en quelque sorte cela?" Ouais, vous dites, pourquoi diable en aviez-vous besoin, s'asseyait-il sur Windows et ne soufflait pas une moustache.
Étape 1. Recherche
"Quel caprice va dans la tête - vous ne la battrez pas", - a déclaré Nekrasov dans son travail "Qui peut bien vivre en Russie".
Ainsi, depuis que la pensée a frappé la tête, après un certain temps, la première idée a émergé pour la mise en œuvre. Tout semblait simple - vous devez intercepter l'appel vers les liens
meet.company.com/user/confid - placez le processus local de l'application Web sur 127.0.0.1 sur votre brouette et entrez l'entrée statique du domaine de l'entreprise via laquelle dans / etc / hosts lors d'une conférence pointant vers localhost. De plus, ce serveur Web devrait traiter le lien qui lui est arrivé 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 pas du tout comment le lui donner). La solution, bien sûr, sent comme des béquilles, mais nous sommes programmeurs, les béquilles ne nous font pas peur (grincement).
Puis, par hasard, j'ai en quelque sorte ouvert un lien vers une invitation à Google Chrome (et généralement j'utilise toujours Mozilla Firefox). Et à ma grande surprise, la page Web avait l'air complètement différente - il n'y avait pas de formulaire de saisie de données utilisateur et immédiatement après avoir entré la page, il y avait une demande d'ouverture de quelque chose via
xdg-open . Pour le plaisir, 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 autopsie lisant la documentation a montré qu'il s'agit d'un gestionnaire de shell graphique qui permet de lancer des applications associées avec les protocoles du schéma uri ou certains types de fichiers. Les associations sont configurées via un mappage de type mime. Donc, nous voyons que nous commençons la recherche d'une application mappée pour le schéma uri avec le nom
lync15 et le lien est passé à xdg-open, qui devrait en théorie le passer à une application responsable de ce type de liens. Ce que nous n'avons bien sûr pas dans le système. Et sinon, comment font-ils dans le monde open source? C'est vrai, nous l'écrirons nous-mêmes.
Une immersion supplémentaire dans le monde Linux et en particulier dans l'étude du fonctionnement du shell graphique (environnement de bureau, DE), par la façon dont je l'ai Xfce dans Linux Mint, a montré que les applications et le type MIME qui lui sont associés sont généralement écrits directement dans des fichiers de raccourci avec l'extension .desktop. Eh bien, pourquoi pas, je crée un raccourci d'application simple, qui devrait simplement exécuter le script bash et sortir l'argument qui lui est transmis à la console, je ne donnerai 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 avec le même lien qui vient du navigateur et ... bummer. Encore une fois, il dit qu'il ne peut pas traiter le lien.
Il s'est avéré que je n'ai pas mis à jour le répertoire du type mime associé avec mon application. Cela se fait avec une simple commande:
xdg-mime default lync.desktop x-scheme-handler/lync15
qui modifie simplement le
fichier ~ / .config / mimeapps.list .
Tentative numéro 2 avec appel xdg-open - et échec à nouveau. Rien, les difficultés ne nous font pas peur, mais ne font que nourrir l'intérêt. Et armés de toute la puissance de la bash (c'est-à-dire du traçage), nous plongeons tête baissée 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 la sortie après le traçage, il devient un peu clair qu'un contrôle supplémentaire est transféré vers
exo-open . Et il s'agit déjà d'un fichier binaire et il est déjà plus difficile de comprendre pourquoi il renvoie un code retour infructueux lors de la transmission d'un lien vers celui-ci dans un argument.
Après avoir parcouru les intérieurs de xdg-open, j'ai découvert qu'il analyse divers paramètres environnementaux et passe le contrôle à certains outils pour ouvrir des fichiers / liens spécifiques à un DE particulier, ou qu'il a un repli sous la forme de la fonction
open_generic 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 }
J'ai rapidement coupé un petit hack ici avec l'analyse de l'argument passé, et si notre sous-chaîne spécifique
lync15 est là , alors nous passons immédiatement le contrôle à la fonction
open_generic .
Essayez le numéro 3 et vous pensez que cela a fonctionné? Ouais, maintenant comment. Mais le message d'erreur a déjà changé, c'est déjà un progrès - maintenant il m'a dit que le fichier n'était pas trouvé et sous la forme d'un fichier il m'a écrit le lien même passé en argument.
Cette fois, il s'est avéré être la fonction
is_file_url_or_path , qui analyse le lien vers le fichier fichier: // 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) a des nombres, et l'expression régulière n'est vérifiée que pour un jeu de caractères composé de: alpha: points et tirets. Après avoir consulté la norme rfc3986 pour un
identifiant de ressource uniforme, il est devenu clair que cette fois, Microsoft n'a rien violé (bien que j'avais une telle version). Juste une classe de caractères: alpha: contient uniquement des lettres de l'alphabet latin. Je change rapidement le chèque régulier en alphanumérique. Terminé, vous êtes ravissant, tout démarre enfin, le contrôle après tous les contrôles 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 d'exo-open sont également dus à la validation du format de lien en raison des numéros dans le diagramme. Pour tester l'hypothèse, je change l'enregistrement de type mime de l'application en juste le schéma
lync et le tour est joué - tout fonctionne sans redéfinir la fonction open_xfce. Mais cela ne nous aidera en aucune façon, car la page Web pour entrer dans la conférence crée exactement le lien avec lync15.
Ainsi, la première partie du chemin est terminée. Nous pouvons intercepter l'appel de liaison, puis nous devons le traiter et le passer dans Pidgin. Afin de comprendre comment cela fonctionne en interne lors de la saisie de données à l'aide du lien dans le menu «Rejoindre la conférence», j'ai cloné le référentiel du projet Sipe et me suis préparé à plonger à nouveau dans le code. Mais ici, heureusement, j'ai été attiré par les scripts du répertoire
contrib / dbus / :
- sipe-join-conference-with-uri.pl
- sipe-join-conference-with-organizer-and-id.pl
- sipe-call-phone-number.pl
- Sipehelp.pm
Il s'avère que le plug-in Sipe est disponible pour une interaction via le dbus (bus de bureau) et à l'intérieur des scripts, il existe directement des exemples de participation à la conférence via un lien, soit via le nom de l'organisateur et conf-id, ou vous pouvez initier un appel via sip. C'est exactement ce qui nous manquait.
Étape 2. Implémentation d'un gestionnaire pour la jointure automatique
Puisqu'il y a des exemples prêts à l'emploi pour la perle, j'ai décidé d'utiliser simplement
sipe-join-conference-with-uri.pl et de le modifier un peu pour moi. Je peux écrire en nacre, donc cela n'a pas posé de problème particulier.
Après avoir testé le script séparément, j'ai entré son appel dans le fichier
lync.desktop . Et ce fut une victoire! Lorsque vous entrez dans la page de participation à la conférence et autorisez le lancement de xdg-open, la fenêtre contextuelle de la conférence de Pidgin s'ouvre automatiquement. Comme je me réjouissais.
Encouragé par le succès, j'ai décidé de faire de même pour mon navigateur principal, Mozilla Firefox. Lorsque vous entrez par le renard, une page d'autorisation s'ouvre et tout en bas se trouve un bouton de
connexion à l'aide du communicateur de bureau . Elle a également attiré mon attention. Lorsque vous cliquez dessus dans le navigateur, le lien va à:
conf:sip:{user};gruu;opaque=app:conf:focus:id:{conf-id}%3Frequired-media=audio
auquel il me dit gentiment qu'il ne sait pas comment l'ouvrir et, peut-être, je n'ai pas d'application associée pour un tel protocole. Eh bien, nous l'avons déjà adopté.
Enregistrement rapide de mon application de script également pour la
configuration d' uri-schéma et ... rien ne se passe. Le navigateur continue de se plaindre qu'aucune application ne traite mes liens. Dans le même temps, un appel à partir de la console xdg-open avec des paramètres fonctionne correctement.
"Définir un gestionnaire de protocole personnalisé dans Firefox" - avec cette question, je suis allé en ligne. Après quelques discussions sur stackoverflow (et où 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, remplacer foo par conf):
network.protocol-handler.expose.foo = false
Nous créons, ouvrons le lien et ... il n'était pas là. Le navigateur, comme si de rien n'était, dit qu'il ne connaît pas notre application.
J'ai lu la documentation officielle sur l'enregistrement du protocole avec Mozilla, il y a une option pour enregistrer les associations dans le bureau gnome lui-même (en remplaçant bien sûr foo par conf):
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, ouvre le navigateur ... et encore la barbe.
Ici, une ligne de la documentation attire votre attention:
La prochaine fois que vous cliquerez sur un lien de type de protocole foo, vous serez invité avec quelle application l'ouvrir.
- Semen Semenych
- Ahh
Nous ne cliquons pas sur le lien, mais simplement la page Web fait le changement de window.location via javascript. J'écris un simple fichier html avec un lien vers le protocole conf, ouvrez-le dans un navigateur, cliquez sur le lien - Yos! Une fenêtre s'ouvre avec une question dans quelle application vous devez 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. Il y a une coche dans la fenêtre «souvenez-vous du choix et ouvrez toujours les liens dans notre application», notez, 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 déjà non seulement lorsque vous cliquez sur le lien, mais également lorsque vous passez de la page souhaitée pour rejoindre la conférence.
Ensuite, j'ai vérifié que la suppression des
paramètres network.protocol-handler.expose.conf n'affectait en rien le fonctionnement du protocole dans le renard. Les liens ont continué de fonctionner.
Conclusion
J'ai téléchargé toutes mes réalisations dans le référentiel github, des liens vers toutes les ressources seront à la fin de l'article.
Il sera intéressant pour moi d'obtenir des commentaires de ceux qui souhaitent utiliser mes meilleures pratiques. Je dois dire tout de suite que j'ai tout fait uniquement pour mon système Linux Mint, donc certaines autres distributions ou bureaux peuvent ne pas fonctionner dans cette version. Au contraire, je suis même presque sûr de cela, car j'ai patché dans xdg-open seulement 1 fonction liée uniquement à mon DE. Si vous souhaitez ajouter la prise en charge d'autres systèmes ou dekstopov, écrivez-moi une demande de pool dans github.
La mise en œuvre de l'ensemble du projet a pris 1 soirée.
Références: