Szia Habr!
Számomra ez a mondat a hello world-hez hasonlít, hiszen végre eljutottam az első publikációmhoz. Sokáig halogattam ezt a csodás pillanatot, hiszen nem volt miről írni, és nem is akartam olyat szívni, amit már rengetegszer megszívtam. Általánosságban elmondható, hogy az első publikációmhoz valami eredetit, mások számára hasznosat szerettem volna, és valamiféle kihívást és problémamegoldást tartalmaz. És most megoszthatom ezt. Most beszéljünk mindent sorban.
Belépés
Az egész akkor kezdődött, amikor egy ideje letöltöttem a Linux Mint-et a munkahelyi számítógépemre. Valószínűleg sokan tudják, hogy a Pidgin a Sipe bővítménnyel teljesen megfelelő helyettesíti a Microsoft Lync-et (jelenleg Skype for business) Linux rendszereken. Munkám sajátosságaiból adódóan gyakran kell részt vennem SIP-konferenciákon, és amikor Windows-munkás voltam, a konferenciákra való belépés elemi volt: postai úton kapunk meghívót, kattintsunk a bejelentkezési linkre, és már indulhatunk is. .
Amikor a Linux sötét oldalára váltunk, minden bonyolultabbá vált: természetesen Pidginben is be lehet jelentkezni a konferenciákra, de ehhez a SIP-fiók tulajdonságai közül a menüben ki kell választani a konferencia csatlakozás opciót, a megnyíló ablakban szúrjon be egy hivatkozást a konferenciára, vagy írja be a szervező nevét és a konf id-t. És egy idő után elkezdtem gondolkodni: "lehet ezt valahogy leegyszerűsíteni?" Igen, azt mondanád, mi a fenének van erre szükséged? Inkább ülök a Windowson, és nem töröm a fejem.
1. lépés: Kutatás
„Ha valami szeszély támad a fejében, nem ütheti ki karóval” – mondta Nyekrasov a „Ki él jól Oroszországban” című művében.
Szóval, amint a gondolat a fejembe jutott, egy idő után felmerült az első ötlet a megvalósításhoz. Minden egyszerűnek tűnt - meg kell akadályoznia a hivatkozásokhoz való hozzáférést — telepítsen egy helyi webalkalmazási folyamatot az autójára a 127.0.0.1 címen, és az /etc/hosts fájlban adjon hozzá egy statikus bejegyzést a vállalati tartományhoz, amelyen keresztül belép a konferenciába, és a localhost-ra mutat. Ezután ennek a webszervernek fel kell dolgoznia a hozzá érkezett linket, és valahogy át kell vinnie a Pidginbe (azonnal elmondom, hogy ebben a szakaszban még fogalmam sem volt, hogyan adjam meg neki). A megoldás persze mankós, de mi programozók vagyunk, a mankók nem ijesztenek meg minket (szar).
Aztán véletlenül valahogy megnyitottam a meghívó linket a Google Chrome-ban (és általában mindig a Mozilla Firefoxot használom). Meglepetésemre a weboldal teljesen másképp nézett ki - nem volt űrlap a felhasználói adatok megadásához, és az oldalra való belépés után azonnal meg kellett nyitni valamit. xdg-open. Csak szórakozásból rákattintok az „igen” gombra, és megjelenik egy hibaüzenet – a lync15:confjoin?url=https://meet.company.com/user/confid hivatkozás nem nyitható meg. Hmm. Milyen xdg-open ez és mi kell hozzá, hogy ilyen linkek megnyíljanak? A dokumentáció utólagos olvasása során kiderült, hogy ez egy grafikus felületkezelő, amely segít a kapcsolódó alkalmazások futtatásában akár az uri-séma protokolljaival, akár meghatározott fájltípusokkal. Az asszociációk MIME típusú leképezéssel konfigurálhatók. Tehát azt látjuk, hogy egy megfelelő alkalmazást keresünk a nevű uri-séma számára lync15 és a hivatkozást átadjuk az xdg-open-nek, aminek elméletileg át kell adnia egy olyan alkalmazásnak, amely felelős az ilyen típusú hivatkozásokért. Ami természetesen nincs a rendszerünkben. Ha nem, akkor mit csinálnak a nyílt forráskódú világban? Így van, mi magunk írjuk meg.
A Linux világában való további elmélyülés, és különösen a grafikus shell (desktop környezet, DE) működésének tanulmányozásában, egyébként Xfce-em van Linux Mintben, megmutatta, hogy az alkalmazások és a hozzá tartozó mime-típusok általában közvetlenül íródnak parancsikonok .desktop kiterjesztéssel. Nos, miért ne, létrehozok egy egyszerű alkalmazás parancsikont, amely egyszerűen elindít egy bash szkriptet, és kiadja a neki átadott argumentumot a konzolnak, csak magát a parancsikont adom meg:
[Desktop Entry]
Name=Lync
Exec=/usr/local/bin/lync.sh %u
Type=Application
Terminal=false
Categories=Network;InstantMessaging;
MimeType=x-scheme-handler/lync15;
Elindítom a konzolról az xdg-open-t, ugyanazt a linket adom át, ami a böngészőből jön, és... dög. Ismét azt mondja, hogy nem tudja feldolgozni a hivatkozást.
Mint kiderült, nem frissítettem az alkalmazásommal a társított mime-típusok könyvtárát. Ez egy egyszerű paranccsal történik:
xdg-mime default lync.desktop x-scheme-handler/lync15
amely egyszerűen szerkeszti a fájlt ~/.config/mimeapps.list.
Kísérlet a 2. számú xdg-open hívással - és ismét kudarc. Semmi, a nehézségek nem ijesztenek meg minket, hanem csak táplálják az érdeklődésünket. És a bash (azaz a nyomkövetés) minden erejével felvértezve fejest ugrunk a hibakeresésbe. Itt fontos megjegyezni, hogy az xdg-open csak egy shell szkript.
bash -x xdg-open $url
A nyomkövetés után elemezve a kimenetet egy kicsit világossá válik, hogy a vezérlés ezután átkerül a következőre exo-nyitva. És ez már egy bináris fájl, és nehezebb megérteni, hogy miért ad vissza sikertelen visszatérési kódot, amikor egy argumentumban ad át egy hivatkozást.
Átnéztem az xdg-open belsejét, és rájöttem, hogy különféle környezeti paramétereket elemz, és továbbadja az irányítást vagy bizonyos eszközöknek, amelyek egy adott DE-hez specifikus fájlhivatkozásokat nyitnak meg, vagy van tartalék funkciója. 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
}
Gyorsan beágyazok ide egy kis hacket, amely elemzi az átadott argumentumot, és azt, hogy az adott részkarakterláncunk ott található-e lync15:, akkor azonnal átadjuk a vezérlést a függvénynek open_generic.
3. próbálkozás, és szerinted sikerült? Igen, most, persze. De a hibaüzenet már megváltozott, ez már előrelépés - most azt mondta, hogy a fájl nem található, és fájl formájában azt írta nekem, hogy ugyanaz a hivatkozás ment át érvként.
Ezúttal funkciónak bizonyult is_file_url_or_path, amely elemzi a bemenetnek átadott fájlhivatkozást: file:// vagy a fájl elérési útját vagy valami mást. Az ellenőrzés pedig azért nem működött megfelelően, mert az előtagunk (url-séma) számokat tartalmaz, a reguláris kifejezés pedig csak az :alpha: pontokból és kötőjelekből álló karakterkészletet ellenőrzi. Miután megvizsgálta az rfc3986 szabványt egységes erőforrás-azonosító Világossá vált, hogy a Microsoft ezúttal nem sért semmit (bár nekem volt ilyen verzióm). Csak az :alpha: karakterosztály csak a latin ábécé betűit tartalmazza. Gyorsan lecserélem a normál csekket alfanumerikusra. Kész, elképesztő vagy, végre minden elindul, a kontrollt minden ellenőrzés után megkapja a script alkalmazásunk, a linkünk megjelenik a konzolon, minden úgy van, ahogy lennie kell. Ezek után kezdek gyanakodni, hogy az exo-open minden problémája a link formátumának a sémában szereplő számok miatti érvényesítéséből adódik. A hipotézis tesztelésére az alkalmazás mime típusú regisztrációját csak egy sémára változtatom Lync és íme – minden működik az open_xfce függvény felülírása nélkül. De ez semmiben nem segít nekünk, mert a konferenciára való belépéshez szükséges weboldal linket hoz létre a lync15-tel.
Tehát az utazás első része befejeződött. Tudjuk, hogyan kell elkapni egy linkhívást, majd azt valahogy feldolgozni és továbbítani kell a Pidginben. Annak érdekében, hogy megértsem, hogyan működik belsőleg a „csatlakozás a konferenciához” menüben található hivatkozáson keresztül történő adatbevitelkor, klónoztam a Sipe projekt Git tárházát, és készen álltam, hogy újra belemerüljek a kódba. De aztán szerencsére vonzottak a forgatókönyvek a katalógusban contrib/dbus/:
- sipe-join-conference-with-uri.pl
- sipe-join-conference-with-organizer-and-id.pl
- sipe-call-phone number.pl
- SipeHelper.pm
Kiderült, hogy a Sipe plugin elérhető a dbus-on (desktop bus) keresztüli interakcióhoz, és a szkripteken belül vannak példák arra, hogy egy linken keresztül lehet csatlakozni egy konferenciához, akár a szervező nevével és conf-id-jével, akár sip-en keresztül is kezdeményezhet hívást. . Pontosan ez hiányzott nekünk.
2. lépés: Autojoin kezelő megvalósítása
Mivel a Pearlben vannak kész példák, úgy döntöttem, hogy csak használom sipe-join-conference-with-uri.pl és módosítsa egy kicsit, hogy megfeleljen magának. Pearlben tudok írni, így nem okozott különösebb nehézséget.
A szkript külön tesztelése után a hívását beírtam a fájlba lync.desktop. És győzelem volt! Amikor belép a konferencia csatlakozási oldalára, és engedélyezi az xdg-open futtatását, a Pidgin konferencia felugró ablaka automatikusan megnyílik. Hogy örültem.
A sikeren felbuzdulva úgy döntöttem, hogy ugyanezt teszem a fő böngészőmnél, a Mozilla Firefoxnál is. Ha a rókán keresztül bejelentkezik, megnyílik az engedélyezési oldal, és a legalján van egy gomb csatlakozzon az irodai kommunikátor segítségével. Ő volt az, aki felkeltette a figyelmemet. Ha rákattint a böngészőben, a következő címre kerül:
conf:sip:{user};gruu;opaque=app:conf:focus:id:{conf-id}%3Frequired-media=audio
amire kedvesen közli, hogy nem tudja, hogyan kell megnyitni, és talán nincs is társított alkalmazásom ilyen protokollhoz. Nos, ezen már túl vagyunk.
Gyorsan regisztrálom a script alkalmazásomat az uri sémához is conf és... nem történik semmi. A böngésző folyamatosan panaszkodik, hogy nincs olyan alkalmazás, amely kezelné a linkjeimet. Ebben az esetben az xdg-open meghívása konzolról paraméterekkel tökéletesen működik.
„Egyéni protokollkezelő beállítása a firefoxban” – ezzel a kérdéssel felmentem az internetre. A stackoverflow-ról (és hol tartanánk e nélkül) több vitát követően úgy tűnik, meglett a válasz. Létre kell hoznia egy speciális paramétert about: config (természetesen a foo helyett conf):
network.protocol-handler.expose.foo = false
Létrehozzuk, megnyitjuk a linket és... nincs szerencsénk. A böngésző, mintha mi sem történt volna, azt mondja, hogy nem ismeri az alkalmazásunkat.
Olvasom a hivatalos dokumentációt a Mozilla protokoll regisztrálásáról, lehetőség van asszociációk regisztrálására magában a gnome asztalon (természetesen a foo helyett 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
Regisztrálok, megnyitom a böngészőt... és megint a szakáll.
A dokumentáció egy sora megragadja a szemem:
Ha legközelebb egy protokoll típusú foo hivatkozásra kattint, a rendszer megkérdezi, hogy melyik alkalmazással kell megnyitni.
- Szemjon Szemenics
- Ahh
Nem kattintunk a hivatkozásra, hanem a weboldal egyszerűen megváltoztatja a window.location helyét javascripten keresztül. Írok egy egyszerű html fájlt a conf protokoll hivatkozásával, megnyitom a böngészőben, rákattintok a linkre - Yos! Megnyílik egy ablak, amely megkérdezi, hogy melyik alkalmazásban kell megnyitnunk a hivatkozásunkat, és ott már szerepel a Lync alkalmazásunk a listában - őszintén, minden lehetséges módon regisztráltuk. Ott az ablakban van egy „emlékezzen a választásra, és mindig nyissa meg a hivatkozásokat az alkalmazásunkban” jelölőnégyzetet, jelölje be, kattintson az OK gombra. És ez a második győzelem – megnyílik a konferenciaablak. Ugyanakkor a konferenciák megnyitása nem csak akkor működik, ha egy linkre kattintasz, hanem akkor is, amikor a szükséges csatlakozási oldalról a konferenciára lépünk.
Aztán megnéztem, paramétereket törölve network.protocol-handler.expose.conf semmilyen módon nem befolyásolta a Fox protokoll működését. A linkek tovább működtek.
Következtetés
Minden munkámat feltöltöttem a GitHub tárházába; az összes forrásra mutató hivatkozások a cikk végén találhatók.
Érdekelni fogok visszajelzéseket azoktól, akik használni szeretnék a munkáimat. Azonnal meg kell jegyeznem, hogy az összes fejlesztést csak a Linux Mint rendszeremhez végeztem, így előfordulhat, hogy néhány más disztribúció vagy asztali számítógép nem működik ebben a verzióban. Illetve ebben szinte biztos is vagyok, mert az xdg-openben csak 1 olyan függvényt foltoztam be, ami csak a DE-mre vonatkozik. Ha más rendszerekhez vagy asztali számítógépekhez szeretne támogatást adni, írjon nekem lehívási kérelmeket a Githubon.
A teljes projekt 1 estét vett igénybe.
referenciák:
Forrás: will.com