Hé Habr!
Voor mij lijkt deze zin op Hallo wereld, sinds ik eindelijk bij mijn eerste publicatie ben aangekomen. Ik heb dit prachtige moment lang uitgesteld, omdat er niets was om over te schrijven, en ik wilde ook niet aan iets zuigen dat al een paar keer was opgezogen. Over het algemeen wilde ik voor mijn eerste publicatie iets origineels, nuttigs voor anderen en met een zekere uitdaging en probleemoplossing. En nu kan ik dit delen. Laten we nu alles in volgorde bespreken.
Toegang
Het begon allemaal toen ik enige tijd geleden Linux Mint op mijn werkcomputer downloadde. Veel mensen weten waarschijnlijk dat Pidgin met de Sipe-plug-in een volkomen geschikte vervanging is voor Microsoft Lync (nu Skype for Business genoemd) voor Linux-systemen. Vanwege de specifieke kenmerken van mijn werk moet ik vaak deelnemen aan SIP-conferenties, en toen ik een Windows-werknemer was, was het deelnemen aan conferenties eenvoudig: we ontvangen een uitnodiging per e-mail, klikken op de inloglink en we zijn klaar om te gaan .
Bij het overstappen naar de duistere kant van Linux werd alles wat ingewikkelder: je kunt natuurlijk ook inloggen op conferenties in Pidgin, maar hiervoor moet je de optie deelnemen aan conferentie selecteren in het menu in de eigenschappen van je SIP-account en in het geopende venster voegt u een link naar de conferentie in of voert u de naam van de organisator en het vertrouwelijke nummer in. En na een tijdje begon ik te denken: "is het mogelijk om dit op de een of andere manier te vereenvoudigen?" Ja, zou je kunnen zeggen: waarom heb je dit in vredesnaam nodig? Ik zit liever op Windows en word niet gek.
Stap 1: Onderzoek
"Als je een gril in je hoofd krijgt, kun je die niet uitschakelen met een paal", zei Nekrasov in zijn werk "Who Lives Well in Rus'."
Dus toen de gedachte eenmaal in mijn hoofd opkwam, ontstond na enige tijd het eerste idee voor implementatie. Alles leek eenvoudig: je moet de toegang tot links onderscheppen — installeer een lokaal webapplicatieproces op uw auto op 127.0.0.1 en voeg in /etc/hosts een statische vermelding toe voor het bedrijfsdomein waarmee u de conferentie betreedt, wijzend naar localhost. Vervolgens moet deze webserver de link verwerken die ernaartoe is gekomen en deze op de een of andere manier binnen Pidgin overbrengen (ik zal meteen zeggen dat ik in dit stadium nog steeds geen idee had hoe ik deze eraan moest geven). De oplossing ruikt natuurlijk naar krukken, maar wij zijn programmeurs, krukken maken ons niet bang (shit).
Toen opende ik toevallig op de een of andere manier de uitnodigingslink in Google Chrome (en meestal gebruik ik altijd Mozilla Firefox). En tot mijn verbazing zag de webpagina er heel anders uit: er was geen formulier voor het invoeren van gebruikersgegevens en onmiddellijk na het betreden van de pagina was er een verzoek om iets te openen via xdg open. Voor de lol klik ik op “ja” en er verschijnt een foutmelding - de link lync15:confjoin?url=https://meet.company.com/user/confid kan niet worden geopend. Hm. Wat voor soort xdg-open is dit en wat heeft het nodig om dergelijke links te openen? Uit een post-mortem lezing van de documentatie bleek dat het een GUI-handler is die helpt bij het uitvoeren van bijbehorende applicaties, hetzij met protocollen voor het uri-schema, hetzij met specifieke bestandstypen. Associaties worden geconfigureerd via MIME-type mapping. We zien dus dat we zoeken naar een overeenkomende applicatie voor een uri-schema met de naam Lync15 en de link wordt doorgegeven aan xdg-open, die deze vervolgens, in theorie, zou moeten doorgeven aan een applicatie die verantwoordelijk is voor dit type link. Wat wij uiteraard niet in ons systeem hebben. Zo niet, wat doen ze dan in de open source-wereld? Dat klopt, we zullen het zelf schrijven.
Verdere onderdompeling in de wereld van Linux en vooral in het bestuderen van hoe de grafische schil (desktopomgeving, DE) werkt, trouwens, ik heb Xfce in Linux Mint, toonde aan dat applicaties en het bijbehorende mime-type meestal rechtstreeks in snelkoppelingsbestanden met de extensie .desktop. Nou, waarom niet, ik maak een eenvoudige applicatiesnelkoppeling, die eenvoudigweg een bash-script moet starten en het doorgegeven argument naar de console moet uitvoeren. Ik geef alleen het snelkoppelingsbestand zelf:
[Desktop Entry]
Name=Lync
Exec=/usr/local/bin/lync.sh %u
Type=Application
Terminal=false
Categories=Network;InstantMessaging;
MimeType=x-scheme-handler/lync15;
Ik start xdg-open vanaf de console en geef dezelfde link door die uit de browser komt en... jammer. Opnieuw zegt hij dat hij de link niet kan verwerken.
Het blijkt dat ik de map met bijbehorende mime-typen niet heb bijgewerkt met mijn applicatie. Dit gebeurt met een eenvoudig commando:
xdg-mime default lync.desktop x-scheme-handler/lync15
die eenvoudig het bestand bewerkt ~/.config/mimeapps.list.
Poging nummer 2 met de xdg-open oproep - en opnieuw mislukt. Niets, moeilijkheden maken ons niet bang, maar voeden alleen onze interesse. En gewapend met alle kracht van bash (d.w.z. traceren), duiken we halsoverkop in het debuggen. Het is belangrijk op te merken dat xdg-open slechts een shellscript is.
bash -x xdg-open $url
Door de output te analyseren na het traceren, wordt het een beetje duidelijk waar de controle vervolgens op wordt overgedragen exo-open. En dit is al een binair bestand en het is moeilijker te begrijpen waarom het een mislukte retourcode retourneert wanneer er in een argument een link naar wordt doorgegeven.
Nadat ik de interne werking van xdg-open had doorgenomen, kwam ik erachter dat het verschillende omgevingsparameters analyseert en de controle verder doorgeeft aan een aantal tools voor het openen van bestandskoppelingen die specifiek zijn voor een bepaalde DE, of dat het een terugvalfunctie heeft. open_generiek
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
}
Ik zal hier snel een kleine hack insluiten met analyse van het doorgegeven argument en of onze specifieke substring zich daar bevindt lync15:, dan dragen we de controle onmiddellijk over aan de functie open_generiek.
Probeer nummer 3 en denk je dat het gelukt is? Ja, nu natuurlijk. Maar de foutmelding is al veranderd, dit is al vooruitgang - nu vertelde hij me dat het bestand niet was gevonden en in de vorm van een bestand schreef hij me dat dezelfde link als argument werd doorgegeven.
Deze keer bleek het een functie te zijn is_bestand_url_of_pad, dat de bestandslink analyseert die wordt doorgegeven aan de invoer: file:// of het pad naar het bestand of iets anders. En de controle werkte niet correct vanwege het feit dat ons voorvoegsel (url-schema) cijfers heeft, en de reguliere expressie alleen de tekenset controleert die bestaat uit :alpha: punten en streepjes. Na raadpleging van de rfc3986-standaard voor uniforme bronidentificatie Het werd duidelijk dat Microsoft deze keer niets schendt (hoewel ik zo'n versie had). Alleen de karakterklasse :alpha: bevat alleen letters van het Latijnse alfabet. Ik verander snel de gewone cheque in alfanumeriek. Klaar, je bent geweldig, alles begint eindelijk, controle na alle controles wordt gegeven aan onze scriptapplicatie, onze link wordt weergegeven op de console, alles is zoals het hoort. Hierna begin ik te vermoeden dat alle problemen met exo-open ook te wijten zijn aan de validatie van het linkformaat vanwege de cijfers in het schema. Om de hypothese te testen, verander ik de mime-typeregistratie van de applicatie in slechts een schema Lync en voila - alles werkt zonder de open_xfce-functie te overschrijven. Maar dit helpt ons op geen enkele manier, omdat de webpagina voor toegang tot de conferentie een link maakt met lync15.
Het eerste deel van de reis zit er dus op. We weten hoe we een linkoproep moeten onderscheppen en dan moet deze op de een of andere manier worden verwerkt en doorgegeven binnen Pidgin. Om te begrijpen hoe het intern werkt bij het invoeren van gegevens via een link in het menu “deelnemen aan een conferentie”, heb ik de Git-repository van het Sipe-project gekloond en maakte ik me klaar om opnieuw in de code te duiken. Maar toen werd ik gelukkig aangetrokken door de scripts in de catalogus bijdrage/dbus/:
- sipe-join-conference-with-uri.pl
- sipe-deelnemen aan-conferentie-met-organisator-en-id.pl
- sipe-call-telefoonnummer.pl
- SipeHelper.pm
Het blijkt dat de Sipe-plug-in beschikbaar is voor interactie via dbus (desktopbus) en in de scripts staan voorbeelden van deelname aan een conferentie via een link, hetzij via de naam en conf-id van de organisator, of u kunt een gesprek starten via sip . Dit is precies wat we misten.
Stap 2. Implementatie van een autojoin-handler
Omdat er kant-en-klare voorbeelden in Pearl staan, heb ik besloten om het gewoon te gebruiken sipe-join-conference-with-uri.pl en pas het een beetje aan, zodat het bij jou past. Ik kan in Pearl schrijven, dus het veroorzaakte geen bijzondere problemen.
Nadat ik het script afzonderlijk had getest, schreef ik de aanroep ervan in het bestand lync.desktop. En het was een overwinning! Wanneer u de pagina voor deelname aan de conferentie betreedt en xdg-open laat draaien, wordt het pop-upvenster voor de conferentie van Pidgin automatisch geopend. Wat was ik blij.
Aangemoedigd door het succes besloot ik hetzelfde te doen voor mijn hoofdbrowser, Mozilla Firefox. Wanneer je via de fox inlogt, opent er een pagina voor autorisatie en helemaal onderaan staat een knop deelnemen via kantoorcommunicator. Zij was degene die mijn aandacht trok. Wanneer u erop klikt in de browser, gaat het naar het adres:
conf:sip:{user};gruu;opaque=app:conf:focus:id:{conf-id}%3Frequired-media=audio
waarop hij me vriendelijk vertelt dat hij niet weet hoe hij het moet openen en misschien heb ik geen bijbehorende applicatie voor een dergelijk protocol. Nou, we hebben dit al meegemaakt.
Ik registreer mijn scripttoepassing snel ook voor het uri-schema conf en... er gebeurt niets. De browser blijft klagen dat er geen applicatie is die mijn links verwerkt. In dit geval werkt het aanroepen van xdg-open vanaf de console met parameters perfect.
"Aangepaste protocolhandler instellen in Firefox" - Ik ging online met deze vraag. Na verschillende discussies over stackoverflow te hebben gevoerd (en waar zouden we zijn zonder), lijkt het erop dat het antwoord is gevonden. U moet een speciale parameter aanmaken in about: config (uiteraard foo vervangen door conf):
network.protocol-handler.expose.foo = false
We maken het, openen de link en... geen geluk. De browser zegt, alsof er niets is gebeurd, dat hij onze applicatie niet kent.
Ik lees de officiële documentatie over het registreren van een protocol van Mozilla, er is een optie om associaties te registreren op de gnome-desktop zelf (uiteraard foo vervangen door 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
Ik registreer me, open de browser... en opnieuw de baard.
Hier valt me een regel uit de documentatie op:
De volgende keer dat u op een link van het protocolfoo klikt, wordt u gevraagd met welke toepassing u deze wilt openen.
— Semjon Semenych
- Ah
We klikken niet op de link, maar de webpagina verandert eenvoudigweg window.location via javascript. Ik schrijf een eenvoudig HTML-bestand met een link naar het conf-protocol, open het in de browser, klik op de link - Yos! Er wordt een venster geopend met de vraag in welke applicatie we onze link moeten openen, en daar hebben we onze Lync-applicatie al in de lijst staan - we hebben deze eerlijk op alle mogelijke manieren geregistreerd. Daar in het venster staat een selectievakje "Onthoud de keuze en open altijd links in onze applicatie", markeer het en klik op OK. En dit is de tweede overwinning - het conferentievenster gaat open. Tegelijkertijd werkt het openen van conferenties niet alleen wanneer u op een link klikt, maar ook wanneer u van de deelnamepagina naar de conferentie gaat.
Vervolgens controleerde ik het en verwijderde ik de parameters netwerk.protocol-handler.expose.conf had op geen enkele manier invloed op de werking van het protocol in Fox. De links bleven werken.
Conclusie
Ik heb al mijn werk geüpload naar de GitHub-repository; links naar alle bronnen staan aan het einde van het artikel.
Ik ben geïnteresseerd in feedback van degenen die mijn werk willen gebruiken. Ik moet meteen opmerken dat ik alle ontwikkeling alleen voor mijn Linux Mint-systeem heb gedaan, dus sommige andere distributies of desktops werken mogelijk niet in die versie. Of beter gezegd, ik ben hier zelfs bijna zeker van, omdat ik slechts 1 functie in xdg-open heb gepatcht die alleen betrekking heeft op mijn DE. Als je ondersteuning voor andere systemen of desktops wilt toevoegen, schrijf me dan pull-aanvragen op Github.
Het hele project nam 1 avond in beslag.
referenties:
Bron: www.habr.com