Automaatne sisenemine Lynci konverentsidesse Linuxis

Tere, Habr!

See fraas on mulle nagu hello world, kuna olen lõpuks jõudnud oma esimese avalduse juurde. Olen seda imelise hetke kaua edasi lükanud, sest kirjutada ei olnud millestki, ning ka juba mitu korda arutatud teemasid uuesti arutama ei soovinud. Üldiselt tahtsin oma esimeses avalduses midagi originaalset, teistele kasulikku ning sellist, mis sisaldaks mingisugust väljakutset ja probleemide lahendamist. Ja nüüd saan seda juba jagada. Räägime nüüd kõikidest detailidest.

Sissejuhatus

Kõik algas sellest, et mõni aeg tagasi installisin oma töölauale Linux Mint'i. Paljud meist teavad kindlasti, et Pidgin koos Sipe pluginaga on täiesti hea asend Microsoft Lyncile (praegu tuntud kui Skype for Business) Linuxi süsteemidele. Oma töö spetsiifika tõttu pean tihti osalema sip-konverentsides, ja kui olin veel Windowsi kasutaja, oli konverentsidesse sisenemine elementaarne: saame kutse e-posti teel, klikkime sisenemislingile ja oleme kohal.

Linuxi tumedale poole üleminek muutis kõik natuke keerulisemaks: konverentsidesse sisenemine Pidginis loomulikult on olemas, kuid seal on vaja oma sip-konto omadustes valida konverentsiga liitumise punkt menüüs ja avanenud aknas lisada konverentsi link või sisestada korraldaja nimi ja konfi ID. Ja pärast mõnda aega hakkasin ma mõtlema: "aga kas võiks seda kuidagi lihtsamaks teha?" Aha, ütlete teie, miks sul seda vaja on, oleksid Windowsis ja ei muretsenud.

Samm 1. Uurimine

"Kui pähe sügeleb mingi lollus — ei saa seda sealt väljastada" — ütles Nekrassov oma teoses "Kellel Venemaal elada on hea".

Nüüd, kui mõte oli pead pannud, tekkis mingil hetkel ka esimene idee elluviimiseks. Näis, et kõik on lihtne — tuleb linkide päringud kinni püüda. meet.company.com/user/confid — seadista oma seadmes kohaliku veebirakenduse protsess 127.0.0.1 ja lisage /etc/hosts failis staatiline kirje ettevõtte domeeni jaoks, mille kaudu toimub sisse logimine konverentsidele, viidates localhostile. Järgmine samm on see, et see veebiserver peab töötlema saadud lingi ja edastama selle kuidagi Pidgin'ile (ütlen kohe, et sellel hetkel polnud mul veel arusaama, kuidas ma seda talle üle annan). Lahendus lõhnab muidugi pärastlõunate järele, kuid me oleme ju programmeerijad, vigadega peame silmitsi seisma (nalja pärast).

Siis avasin ma kogemata kutselingi Google Chromes (tavaliselt kasutan alati Mozilla Firefoxi). Ja minu üllatuseks nägi veebileht hoopis teistsugune välja — seal ei olnud kasutajaandmete sisestamise vormi ja kohe pärast lehele sisenemist tuli palve millegi avamiseks läbi xdg-open. Huvi pärast klikin "jah" ja saan veateate - link lync15:confjoin?url=https://meet.company.com/user/confid ei saa avatud. Hmm. Mis asi on see xdg-open ning mida on tal vaja, et selliseid linke avada? Dokumentatsiooni lugemine näitas, et see on graafikakäitleja, mis aitab käivitada seotud rakendusi kas uri skeemide protokollide või teatud faili tüüpidena. Seosed seadistatakse mime-tüübi vastavuse kaudu. Niisiis, näeme, et meil käivitub otsing vastavat rakendust uri skeemile nimega lync15 ja link edastatakse xdg-open'ile, mis peaks edasi edastama selle mingile rakendusele, mis vastutab nende linkide tüübi eest. Mida meil süsteemis muidugi ei ole. Ja kuna seda pole, siis kuidas avatud lähtekoodiga maailmas toimivad? Õigus, kirjutame selle ise.

Süvenemine Linuxi maailma, eriti graafilise liidese (desktop environment, DE) õppimisse, mida muideks mina kasutan Xfce Linux Mintis, näitas, et rakenduste ja sellega seotud mime-type'id määratakse tavaliselt otse .desktop laiendiga otseteedeses failides. Noh, miks mitte, loon lihtsa rakenduse otsetee, mis peaks lihtsalt käivitama bash-skripti ja kuvama talle antud argumendi konsoolis, toon välja vaid otsetee faili:

[Desktop Entry]
Name=Lync
Exec=/usr/local/bin/lync.sh %u
Type=Application
Terminal=false
Categories=Network;InstantMessaging;
MimeType=x-scheme-handler/lync15;

Käivitan xdg-open konsoolist, edastades sama lingi, mis tuleb brauserist, ja... pettumus. Ta ütleb jälle, et ei saa linki töödelda.

Kuidas selgus, et ma ei olnud uuendanud seotud mime-type katalooge oma rakenduse jaoks. Selleks on lihtne käsk:

xdg-mime default lync.desktop x-scheme-handler/lync15

mis lihtsalt redigeerib faili ~/.config/mimeapps.list.

Katse number 2 xdg-open'i väljakutsumisega — ja jälle ebaõnnestumine. Pole hullu, raskused ei hirmuta meid, vaid ainult sütitavad huvi. Ja varustatud kogu bash'i võimega (st. jälgimisega) sukeldume sügavale tõrkeotsingusse. Siinkohal on oluline märkida, et xdg-open on lihtsalt shell-skript.

bash -x xdg-open $url

Analüüsides jälgimise väljundit, saab natuke aru, et juhtimine antakse edasi exo-open. See on juba binaarfail ja on keerulisem välja selgitada, miks see tagastab ebaõnnestunud väljastuskoodi, kui talle antakse link argumentina.

Uurides xdg-openi sisemust, avastasin, et see analüüsib erinevaid keskkonnaparameetreid ja suunab juhtimise edasi kas mõnele tööriistale, mis avab faililinke, mis on spetsiifilised konkreetsele töölauakeskkonnale, või sellel on tagasipöördumine funktsioonile 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
}

Panen siia kiiresti väikese häkki, et analüüsida edasi antud argumenti ja kui seal on meie spetsiifiline alamstring lync15:, siis suuname kohe juhtimise funktsiooni open_generic.

Katse number 3 ja kas te arvate, et see toimis? Aha, jah, muidugi. Kuid veateade on juba muutunud, see on juba edasiminek — nüüd ütles see mulle, et faili ei leitud ja faili asemel edastas selle sama lingi, mis anti argumentina.

Seekord oli probleem funktsionaalsuses is_file_url_or_path, mis analüüsib antud faili linki file:// või faili teed või midagi muud. Kontroll ei töötanud õigesti, kuna meie prefiks (url skeem) sisaldab numbreid ja regulaaravaldis kontrollib ainult tähe, punkti ja sidekriipsu komplekti. Pärast konsulteerimist standardiga rfc3986 uniform resource identifier oli selge, et seekord Microsoft ei riku midagi (kuigi mul oli selline versioon). Lihtsalt tähemärkide klass :alpha: sisaldab ainult ladina tähestiku tähti. Muudan regulaaravaldiste kontrolli kiiresti alfanumeriliseks. Valmis, olete imetlusväärsed, kõik lõpuks käivitub, kontrollide järel antakse juhtimine meie skripti-rakendusele, konsoolile väljastatakse meie link, kõik nagu peab. Pärast seda hakkan kahtlema, et kõik probleemid exo-openis on samuti tingitud linkide formaadi valideerimisest numbrite tõttu skeemis. Hüpoteesi kontrollimiseks muudan rakenduse mime-type registreerimise lihtsalt skeemiks lync ja voilà — kõik töötab ka ilma open_xfce funktsiooni üledefineerimiseta. Kuid see ei aita meid kuidagi, sest konverentsi sisenemise veebileht loob just selle lync15 lingi.

Nii et teel on tehtud esimene osa. Me oskame linkide kutseid kinni püüda ja nüüd tuleb see mingil moel töödelda ning edastada Pidgini sisse. Selleks, et mõista, kuidas see töötab, kui sisestatakse andmeid lingi kaudu menüüs 'konverentsile liitumine', kloonisin projekti Sipe git-reposi ja valmistusin taas koodi sukelduma. Kuid seekord tõmbasid mind õnneks skriptid kataloogis contrib/dbus/:

  • sipe-join-conference-with-uri.pl
  • sipe-join-conference-with-organizer-and-id.pl
  • sipe-call-phone-number.pl
  • SipeHelper.pm

Selgub, et Sipe plugin on saadaval dbus (desktop bus) kaudu suhtlemiseks ja skriptides on põhimõtted, kuidas liituda konverentsiga lingi kaudu, kas korraldaja nime ja conf-id kaudu või saab alustada kõnet läbi sip. See on just see, mis meil puudus.

Samm 2. Automaatse liitumise töödeldaja rakendamine

Kuna valmis näidised on Perl'is, siis otsustasin neid lihtsalt kasutada sipe-join-conference-with-uri.pl ja natuke enda järgi kohandada. Perl'is kirjutada oskan, seega ei tekkinud erilisi raskusi.

Pärast skripti eraldi testimist märkisin selle kutse faili lync.desktop. Ja see oli võit! Konverentsi liitumisse hääletamise lehte sisenedes ja xdg-open'i avamise loal konverentsi hüpikaken Pidgin'ist avanes automaatselt. Kuidas ma ei rõõmustanud!
Inspireerituna edust otsustasin teha sama ka oma peamise brauseri Mozilla Firefoxiga. Kui sisse logite läbi rebase, avaneb autentimise leht ja veel lehe allosas on nupp liitu Office Communicatoriga. Just see tõmbas minu tähelepanu. Kui sellele klikkida, suundub brauser aadressile:

conf:sip:{user};gruu;opaque=app:conf:focus:id:{conf-id}required-media=audio

ja selle peale ütleb ta mulle lahkesti, et ta ei tea, kuidas seda avada, ja võib-olla mul ei ole sellise protokolli jaoks assotsieeritud rakendust. No seda me oleme juba kogenud.

Registreerin kiiresti oma skripti rakenduse ka uri-skeemi conf ja... midagi ei juhtu. Brauser jätkab kaebamist, et rakendust, mis minu linke töötleb, ei ole. Samal ajal töötab konsoolist xdg-open'i kutsumine parameetritega suurepäraselt.

«Määra kohandatud protokolli käitleja Firefoxis» — selle küsimusega pöördusin Internetti. Otsisin mitu arutelu StackOverflow's, ja tundub, et vastus leiti. Pean looma spetsiaalse parameetri about:config (loomulikult asendades foo conf'iga):

network.protocol-handler.expose.conf = false

Loon, avame lingi ja... ei, ei läinud niisama. Brauser ütleb, et ei tunne meie rakendust.

Lugen ametlikku dokumentatsiooni protokolli registreerimise kohta Mozillalt, seal on võimalus määrata assotsiatsioone gnome desktop'is (loomulikult asendades foo conf'iga):

gconftool-2 -s /desktop/gnome/url-handlers/conf/command '/path/to/app %s' --type String
gconftool-2 -s /desktop/gnome/url-handlers/conf/enabled --type Boolean true

Registreerin, avame brauseri... ja jälle ei toimi.

Siin silma alla jääb dokumentatsioonist rida:

Järgmine kord, kui klikkite protokolli tüübiga foo linki, küsitakse teilt, millise rakendusega seda avada.

— Semjon Semjonovitš
— Aaaa

Me ei kliki lingile, vaid veebileht muudab window.location'i javascripti kaudu. Kirjutan lihtsalt HTML faili lingiga conf protokollile, avatud brauseris klikin lingile — Yos! Avaneb aken küsimusega, milles rakenduses peaksime meie linki avama, ja seal on juba meie rakendus Lync - oleme selle kõigi võimalikud viiside kaudu õigesti registreerinud. Samas aknas on ka märkeruut "mäleta valik ja ava linke alati meie rakenduses", märkime selle, vajutame ok. Ja see on teine võit — konverentsi aken avaneb. Samuti töötab konverentside avamine mitte ainult lingile klikkides, vaid ka mingeid soovitud lehti konverentsi liitumiseks.

Seejärel kontrollisin, kas parameetrite eemaldamine network.protocol-handler.expose.conf ei mõjutanud protokolli töötamist lises. Lingid jätkasid töötamist.

Kokkuvõte

Olen lisanud kõik oma saavutused GitHubi repositorisse, lingid kõikidele ressurssidele on artikli lõpus.
Olen huvitatud tagasiside saamisest nende käest, kes soovivad kasutada minu tehtud tööd. Tahan kohe märkida, et tegin arendust ainult oma Linux Mint süsteemi jaoks, seega võivad teised distributsioonid või töölauad mitte töötada selles variandis. Täpsemalt olen selle osas isegi peaaegu kindel, kuna patitsin xdg-open'is ainult ühe funktsiooni, mis puutub ainult minu DE-sse. Kui soovite lisada toetust teistele süsteemidele või töölauale, kirjutage mulle GitHubis pull-request'e.

Kogu projekti teostamine võttis ühe õhtu.

Lingid:

Allikas: habr.com

Osta usaldusväärne veebihosting DDoS kaitsega, VPS VDS serverid 🔥 Osta usaldusväärne veebihosting DDoS kaitsega, VPS VDS serverid | ProHoster