Hei Habr!
Pentru mine, această frază seamănă cu hello world, deoarece am ajuns în sfârșit la prima mea publicație. Am amânat acest moment minunat pentru o lungă perioadă de timp, din moment ce nu aveam despre ce să scriu și, de asemenea, nu am vrut să sug ceva care fusese deja supt de mai multe ori. În general, pentru prima mea publicație mi-am dorit ceva original, util altora și care să conțină un fel de provocare și rezolvare de probleme. Și acum pot să împărtășesc asta. Acum să vorbim despre totul în ordine.
Intrare
Totul a început când în urmă cu ceva timp am descărcat Linux Mint pe computerul meu de lucru. Mulți oameni știu probabil că Pidgin cu pluginul Sipe este un înlocuitor complet potrivit pentru Microsoft Lync (numit acum Skype pentru afaceri) pentru sistemele Linux. Datorită specificului muncii mele, trebuie să particip adesea la conferințe SIP, iar când eram lucrător Windows, intrarea la conferințe era elementară: primim o invitație prin poștă, facem clic pe linkul de conectare și suntem gata să mergem. .
La trecerea la partea întunecată a Linux, totul a devenit ceva mai complicat: desigur, puteți introduce conferințe și în Pidgin, dar pentru a face acest lucru trebuie să selectați opțiunea de participare la conferință din meniul din proprietățile contului dvs. SIP și în fereastra care se deschide, introduceți un link către conferință sau introduceți numele organizatorului și confid. Și după ceva timp am început să mă gândesc: „Este posibil să simplificăm cumva acest lucru?” Da, ai putea spune, de ce naiba ai nevoie de asta, aș prefera să stau pe Windows și să nu-mi surprindă mintea?
Pasul 1: Cercetare
„Dacă îți prinde un capriciu, nu poți să-l elimini cu o miză”, a spus Nekrasov în lucrarea sa „Cine trăiește bine în Rusia”.
Așa că, odată ce gândul mi-a intrat în cap, după ceva timp a apărut prima idee de implementare. Totul părea simplu - trebuie să interceptați accesul la linkuri — instalați un proces de aplicație web local pe mașina dvs. la 127.0.0.1 și în /etc/hosts adăugați o intrare statică pentru domeniul companiei prin care intrați în conferință, indicând localhost. În continuare, acest server web trebuie să proceseze linkul care a venit la el și să îl transfere cumva în Pidgin (voi spune imediat că în această etapă încă nu aveam idee cum să i-o dau deloc). Soluția, desigur, miroase a cârje, dar noi suntem programatori, cârjele nu ne sperie (la rahat).
Apoi, întâmplător, am deschis cumva linkul de invitație în Google Chrome (și de obicei folosesc întotdeauna Mozilla Firefox). Și spre surprinderea mea, pagina web arăta complet diferit - nu exista niciun formular pentru introducerea datelor utilizatorului și imediat după intrarea în pagină a fost solicitat să deschidem ceva prin XDG-deschis. Doar pentru distracție, dau clic pe „da” și apare un mesaj de eroare - linkul lync15:confjoin?url=https://meet.company.com/user/confid nu poate fi deschis. Hmm. Ce fel de xdg-open este acesta și de ce are nevoie pentru ca astfel de link-uri să se deschidă? O citire post-mortem a documentației a arătat că este un handler GUI care ajută la rularea aplicațiilor asociate fie cu protocoale pentru schema uri, fie cu anumite tipuri de fișiere. Asociațiile sunt configurate prin mapare de tip mime. Deci vedem că rulăm o căutare pentru o aplicație potrivită pentru o schemă uri numită lync15 iar linkul este transmis către xdg-open, care apoi, în teorie, ar trebui să îl transmită unei aplicații care este responsabilă pentru acest tip de legătură. Pe care, desigur, nu îl avem în sistemul nostru. Dacă nu, atunci ce fac ei în lumea open source? Așa este, o vom scrie singuri.
O imersiune suplimentară în lumea Linux și mai ales în studierea modului în care funcționează shell-ul grafic (mediu desktop, DE), apropo, am Xfce în Linux Mint, a arătat că aplicațiile și tipul mime asociat cu acesta sunt de obicei scrise direct în fișiere de comandă rapidă cu extensia .desktop. Ei bine, de ce nu, creez o comandă rapidă simplă pentru aplicație, care ar trebui pur și simplu să lanseze un script bash și să scoată argumentul transmis către consolă, furnizez doar fișierul de comandă rapidă în sine:
[Desktop Entry]
Name=Lync
Exec=/usr/local/bin/lync.sh %u
Type=Application
Terminal=false
Categories=Network;InstantMessaging;
MimeType=x-scheme-handler/lync15;
Lansez xdg-open din consola, trecand acelasi link care vine din browser si... pacat. Din nou se spune că nu poate procesa linkul.
După cum se dovedește, nu am actualizat directorul de tipuri mime asociate cu aplicația mea. Acest lucru se face cu o comandă simplă:
xdg-mime default lync.desktop x-scheme-handler/lync15
care pur și simplu editează fișierul ~/.config/mimeapps.list.
Încercați numărul 2 cu apelul xdg-open - și din nou eșec. Nimic, dificultățile nu ne sperie, ci doar ne alimentează interesul. Și înarmați cu toată puterea bash (adică urmărirea), ne aruncăm cu capul înainte în depanare. Este important să rețineți că xdg-open este doar un script shell.
bash -x xdg-open $url
Analizând rezultatul după urmărire, devine puțin clar că controlul este apoi transferat exo-deschis. Și acesta este deja un fișier binar și este mai greu de înțeles de ce returnează un cod de returnare nereușit atunci când trece un link către acesta într-un argument.
După ce m-am uitat prin elementele interne ale xdg-open, am aflat că analizează diverși parametri de mediu și transmite controlul mai departe fie unor instrumente pentru deschiderea legăturilor de fișiere specifice unui anumit DE, fie are o funcție de rezervă. 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
}
Voi încorpora rapid aici un mic hack cu analiza argumentului transmis și dacă subșirul nostru specific se află acolo lync15:, apoi transferăm imediat controlul funcției open_generic.
Încercați numărul 3 și credeți că a funcționat? Da, acum, desigur. Dar mesajul de eroare s-a schimbat deja, acesta este deja progres - acum îmi spunea că fișierul nu a fost găsit și sub formă de fișier mi-a scris același link trecut ca argument.
De data aceasta s-a dovedit a fi o funcție is_file_url_or_path, care analizează linkul de fișier transmis la intrare: file:// sau calea către fișier sau altceva. Și verificarea nu a funcționat corect din cauza faptului că prefixul nostru (schema URL) are numere, iar expresia regulată verifică doar setul de caractere format din :alpha: puncte și liniuțe. După consultarea standardului rfc3986 pentru identificator uniform de resursă A devenit clar că de data aceasta Microsoft nu încalcă nimic (deși am avut o astfel de versiune). Doar clasa de caractere :alpha: conține doar litere ale alfabetului latin. Schimb rapid verificarea obișnuită în alfanumeric. Gata, sunteți uimitor, totul începe în sfârșit, controlul după toate verificările este dat aplicației noastre de script, linkul nostru este afișat pe consolă, totul este așa cum ar trebui să fie. După aceasta, încep să bănuiesc că toate problemele cu exo-open se datorează și validării formatului link-ului din cauza numerelor din schemă. Pentru a testa ipoteza, schimb înregistrarea de tip mime a aplicației la doar o schemă Lync și voilà - totul funcționează fără a suprascrie funcția open_xfce. Dar acest lucru nu ne va ajuta în niciun fel, deoarece pagina web pentru intrarea în conferință creează un link cu lync15.
Deci, prima parte a călătoriei a fost finalizată. Știm cum să interceptăm un apel de legătură și apoi trebuie să fie procesat cumva și transmis în interiorul Pidgin. Pentru a înțelege cum funcționează intern atunci când introduceți date printr-un link în meniul „alăturați-vă unei conferințe”, am clonat depozitul Git al proiectului Sipe și m-am pregătit să merg din nou în cod. Dar apoi, din fericire, m-au atras scenariile din catalog contributie/dbus/:
- sipe-join-conference-with-uri.pl
- sipe-join-conferinta-cu-organizator-si-id.pl
- sipe-call-phone-number.pl
- SipeHelper.pm
Se pare că pluginul Sipe este disponibil pentru interacțiune prin dbus (desktop bus) iar în interiorul scripturilor există exemple de participare la o conferință prin intermediul unui link, fie prin numele organizatorului și conf-id, fie puteți iniția un apel prin sip . Este exact ceea ce ne lipsea.
Pasul 2. Implementarea unui handler de autojoin
Deoarece există exemple gata făcute în Pearl, am decis să folosesc doar sipe-join-conference-with-uri.pl și modificați-l puțin pentru a vă potrivi. Pot să scriu în Pearl, așa că nu a cauzat dificultăți deosebite.
După ce am testat separat scriptul, am scris apelul său în fișier lync.desktop. Și a fost o victorie! Când intrați în pagina de participare la conferință și permiteți rularea xdg-open, fereastra pop-up conferință din Pidgin se deschidea automat. Cât m-am bucurat.
Încurajat de succes, am decis să fac același lucru pentru browserul meu principal, Mozilla Firefox. Când vă autentificați prin vulpe, se deschide o pagină pentru autorizare, iar în partea de jos există un buton alăturați-vă folosind Office Communicator. Ea a fost cea care mi-a atras atenția. Când faceți clic pe el în browser, acesta merge la adresa:
conf:sip:{user};gruu;opaque=app:conf:focus:id:{conf-id}%3Frequired-media=audio
la care îmi spune cu amabilitate că nu știe să-l deschidă și, poate, nu am o aplicație asociată pentru un astfel de protocol. Ei bine, deja am trecut prin asta.
Îmi înregistrez rapid aplicația de script și pentru schema uri conf și... nu se întâmplă nimic. Browserul continuă să se plângă că nu există nicio aplicație care să gestioneze linkurile mele. În acest caz, apelarea xdg-open din consola cu parametri funcționează perfect.
„Setați un handler de protocol personalizat în firefox” - am intrat online cu această întrebare. După ce am trecut prin mai multe discuții despre stackoverflow (și unde am fi fără el), se pare că răspunsul a fost găsit. Trebuie să creați un parametru special în about: config (desigur, înlocuind foo cu conf):
network.protocol-handler.expose.foo = false
Îl creăm, deschidem link-ul și... nici un astfel de noroc. Browserul, de parcă nu s-ar fi întâmplat nimic, spune că nu cunoaște aplicația noastră.
Citesc documentația oficială privind înregistrarea unui protocol de la Mozilla, există o opțiune de a înregistra asocieri în desktop-ul gnome (înlocuind foo cu conf, desigur):
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
Mă înregistrez, deschid browserul... și iarăși barbă.
Iată un rând din documentație îmi atrage atenția:
Data viitoare când faceți clic pe un link de tip protocol foo, vi se va întreba cu ce aplicație să o deschideți.
— Semyon Semenych
- Ahh
Nu facem clic pe link, dar pagina web pur și simplu schimbă window.location prin javascript. Scriu un fișier html simplu cu un link către protocolul conf, îl deschid în browser, dați clic pe link - Yos! Se deschide o fereastră care ne întreabă în ce aplicație trebuie să ne deschidem linkul și acolo avem deja aplicația noastră Lync în listă - am înregistrat-o sincer în toate modurile posibile. Există, de asemenea, o casetă de selectare în fereastra „amintiți-vă alegerea și deschideți întotdeauna linkurile în aplicația noastră”, bifați-o și faceți clic pe ok. Și aceasta este a doua victorie - se deschide fereastra conferinței. În același timp, deschiderea conferințelor funcționează nu numai atunci când faceți clic pe un link, ci și atunci când treceți de la pagina de alăturare de care avem nevoie la conferință.
Apoi am verificat, ștergând parametrii network.protocol-handler.expose.conf nu a afectat în niciun fel funcționarea protocolului în Fox. Legăturile au continuat să funcționeze.
Concluzie
Am încărcat toată munca mea în depozitul GitHub. Linkurile către toate resursele vor fi la sfârșitul articolului.
Voi fi interesat să primesc feedback de la cei care doresc să folosească munca mea. Ar trebui să remarc imediat că am făcut toată dezvoltarea numai pentru sistemul meu Linux Mint, așa că este posibil ca unele alte distribuții sau desktop-uri să nu funcționeze în acea versiune. Sau, mai degrabă, sunt chiar aproape sigur de acest lucru, pentru că am corectat doar 1 funcție în xdg-open care se referă doar la DE-ul meu. Dacă doriți să adăugați suport pentru alte sisteme sau desktop-uri, scrieți-mi solicitări de extragere pe Github.
Întregul proiect a durat 1 seară pentru a fi finalizat.
referințe:
Sursa: www.habr.com