Hei Habr!
Minulle tämä lause on kuin hello world, koska sain vihdoin ensimmäisen julkaisuni. Lykkäsin tätä ihanaa hetkeä pitkäksi aikaa, koska ei ollut mitään kirjoitettavaa, enkä myöskään halunnut imeä jotain, mikä oli imetty jo monta kertaa. Yleisesti ottaen halusin ensimmäiseen julkaisuun jotain omaperäistä, muille hyödyllistä ja jonkinlaista haastetta ja ongelmanratkaisua sisältävää. Ja nyt voin jakaa tämän. Puhutaan nyt kaikesta järjestyksessä.
Merkintä
Kaikki alkoi, kun jokin aika sitten latasin Linux Mintin työtietokoneelleni. Monet ihmiset luultavasti tietävät, että Pidgin Sipe-laajennuksella on täysin sopiva korvike Microsoft Lyncille (nykyään Skype for business) Linux-järjestelmille. Työni erityispiirteistä johtuen joudun usein osallistumaan SIP-konferensseihin, ja kun olin Windows-työntekijä, konferensseihin osallistuminen oli alkeellista: saamme kutsun postitse, napsautamme kirjautumislinkkiä ja olemme valmiita lähtöön. .
Linuxin pimeälle puolelle vaihdettaessa kaikki muuttui hieman monimutkaisemmaksi: konferensseihin voi toki kirjautua myös Pidginissä, mutta tätä varten sinun on valittava SIP-tilisi ominaisuuksien valikosta liity konferenssiin -vaihtoehto ja Lisää avautuvaan ikkunaan linkki konferenssiin tai kirjoita järjestäjän nimi ja conf id. Ja jonkin ajan kuluttua aloin ajatella: "Voiko tätä jotenkin yksinkertaistaa?" Joo, saatat sanoa, miksi helvetissä tarvitset tätä? Istun mieluummin Windowsin päällä enkä räjäyttää mieltäni.
Vaihe 1: Tutkimus
"Jos päähän tulee oikkua, et voi tyrmätä sitä panokseen", Nekrasov sanoi teoksessaan "Who Lives Well in Venäjä".
Joten kun ajatus pääsi päähäni, jonkin ajan kuluttua syntyi ensimmäinen idea toteuttamisesta. Kaikki näytti yksinkertaiselta - sinun on keskeytettävä pääsy linkkeihin — asenna paikallinen verkkosovellusprosessi autoosi osoitteessa 127.0.0.1 ja lisää hakemistoon /etc/hosts yrityksen toimialueelle staattinen merkintä, jonka kautta osallistut konferenssiin, osoittaen localhost. Seuraavaksi tämän verkkopalvelimen täytyy käsitellä siihen saapunut linkki ja siirtää se jotenkin Pidginin sisään (sanoan heti, että tässä vaiheessa minulla ei vielä ollut aavistustakaan, miten se sille annetaan). Ratkaisu tietysti haisee kainalosauvoilta, mutta olemme ohjelmoijia, kainalosauvat eivät pelota meitä (paska).
Sitten, sattumalta, avasin kutsulinkin Google Chromessa (ja yleensä käytän aina Mozilla Firefoxia). Ja yllätyksekseni nettisivu näytti täysin erilaiselta - käyttäjätietojen syöttämistä varten ei ollut lomaketta ja heti sivulle sisääntulon jälkeen pyydettiin avaamaan jotain XDG- auki. Ihan huvikseni napsautan "kyllä" ja näkyviin tulee virheilmoitus - linkkiä lync15:confjoin?url=https://meet.company.com/user/confid ei voi avata. Hmm. Millainen xdg-open tämä on ja mitä se vaatii, jotta tällaiset linkit aukeavat? Dokumentaation post mortem -lukeminen paljasti, että se on GUI-käsittelijä, joka auttaa suorittamaan liittyviä sovelluksia joko uri-järjestelmän protokollien tai tiettyjen tiedostotyyppien kanssa. Assosiaatiot konfiguroidaan mime-tyyppisellä kartoituksella. Joten näemme, että etsimme sopivaa sovellusta uri-järjestelmälle nimeltä lync15 ja linkki välitetään xdg-openille, jonka sitten teoriassa pitäisi välittää se jollekin sovellukselle, joka on vastuussa tämäntyyppisestä linkistä. Mitä meillä ei tietenkään ole järjestelmässämme. Jos ei, niin mitä he tekevät avoimen lähdekoodin maailmassa? Aivan oikein, kirjoitamme sen itse.
Syvästyttäminen Linuxin maailmaan ja erityisesti graafisen kuoren (työpöytäympäristö, DE) toiminnan tutkiminen, minulla on muuten Xfce Linux Mintissa, osoitti, että sovellukset ja siihen liittyvä mime-tyyppi kirjoitetaan yleensä suoraan pikakuvaketiedostot, joiden tunniste on .desktop. No, miksi ei, luon yksinkertaisen sovelluksen pikakuvakkeen, jonka pitäisi yksinkertaisesti käynnistää bash-skripti ja tulostaa sille välitetty argumentti konsoliin, tarjoan vain itse pikakuvaketiedoston:
[Desktop Entry]
Name=Lync
Exec=/usr/local/bin/lync.sh %u
Type=Application
Terminal=false
Categories=Network;InstantMessaging;
MimeType=x-scheme-handler/lync15;
Käynnistän xdg-open konsolista, välitän saman linkin, joka tulee selaimesta ja... hämmentävää. Jälleen se sanoo, että se ei voi käsitellä linkkiä.
Kuten kävi ilmi, en päivittänyt sovelluksellani liittyvien mime-tyyppien hakemistoa. Tämä tehdään yksinkertaisella komennolla:
xdg-mime default lync.desktop x-scheme-handler/lync15
joka yksinkertaisesti muokkaa tiedostoa ~/.config/mimeapps.list.
Yritys numero 2 xdg-open kutsulla - ja taas epäonnistuminen. Ei mitään, vaikeudet eivät pelota meitä, vaan vain lisäävät kiinnostusta. Ja aseistettuna kaikella bashin (eli jäljittämisen) voimalla, sukeltamme pää edellä virheenkorjaukseen. Tässä on tärkeää huomata, että xdg-open on vain komentotulkkikomentosarja.
bash -x xdg-open $url
Analysoimalla tulosta jäljityksen jälkeen tulee hieman selväksi, että ohjaus siirtyy sitten ekso-avoin. Ja tämä on jo binääritiedosto, ja on vaikeampaa ymmärtää, miksi se palauttaa epäonnistuneen palautuskoodin, kun se välittää linkin sille argumentissa.
Tarkastellessani xdg-openin sisäosia huomasin, että se analysoi erilaisia ympäristöparametreja ja siirtää ohjauksen edelleen joko joillekin työkaluille, joilla avataan tiettyä DE:tä koskevia tiedostolinkkejä, tai siinä on varatoiminto. 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
}
Upotan tähän nopeasti pienen hakkeroinnin, jossa analysoidaan läpäissyt argumentti ja löytyykö tietty alimerkkijonomme siellä lync15:, siirrämme ohjauksen välittömästi funktiolle open_generic.
Yritys numero 3 ja toimiko se mielestäsi? Joo, nyt tietysti. Mutta virheilmoitus on jo muuttunut, tämä on jo edistystä - nyt hän kertoi minulle, että tiedostoa ei löydy ja hän kirjoitti minulle tiedoston muodossa, että sama linkki meni argumenttina.
Tällä kertaa se osoittautui toiminnaksi on_tiedoston_url_tai_polku, joka analysoi syötteeseen välitetyn tiedostolinkin: file:// tai tiedoston polun tai jotain muuta. Ja tarkistus ei toiminut oikein johtuen siitä, että etuliitteessämme (url-skeemassamme) on numeroita ja säännöllinen lauseke tarkistaa vain merkistön, joka koostuu :alpha: pisteistä ja katkoksista. Kun olet tutustunut rfc3986-standardiin yhtenäinen resurssitunniste Kävi selväksi, että tällä kertaa Microsoft ei riko mitään (vaikka minulla oli sellainen versio). Vain merkkiluokka :alpha: sisältää vain latinalaisten aakkosten kirjaimia. Vaihdan nopeasti tavallisen sekin aakkosnumeeriseksi. Valmis, olet hämmästyttävä, kaikki alkaa vihdoin, ohjaus sen jälkeen, kun kaikki tarkastukset on annettu komentosarjasovelluksellemme, linkkimme näkyy konsolissa, kaikki on niin kuin pitää. Tämän jälkeen aloin epäillä, että kaikki exo-open ongelmat johtuvat myös linkin muodon validoinnista kaavion numeroiden takia. Hypoteesin testaamiseksi vaihdan sovelluksen mime-tyyppisen rekisteröinnin pelkkäksi skeemaksi ilves ja voila - kaikki toimii ohittamatta open_xfce-funktiota. Mutta tämä ei auta meitä millään tavalla, koska konferenssiin pääsyn verkkosivu luo linkin lync15:een.
Matkan ensimmäinen osa on siis suoritettu. Tiedämme kuinka siepata linkkipuhelu ja sitten se täytyy jotenkin käsitellä ja välittää Pidginin sisällä. Ymmärtääkseni, kuinka se toimii sisäisesti syötettäessä tietoja "liity konferenssiin" -valikon linkin kautta, kloonasin Sipe-projektin Git-arkiston ja valmistauduin sukeltamaan uudelleen koodiin. Mutta sitten, onneksi, minua houkuttelivat luettelon käsikirjoitukset contrib/dbus/:
- sipe-join-conference-with-uri.pl
- sipe-join-conference-with-organizer-and-id.pl
- sipe-call-phone-number.pl
- SipeHelper.pm
Osoittautuu, että Sipe-laajennus on käytettävissä vuorovaikutukseen dbus-väylän (desktopbus) kautta ja skriptien sisällä on esimerkkejä neuvotteluun liittymisestä linkin kautta, joko järjestäjän nimen ja conf-id:n kautta, tai voit aloittaa puhelun sip:n kautta. . Juuri tätä meiltä puuttui.
Vaihe 2. Automaattisen liitoskäsittelijän käyttöönotto
Koska Pearlissä on valmiita esimerkkejä, päätin vain käyttää sipe-join-conference-with-uri.pl ja muokkaa sitä hieman itsellesi sopivaksi. Osaan kirjoittaa Pearl-kielellä, joten se ei aiheuttanut erityisiä vaikeuksia.
Testattuani skriptin erikseen, kirjoitin sen kutsun tiedostoon lync.desktop. Ja se oli voitto! Kun siirryt konferenssin liittymissivulle ja annat xdg-openin toimia, Pidginin neuvottelun ponnahdusikkuna avautuu automaattisesti. Kuinka minä iloitsin.
Menestyksen rohkaisemana päätin tehdä saman pääselaimelleni, Mozilla Firefoxille. Kun kirjaudut sisään ketun kautta, aukeaa valtuutussivu ja aivan alareunassa on painike Liity toimistokommunikaattorilla. Hän oli se, joka kiinnitti huomioni. Kun napsautat sitä selaimessa, se siirtyy osoitteeseen:
conf:sip:{user};gruu;opaque=app:conf:focus:id:{conf-id}%3Frequired-media=audio
johon hän ystävällisesti kertoo minulle, ettei hän osaa avata sitä ja kenties minulla ei ole vastaavaa sovellusta tällaiselle protokollalle. No, olemme jo käyneet tämän läpi.
Rekisteröin nopeasti skriptisovellukseni myös uri-järjestelmään conf ja... mitään ei tapahdu. Selain valittaa jatkuvasti, ettei ole olemassa sovellusta, joka käsittelee linkkejäni. Tässä tapauksessa xdg-open kutsuminen konsolista parametreilla toimii täydellisesti.
"Aseta mukautettu protokollakäsittelijä firefoxissa" - Menin verkkoon tämän kysymyksen kanssa. Käytyämme läpi useita keskusteluja stackoverflowsta (ja missä olisimme ilman sitä), näyttää siltä, että vastaus löytyi. Sinun on luotava erityinen parametri about: config (tietenkin korvaamalla foo:lla conf):
network.protocol-handler.expose.foo = false
Luomme sen, avaamme linkin ja... ei onnea. Selain, ikään kuin mitään ei olisi tapahtunut, sanoo, ettei se tunne sovellustamme.
Luen Mozillan protokollan rekisteröintiä koskevia virallisia asiakirjoja, itse gnome-työpöydällä on mahdollisuus rekisteröidä assosiaatiot (korvaamalla foo tietysti conf:lla):
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
Rekisteröidyn, avaan selaimen... ja taas parran.
Tässä kohta dokumentaatiosta pistää silmääni:
Kun seuraavan kerran napsautat protokollatyyppistä foo-linkkiä, sinulta kysytään, millä sovelluksella se avataan.
- Semjon Semenych
- Ahh
Emme klikkaa linkkiä, mutta verkkosivu yksinkertaisesti muuttaa window.location -paikkaa javascriptin avulla. Kirjoitan yksinkertaisen html-tiedoston, jossa on linkki conf-protokollaan, avaa se selaimessa, napsauta linkkiä - Yos! Ikkuna avautuu, jossa kysytään, missä sovelluksessa meidän on avattava linkkimme, ja siellä meillä on jo Lync-sovelluksemme luettelossa - rekisteröimme sen rehellisesti kaikilla mahdollisilla tavoilla. Siellä ikkunassa on valintaruutu "muista valinta ja avaa linkit aina sovelluksessamme", merkitse se, napsauta ok. Ja tämä on toinen voitto - konferenssiikkuna avautuu. Samalla konferenssien avaaminen ei toimi vain linkkiä napsauttaessa, vaan myös siirtyessämme tarvitsemamme liittymissivulta konferenssiin.
Sitten tarkistin ja poistin parametrit network.protocol-handler.expose.conf ei millään tavalla vaikuttanut protokollan toimintaan Foxissa. Linkit jatkoivat toimintaansa.
Johtopäätös
Olen ladannut kaiken työni GitHub-arkistoon; linkit kaikkiin resursseihin ovat artikkelin lopussa.
Olen kiinnostunut saamaan palautetta niiltä, jotka haluavat käyttää työtäni. Haluan heti huomauttaa, että tein kaiken kehitystyön vain Linux Mint -järjestelmälleni, joten jotkin muut jakelut tai työpöydät eivät välttämättä toimi kyseisessä versiossa. Tai pikemminkin olen jopa melkein varma tästä, koska korjasin vain yhden funktion xdg-openissa, joka liittyy vain DE:heni. Jos haluat lisätä tukea muille järjestelmille tai pöytäkoneille, kirjoita minulle vetopyyntöjä Githubissa.
Koko projektin valmistuminen kesti yhden illan.
viitteet:
Lähde: will.com