Hej Habra!
Dla mnie to zdanie jest jak witaj, świecie, skoro w końcu dotarłem do mojej pierwszej publikacji. Długo odkładałam ten cudowny moment, bo nie było o czym pisać, a nie chciałam też ssać czegoś, co było już ssane nie raz. Ogólnie rzecz biorąc, w przypadku mojej pierwszej publikacji chciałem czegoś oryginalnego, przydatnego dla innych i zawierającego pewnego rodzaju wyzwanie i rozwiązanie problemu. I teraz mogę się tym podzielić. Porozmawiajmy teraz o wszystkim w porządku.
Wejście
Wszystko zaczęło się, gdy jakiś czas temu pobrałem Linux Mint na swój służbowy komputer. Wiele osób zapewne wie, że Pidgin z wtyczką Sipe jest w pełni odpowiednim zamiennikiem Microsoft Lync (obecnie nazywanym Skype dla firm) dla systemów Linux. Ze względu na specyfikę mojej pracy często muszę brać udział w konferencjach SIP, a gdy byłem pracownikiem Windowsa, uczestnictwo w konferencjach było elementarne: dostajemy zaproszenie pocztą, klikamy w link do logowania i gotowe .
Po przejściu na ciemną stronę Linuksa wszystko stało się nieco bardziej skomplikowane: oczywiście do konferencji można logować się także w Pidginie, jednak w tym celu należy w menu we właściwościach swojego konta SIP zaznaczyć opcję dołącz do konferencji i w oknie, które się otworzy, wstaw link do konferencji lub wpisz nazwę organizatora i potwierdź. I po pewnym czasie zacząłem się zastanawiać: „czy da się to jakoś uprościć?” Tak, można by powiedzieć, po co ci to, do cholery, potrzebne? Wolę siedzieć w systemie Windows i nie zawracać sobie głowy.
Krok 1: Badania
„Jeśli wpadnie ci do głowy jakiś kaprys, nie możesz go przebić kołkiem” – stwierdził Niekrasow w swojej pracy „Kto dobrze żyje na Rusi”.
Tak więc, gdy tylko taka myśl przyszła mi do głowy, po pewnym czasie zrodził się pierwszy pomysł na realizację. Wszystko wydawało się proste - trzeba przechwycić dostęp do linków — zainstaluj w swoim samochodzie lokalną aplikację internetową pod adresem 127.0.0.1 i w pliku /etc/hosts dodaj statyczny wpis dla domeny firmowej, przez którą wchodzisz na konferencję, wskazując na localhost. Następnie ten serwer WWW musi przetworzyć link, który do niego przyszedł i jakoś przenieść go do wnętrza Pidgina (od razu powiem, że na tym etapie jeszcze nie miałem pojęcia, jak mu to w ogóle dać). Rozwiązanie oczywiście pachnie kulami, ale jesteśmy programistami, kule nam nie straszne (cholera).
Potem jakimś cudem otworzyłem link z zaproszeniem w przeglądarce Google Chrome (a zazwyczaj zawsze korzystam z przeglądarki Mozilla Firefox). I ku mojemu zaskoczeniu strona wyglądała zupełnie inaczej - nie było formularza do wpisania danych użytkownika i od razu po wejściu na stronę pojawiała się prośba o otwarcie czegoś przez xdg-open. Dla zabawy klikam „tak” i pojawia się komunikat o błędzie – nie można otworzyć łącza lync15:confjoin?url=https://meet.company.com/user/confid. Hmm. Co to za xdg-open i czego potrzebuje, aby takie linki się otwierały? Pośmiertna lektura dokumentacji ujawniła, że jest to moduł obsługi GUI, który pomaga uruchamiać powiązane aplikacje z protokołami dla schematu uri lub z określonymi typami plików. Powiązania są konfigurowane poprzez mapowanie typu MIME. Widzimy więc, że szukamy pasującej aplikacji dla schematu uri o nazwie Lync15 i link jest przekazywany do xdg-open, który następnie teoretycznie powinien go przekazać do jakiejś aplikacji odpowiedzialnej za tego typu link. Którego oczywiście nie mamy w naszym systemie. Jeśli nie, to co robią w świecie open source? Zgadza się, napiszemy to sami.
Dalsze zanurzenie się w świecie Linuksa, a zwłaszcza studiowanie działania powłoki graficznej (środowisko pulpitu, DE), nawiasem mówiąc, mam Xfce w Linux Mint, pokazało, że aplikacje i powiązany z nimi typ MIME są zwykle pisane bezpośrednio w pliki skrótów z rozszerzeniem .desktop. No cóż, czemu nie, tworzę prosty skrót do aplikacji, który powinien po prostu uruchomić skrypt bashowy i wyprowadzić przekazany mu argument do konsoli, udostępniam tylko sam plik skrótu:
[Desktop Entry]
Name=Lync
Exec=/usr/local/bin/lync.sh %u
Type=Application
Terminal=false
Categories=Network;InstantMessaging;
MimeType=x-scheme-handler/lync15;
Uruchamiam xdg-open z konsoli, przekazując ten sam link, który pochodzi z przeglądarki i... bumer. Znowu wyskakuje komunikat, że nie może przetworzyć łącza.
Jak się okazuje, w mojej aplikacji nie zaktualizowałem katalogu powiązanych typów MIME. Odbywa się to za pomocą prostego polecenia:
xdg-mime default lync.desktop x-scheme-handler/lync15
który po prostu edytuje plik ~/.config/mimeapps.list.
Próba numer 2 z wywołaniem xdg-open - i znowu porażka. Nic, trudności nas nie przerażają, a jedynie podsycają nasze zainteresowanie. Uzbrojeni w całą moc basha (tj. śledzenie) od razu rzucamy się w wir debugowania. Należy tutaj zauważyć, że xdg-open to tylko skrypt powłoki.
bash -x xdg-open $url
Analizując dane wyjściowe po prześledzeniu, staje się trochę jasne, że kontrola jest następnie przekazywana do egzo-otwarty. A to już jest plik binarny i trudniej zrozumieć, dlaczego zwraca nieudany kod powrotu, przekazując link do niego w argumencie.
Po przejrzeniu wewnętrznych elementów xdg-open odkryłem, że analizuje on różne parametry środowiskowe i przekazuje kontrolę albo niektórym narzędziom do otwierania łączy do plików specyficznych dla konkretnego DE, albo ma funkcję awaryjną open_ogólny
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
}
Na szybko zamieszczę tutaj mały hack z analizą przekazanego argumentu i tego, czy znajduje się tam nasz konkretny podciąg Lync15:, wówczas natychmiast przekazujemy kontrolę do funkcji open_ogólny.
Próba nr 3 i myślisz, że się udała? Tak, teraz, oczywiście. Ale komunikat o błędzie już się zmienił, to już jest postęp - teraz mi mówił, że pliku nie odnaleziono i w formie pliku napisał mi ten sam link przekazany jako argument.
Tym razem okazało się, że jest to funkcja is_file_url_or_path, który analizuje link do pliku przekazany na wejście: file:// lub ścieżkę do pliku lub coś innego. A sprawdzenie nie zadziałało poprawnie, ponieważ nasz prefiks (schemat adresu URL) zawiera liczby, a wyrażenie regularne sprawdza tylko zestaw znaków składający się z :alpha: kropek i myślników. Po zapoznaniu się ze standardem RFC3986 dla jednolity identyfikator zasobu Stało się jasne, że tym razem Microsoft niczego nie narusza (mimo że miałem taką wersję). Tylko klasa znaków :alpha: zawiera tylko litery alfabetu łacińskiego. Szybko zmieniam zwykłe sprawdzenie na alfanumeryczne. Gotowe, jesteś niesamowity, wszystko wreszcie się zaczyna, kontrola po wszystkich sprawdzeniach przekazana jest naszej aplikacji skryptowej, nasz link wyświetla się na konsoli, wszystko jest tak, jak powinno. Po tym zaczynam podejrzewać, że wszystkie problemy z exo-open wynikają również z walidacji formatu łącza ze względu na liczby w schemacie. Aby przetestować tę hipotezę, zmieniam rejestrację typu MIME aplikacji na zwykły schemat Lync i voila - wszystko działa bez przesłaniania funkcji open_xfce. Ale to nam w niczym nie pomoże, ponieważ strona internetowa umożliwiająca wejście na konferencję tworzy łącze z programem lync15.
Tak więc pierwsza część podróży została zakończona. Wiemy, jak przechwycić wywołanie łącza, a następnie należy je w jakiś sposób przetworzyć i przekazać do Pidgina. Aby zrozumieć, jak to działa wewnętrznie podczas wprowadzania danych poprzez link w menu „dołącz do konferencji”, sklonowałem repozytorium Git projektu Sipe i przygotowałem się do ponownego zanurzenia się w kodzie. Ale potem, na szczęście, przyciągnęły mnie skrypty w katalogu wkład/dbus/:
- sipe-join-conference-with-uri.pl
- sipe-dołącz-konferencja-z-organizatorem-i-id.pl
- sipe-call-numer-telefonu.pl
- SipeHelper.pm
Okazuje się, że wtyczka Sipe jest dostępna do interakcji poprzez dbus (desktop bus) i wewnątrz skryptów znajdują się przykłady dołączenia do konferencji poprzez link, albo poprzez nazwę organizatora i conf-id, albo można zainicjować połączenie poprzez sip . Właśnie tego nam brakowało.
Krok 2. Implementacja procedury automatycznego łączenia
Ponieważ w Pearl istnieją gotowe przykłady, zdecydowałem się po prostu skorzystać sipe-join-conference-with-uri.pl i zmodyfikuj go trochę tak, aby pasował do Ciebie. Umiem pisać w języku perłowym, więc nie sprawiało mi to szczególnych trudności.
Po osobnym przetestowaniu skryptu zapisałem jego wywołanie w pliku Lync.desktop. I to było zwycięstwo! Po wejściu na stronę dołączania do konferencji i zezwoleniu na uruchomienie xdg-open, wyskakujące okno konferencji z Pidgina otworzy się automatycznie. Jak się cieszyłem.
Zachęcony sukcesem postanowiłem zrobić to samo w przypadku mojej głównej przeglądarki Mozilla Firefox. Kiedy logujesz się przez lisa, otwiera się strona autoryzacji, a na samym dole znajduje się przycisk dołącz za pomocą komunikatora biurowego. To ona przykuła moją uwagę. Po kliknięciu w niego w przeglądarce trafia on pod adres:
conf:sip:{user};gruu;opaque=app:conf:focus:id:{conf-id}%3Frequired-media=audio
na co uprzejmie mi mówi, że nie wie jak go otworzyć i być może nie mam powiązanej aplikacji do takiego protokołu. Cóż, już przez to przeszliśmy.
Szybko rejestruję moją aplikację skryptową również dla schematu uri conf i... nic się nie dzieje. Przeglądarka ciągle narzeka, że nie ma aplikacji obsługującej moje linki. W tym przypadku wywołanie xdg-open z konsoli z parametrami działa idealnie.
„Ustaw niestandardową procedurę obsługi protokołu w przeglądarce Firefox” – z tym pytaniem udałem się do Internetu. Po przejrzeniu kilku dyskusji na temat przepełnienia stosu (i gdzie bylibyśmy bez niego) wygląda na to, że odpowiedź została znaleziona. Musisz utworzyć specjalny parametr w about: config (oczywiście zastępując foo przez conf):
network.protocol-handler.expose.foo = false
Tworzymy go, otwieramy link i... bez skutku. Przeglądarka jak gdyby nic się nie stało, mówi, że nie zna naszej aplikacji.
Czytam oficjalną dokumentację dotyczącą rejestracji protokołu z Mozilli, istnieje możliwość zarejestrowania skojarzeń w samym pulpicie gnome (oczywiście zastępując foo przez 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
Rejestruję się, otwieram przeglądarkę... i znowu broda.
Tutaj moją uwagę przykuwa linijka z dokumentacji:
Następnym razem, gdy klikniesz łącze typu foo, zostaniesz zapytany, w której aplikacji chcesz je otworzyć.
— Siemion Semenych
- Aha
Nie klikamy na link, ale strona internetowa po prostu zmienia lokalizację okna za pomocą JavaScript. Piszę prosty plik HTML z linkiem do protokołu conf, otwieram go w przeglądarce, klikam w link - Yos! Otwiera się okienko z pytaniem w jakiej aplikacji mamy otworzyć nasz link, a tam już mamy na liście naszą aplikację Lync - szczerze ją zarejestrowaliśmy na wszystkie możliwe sposoby. Tam w oknie znajduje się checkbox „zapamiętaj wybór i zawsze otwieraj linki w naszej aplikacji”, zaznacz go, kliknij OK. I to jest drugie zwycięstwo – otwiera się okno konferencji. Jednocześnie otwarcie konferencji działa nie tylko w momencie kliknięcia w link, ale także w momencie przejścia ze strony dołączenia potrzebnej nam do konferencji.
Następnie sprawdziłem, usuwając parametry network.protocol-handler.expose.conf w żaden sposób nie wpłynęło na działanie protokołu w Foxie. Linki nadal działały.
wniosek
Całą moją pracę przesłałem do repozytorium GitHub; linki do wszystkich zasobów znajdą się na końcu artykułu.
Będę zainteresowany otrzymaniem informacji zwrotnej od osób chcących skorzystać z mojej pracy. Powinienem od razu zauważyć, że cały rozwój wykonałem tylko dla mojego systemu Linux Mint, więc niektóre inne dystrybucje lub komputery stacjonarne mogą nie działać w tej wersji. A raczej jestem tego prawie pewien, bo załatałem tylko 1 funkcję w xdg-open, która dotyczy tylko mojego DE. Jeśli chcesz dodać obsługę innych systemów lub komputerów stacjonarnych, napisz do mnie pull request na Githubie.
Całość projektu zajęła 1 wieczór.
Linki:
Źródło: www.habr.com