Hola Habr!
Per a mi, aquesta frase és semblant a hello world, ja que finalment vaig arribar a la meva primera publicació. Vaig ajornar aquest moment meravellós durant molt de temps, ja que no hi havia res a escriure, i tampoc volia xuclar alguna cosa que ja havia estat xuclada un munt de vegades. En general, per a la meva primera publicació volia alguna cosa original, útil per als altres i que contingués algun tipus de repte i resolució de problemes. I ara puc compartir això. Ara parlem de tot en ordre.
Entrada
Tot va començar quan fa un temps vaig descarregar Linux Mint al meu ordinador de treball. Probablement molta gent sap que Pidgin amb el connector Sipe és un reemplaçament completament adequat per a Microsoft Lync (ara anomenat Skype per a empreses) per a sistemes Linux. A causa de les especificitats del meu treball, sovint he de participar en conferències SIP, i quan era treballador de Windows, entrar a les conferències era elemental: rebem una invitació per correu, fem clic a l'enllaç d'inici de sessió i estem preparats per començar. .
En canviar al costat fosc de Linux, tot es va complicar una mica: per descomptat, també podeu introduir conferències a Pidgin, però per fer-ho cal que seleccioneu l'opció d'unir-se a la conferència al menú de les propietats del vostre compte SIP i a la finestra que s'obre, inseriu un enllaç a la conferència o introduïu el nom de l'organitzador i conf id. I després d'un temps vaig començar a pensar: "és possible simplificar això d'alguna manera?" Sí, podríeu dir, per què dimonis ho necessiteu? Prefereixo seure a Windows i no em vola?
Pas 1: investigació
"Si tens cap caprici, no pots eliminar-lo amb una estaca", va dir Nekrasov a la seva obra "Who Lives Well in Rus'".
Així doncs, un cop el pensament em va entrar al cap, al cap d'un temps va sorgir la primera idea d'implementació. Tot semblava senzill: cal interceptar l'accés als enllaços — instal·leu un procés d'aplicació web local al vostre cotxe a 127.0.0.1 i a /etc/hosts afegiu una entrada estàtica per al domini de l'empresa a través del qual entreu a la conferència, apuntant a localhost. A continuació, aquest servidor web ha de processar l'enllaç que hi ha arribat i transferir-lo d'alguna manera dins de Pidgin (de seguida diré que en aquesta etapa encara no tenia ni idea de com donar-li-ho). La solució, és clar, fa olor a crosses, però som programadors, les crosses no ens fan por (merda).
Aleshores, per casualitat, vaig obrir d'alguna manera l'enllaç d'invitació a Google Chrome (i normalment faig servir sempre Mozilla Firefox). I, per a la meva sorpresa, la pàgina web semblava completament diferent: no hi havia cap formulari per introduir les dades de l'usuari i immediatament després d'entrar a la pàgina hi havia una sol·licitud per obrir alguna cosa. xdg-open. Només per diversió, faig clic a "sí" i apareix un missatge d'error: no es pot obrir l'enllaç lync15:confjoin?url=https://meet.company.com/user/confid. Hmm. Quin tipus de xdg-open és aquest i què necessita per obrir aquests enllaços? Una lectura post mortem de la documentació va revelar que es tracta d'un gestor d'interfície gràfica d'usuari que ajuda a executar aplicacions associades amb protocols per a l'esquema uri o amb tipus de fitxers específics. Les associacions es configuren mitjançant mapes de tipus MIME. Així doncs, veiem que estem executant una cerca d'una aplicació coincident per a un esquema uri anomenat lync15 i l'enllaç es passa a xdg-open, que després, en teoria, l'hauria de passar a alguna aplicació responsable d'aquest tipus d'enllaç. Cosa que, per descomptat, no tenim al nostre sistema. Si no, què fan al món de codi obert? Així és, ho escriurem nosaltres mateixos.
Una immersió addicional en el món de Linux i especialment en l'estudi de com funciona l'intèrpret d'ordres gràfic (entorn d'escriptori, DE) , per cert, tinc Xfce a Linux Mint, va demostrar que les aplicacions i el tipus mímic que hi estan associats solen escriure directament en fitxers de drecera amb l'extensió .desktop. Bé, per què no, creo una drecera d'aplicació senzilla, que simplement hauria de llançar un script bash i sortir l'argument que se li passa a la consola, només proporciono el fitxer de drecera en si:
[Desktop Entry]
Name=Lync
Exec=/usr/local/bin/lync.sh %u
Type=Application
Terminal=false
Categories=Network;InstantMessaging;
MimeType=x-scheme-handler/lync15;
Llanço xdg-open des de la consola, passant el mateix enllaç que ve del navegador i... llàstima. De nou diu que no pot processar l'enllaç.
Com a resultat, no vaig actualitzar el directori de tipus MIME associats amb la meva aplicació. Això es fa amb una ordre senzilla:
xdg-mime default lync.desktop x-scheme-handler/lync15
que simplement edita el fitxer ~/.config/mimeapps.list.
Intenteu el número 2 amb la trucada xdg-open, i de nou fracassa. Res, les dificultats no ens espanten, sinó que només alimenten el nostre interès. I armats amb tot el poder de bash (és a dir, el rastreig), ens submergim de cap en la depuració. És important tenir en compte aquí que xdg-open és només un script de shell.
bash -x xdg-open $url
Analitzant la sortida després de traçar, queda una mica clar que després es transfereix el control exo-obert. I això ja és un fitxer binari i és més difícil entendre per què retorna un codi de retorn sense èxit quan s'hi passa un enllaç en un argument.
Després d'haver mirat els elements interns de xdg-open, vaig descobrir que analitza diversos paràmetres ambientals i passa el control més endavant a algunes eines per obrir enllaços de fitxers específics d'un determinat DE, o bé té una funció alternativa. obert_genèric
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
}
Ràpidament incrustaré aquí un petit hack amb l'anàlisi de l'argument passat i si la nostra subcadena específica es troba allà lync15:, llavors transferim immediatament el control a la funció obert_genèric.
Intenta el número 3 i creus que ha funcionat? Sí, ara, és clar. Però el missatge d'error ja ha canviat, això ja és un progrés; ara em deia que el fitxer no s'havia trobat i en forma de fitxer em va escriure el mateix enllaç passat com a argument.
Aquesta vegada va resultar ser una funció is_file_url_or_path, que analitza l'enllaç del fitxer passat a l'entrada: file:// o el camí del fitxer o una altra cosa. I la comprovació no va funcionar correctament a causa del fet que el nostre prefix (esquema d'URL) té números, i l'expressió regular només verifica el conjunt de caràcters format per :alpha: punts i guions. Després de consultar l'estàndard rfc3986 per identificador de recurs uniforme Va quedar clar que aquesta vegada Microsoft no està violant res (tot i que jo tenia una versió així). Només la classe de caràcters :alpha: conté només lletres de l'alfabet llatí. Canvio ràpidament la comprovació habitual a alfanumèrica. Fet, sou increïbles, finalment tot comença, el control després de totes les comprovacions es dóna a la nostra aplicació de scripts, el nostre enllaç es mostra a la consola, tot és com hauria de ser. Després d'això, començo a sospitar que tots els problemes amb exo-open també es deuen a la validació del format d'enllaç a causa dels números de l'esquema. Per provar la hipòtesi, canvio el registre de tipus mime de l'aplicació per només un esquema lync i voilà: tot funciona sense anul·lar la funció open_xfce. Però això no ens servirà de res, perquè la pàgina web per entrar a la conferència crea un enllaç amb lync15.
Així doncs, s'ha completat la primera part del viatge. Sabem com interceptar una trucada d'enllaç i després s'ha de processar i passar d'alguna manera dins de Pidgin. Per entendre com funciona internament quan introduïm dades mitjançant un enllaç al menú "uneix-te a una conferència", vaig clonar el repositori Git del projecte Sipe i em vaig preparar per submergir-me de nou en el codi. Però després, per sort, em van atreure els guions del catàleg contribució/dbus/:
- sipe-join-conference-with-uri.pl
- sipe-join-conference-with-organizer-and-id.pl
- sipe-call-phone-number.pl
- SipeHelper.pm
Resulta que el connector Sipe està disponible per a la interacció mitjançant dbus (bus d'escriptori) i dins dels scripts hi ha exemples d'unir-se a una conferència mitjançant un enllaç, ja sigui a través del nom de l'organitzador i conf-id, o bé podeu iniciar una trucada mitjançant sip . Això és exactament el que ens faltava.
Pas 2. Implementació d'un controlador d'unió automàtica
Com que hi ha exemples ja fets a Pearl, vaig decidir utilitzar-los sipe-join-conference-with-uri.pl i modifiqueu-lo una mica perquè us convingui. Puc escriure en Pearl, així que no va causar cap dificultat especial.
Després de provar l'script per separat, vaig escriure la seva crida al fitxer lync.desktop. I va ser una victòria! En entrar a la pàgina d'unió a la conferència i permetre que xdg-open s'executi, la finestra emergent de la conferència de Pidgin s'obriria automàticament. Com em vaig alegrar.
Animat per l'èxit, vaig decidir fer el mateix amb el meu navegador principal, Mozilla Firefox. Quan inicieu sessió a través de la guineu, s'obre una pàgina d'autorització i a la part inferior hi ha un botó uneix-te mitjançant Office Communicator. Ella va ser la que em va cridar l'atenció. Quan hi feu clic al navegador, va a l'adreça:
conf:sip:{user};gruu;opaque=app:conf:focus:id:{conf-id}%3Frequired-media=audio
al que amablement em diu que no sap com obrir-lo i, potser, no tinc una aplicació associada per a aquest protocol. Bé, ja hem passat per això.
Registre ràpidament la meva aplicació d'script també per a l'esquema uri conf i... no passa res. El navegador continua queixant-se que no hi ha cap aplicació que gestioni els meus enllaços. En aquest cas, cridar a xdg-open des de la consola amb paràmetres funciona perfectament.
"Estableix un gestor de protocols personalitzat a Firefox": vaig connectar amb aquesta pregunta. Després de passar per diverses discussions sobre stackoverflow (i on estaríem sense ell), sembla que s'ha trobat la resposta. Heu de crear un paràmetre especial a about: config (per descomptat, substituint foo per conf):
network.protocol-handler.expose.foo = false
El creem, obrim l'enllaç i... no hi ha sort. El navegador, com si no hagués passat res, diu que no coneix la nostra aplicació.
Estic llegint la documentació oficial sobre el registre d'un protocol de Mozilla, hi ha una opció per registrar associacions al propi escriptori gnome (substituint foo per conf, és clar):
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
Em registre, obro el navegador... i de nou la barba.
Aquí una línia de la documentació em crida l'atenció:
La propera vegada que feu clic a un enllaç de protocol de tipus foo, se us demanarà amb quina aplicació l'obrireu.
— Semyon Semenych
- Ahh
No fem clic a l'enllaç, però la pàgina web simplement canvia window.location mitjançant javascript. Escric un fitxer html senzill amb un enllaç al protocol conf, l'obro al navegador, feu clic a l'enllaç - Yos! S'obre una finestra que ens demana en quina aplicació hem d'obrir el nostre enllaç, i allà ja tenim la nostra aplicació Lync a la llista; sincerament, la vam registrar de totes les maneres possibles. A la finestra hi ha una casella de selecció "recorda l'elecció i obriu sempre els enllaços a la nostra aplicació", marqueu-la, feu clic a d'acord. I aquesta és la segona victòria: s'obre la finestra de la conferència. Al mateix temps, l'obertura de conferències funciona no només quan feu clic a un enllaç, sinó també quan passeu de la pàgina d'unió que necessitem a la conferència.
Llavors vaig comprovar, esborrant paràmetres network.protocol-handler.expose.conf no va afectar de cap manera el funcionament del protocol a Fox. Els enllaços van continuar funcionant.
Conclusió
He penjat tot el meu treball al repositori de GitHub. Els enllaços a tots els recursos es trobaran al final de l'article.
Estaré interessat a rebre comentaris d'aquells que vulguin utilitzar el meu treball. He de tenir en compte immediatament que vaig fer tot el desenvolupament només per al meu sistema Linux Mint, de manera que algunes altres distribucions o escriptoris poden no funcionar en aquesta versió. O més ben dit, fins i tot n'estic gairebé segur, perquè només he pegat 1 funció a xdg-open que només es relaciona amb el meu DE. Si voleu afegir suport per a altres sistemes o escriptoris, escriviu-me sol·licituds d'extracció a Github.
Tot el projecte va trigar 1 vespre a completar-se.
Enllaços:
Font: www.habr.com