Автоматичен вход в Lync конференции в Linux

Здравейте, Хабр!

За мен тази фраза е подобна на hello world, тъй като най-накрая стигнах до първата си публикация. Дълго отлагах този значим момент, защото нямаше какво да пиша, а не ми се искаше да обсъждам неща, които вече са многократно обсъждани. Всъщност, за първата си публикация исках нещо оригинално, полезно за другите и съдържащо известен предизвикателство и решение на проблеми. И ето, мога да споделя това. Сега за всичко по ред.

Въведение

Всичко започна с това, че преди известно време инсталирах Linux Mint на работния си компютър. Много от вас вероятно знаят, че Pidgin с приставката Sipe е съвсем добра алтернатива на Microsoft Lync (сега наречен Skype for business) за Linux системи. Поради спецификата на работата ми често трябва да участвам в SIP-конференции, и когато бях Windows потребител, влизането в конференции беше елементарно: получавахме покана по имейл, кликвахме на линка за вход и готово, бяхме вътре.

Когато преминах на тъмната страна на Linux, всичко стана по-сложно: влизането в конференции с Pidgin също е възможно, но там трябваше в настройките на вашия SIP-акаунт да изберете опцията за присъединяване към конференция от менюто и в отворения прозорец да поставите линка към конференцията или да въведете името на организатора и идентификатора на конференцията. И след известно време започнах да се замислям: "не може ли това да се опрости?" Аха, ще кажете вие, на какво ти е това, можеше да седиш на Windows и да не се тревожиш.

Стъпка 1. Изследване

"Каквато и глупост да се вмъкне в главата, трудно ще я изгони" — казвал е Некрасов в произведението си "Кому на Руси да живее добре".

И така, след като мисълта попадна в главата ми, след известно време се появи и първата идея за реализация. Изглеждаше просто — трябваше да захващам обращенията към линковете meet.company.com/user/confid — да инсталирам на локалния си компютър локален процес на уеб приложение на 127.0.0.1 и в /etc/hosts да добавя статичен запис за домейна на компанията, чрез който се влиза в конференциите, посочващ на localhost. След това този уеб сървър трябва да обработи получената линка и по някакъв начин да я предаде на Pidgin (веднага ще кажа, че в този етап нямаше да разбирам как ще му я дам). Решението, разбира се, мирише на импровизация, но ние сме програмисти, за нас импровизацията не е проблем (шега).

Така случайно открих линк за покана в Google Chrome (обикновено винаги използвам Mozilla Firefox). И на моето учудване уеб страницата изглеждаше съвсем различно — нямаше форма за въвеждане на потребителски данни и веднага след влизането на страницата излезе запитване за отваряне на нещо чрез xdg-open. От любопитство натискам "да" и излиза съобщение за грешка — линкът lync15:confjoin?url=https://meet.company.com/user/confid не може да бъде отворен. Хмм. Какво е това xdg-open и какво му е необходимо, за да могат такива линкове да се отварят? Разглеждането на документацията показа, че това е обработчик на графичната среда, който помага за стартиране на свързани приложения или с протоколи за uri scheme, или с определени типове файлове. Асоциациите се настройват чрез свързване на mime-type. И така, виждаме, че стартираме търсене на свързано приложение за uri scheme с името lync15 и линкът се предава на xdg-open, който по принцип трябва да го прехвърли на някое приложение, което отговаря за този тип линкове. Което, разбира се, нямаме в системата. А ако нямаме, какво правят в света на отворения код? Правилно, ще го напишем сами.

По-дълбокото навлизане в света на Linux, особено в изучаването на начина, по който работи графичната среда (desktop environment, DE), в случая аз използвам Xfce в Linux Mint, показа, че приложенията и свързаният с тях mime-type обикновено се записват право в файловете с прякор с разширение .desktop. А защо да не, създавам прост ярлик на приложението, който просто трябва да стартира баш-скрипт и да изведе предадения му аргумент на конзолата, представям само самия файл на ярлика:

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

стартирам xdg-open от конзолата с предаване на същия линк, който идва от браузера и… провал. Отново казва, че не може да обработи линка.

Както се оказа, не съм обновил каталога с асоциирани mime-type с моето приложение. Това става с простата команда:

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

която просто редактира файла ~/ .config/mimeapps.list.

Опит номер 2 с извикване на xdg-open — и отново неуспех. Нищо, трудностите не ни плашат, а само подхранват интереса. И с цялата мощ на баша (т.е. трасировката) се потапяме в отстраняване на грешки. Тук е важно да се отбележи, че xdg-open всъщност е просто шелл-скрипт.

bash -x xdg-open $url

Анализирайки резултатите от трасировката, става малко ясно, че управлението преминава към exo-open. Това вече е бинарен файл и разбирането защо той връща неуспешен статус код при предаване на линк в аргумента е по-сложно.

Изследвайки вътрешностите на xdg-open, разбрах, че той анализира различни параметри на средата и прехвърля управлението или на някакви инструменти за отваряне на файлове и линкове, специфични за конкретна DE, или има резервна функция 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
}

Бързо вмъквам тук малък хак с анализ на предадения аргумент и ако съдържа нашия специфичен подстринг lync15:, веднага предаваме управлението на функцията open_generic.

Опит номер 3 и вие мислите, че ще проработи? Аха, точно така. Но съобщението за грешка вече се промени, това е напредък — сега ми казваше, че файлът не е намерен и в него пишеше същия линк, предаден като аргумент.

Този път проблемът беше във функцията is_file_url_or_path, която анализира входен линк на файл file:// или път до файл или нещо друго. И проверката не работеше правилно, защото нашият префикс (url схема) съдържа цифри, а регулярното изражение проверяваше само набор от символи, състоящи се от :alpha:, точки и тирета. След консултация със стандарта rfc3986 за уникален ресурсен идентификатор стана ясно, че този път Microsoft не нарушава нищо (макар че имах подобна версия). Просто класът символи :alpha: съдържа само латински букви. Бързо променям проверката по регулярка на alphanumeric. Готово, вие сте невероятни, всичко накрая функционира, управлението след всички проверки се предава на нашето скрипт-приложение, на конзолата се извежда нашият линк, всичко каквото трябва. След това започвам да подозирам, че всички проблеми с exo-open също са заради валидирането на формата на линка заради цифрите в схемата. За проверка на хипотезата променям регистрацията на mime-type при приложението на просто схема lync и воала — всичко работи и без презаписване на функцията open_xfce. Но това по никакъв начин няма да ни помогне, защото уеб страницата за вход в конференцията създава именно линк с lync15.

И така, първата част от пътя е премината. Успяваме да прихванем извикването на линка и сега трябва да го обработим и предадем на Pidgin. За да разбера как работи вътре, когато въвеждаме данни по линка в менюто 'присъединяване към конференцията', клонирах Git репозитория на проекта Sipe и се подготвих отново да навляза в кода. Но тук, за щастие, ми привлече вниманието каталогът с скриптове. contrib/dbus/:

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

Оказа се, че плъгинът Sipe е достъпен за взаимодействие чрез dbus (desktop bus) и в самите скриптове има примери за присъединяване към конференция по линк, или чрез името на организатора и conf-id, или можем да инициираме обаждане през sip. Това е точно това, което ни липсваше.

Стъпка 2. Реализация на обработчика за автожойна

След като имаме готови примери на Perl, реших просто да използвам sipe-join-conference-with-uri.pl и да направя малко модификации по него. Пиша на Perl, затова не ми създаде особени трудности.

След тестиране на скрипта отделно, записах извикването му в файла lync.desktop. И това беше победа! При влизане на страницата за присъединяване към конференцията и разрешаване на стартиране на xdg-open, изскачащото прозорче на конференцията от Pidgin се отваряше автоматично. Как ли се радвах.
Вдъхновен от успеха, реших да направя същото и за основния си браузър Mozilla Firefox. Когато влизам през лисата, се отваря страница за авторизация и още в самия край има бутона присъедини се с office communicator. Той привлече вниманието ми. При кликване на него в браузъра се прехвърля адресът:

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

, на което той учтиво ми казва, че не знае как да го отвори и вероятно нямам асоциирано приложение за този протокол. Но вече минахме през това.

Бързо регистрирам приложението-скрипт и за uri-схемата conf и… нищо не се случва. Браузърът продължава да се оплаква, че няма приложение, което да обработва моите линкове. При това извикването от консолата xdg-open с параметри работи отлично.

„Set custom protocol handler in firefox“ — с този въпрос се обърнах към Интернет. Прегледах няколко дискусии в stackoverflow (а къде другаде), и изглежда намерих отговор. Нужно е да създам специален параметър в about:config (разбира се, заменяйки foo с conf):

network.protocol-handler.expose.foo = false

Създаваме, отваряме линка и… не тук-то беше. Браузерът, сякаш нищо не е станало, казва, че не познава нашето приложение.

Четох официалната документация за регистрацията на протокола от Mozilla, има вариант да се зададат асоциации в самия gnome desktop (заменяйки, разбира се, foo с 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

Регистрирам, отварям браузера… и отново се случи нещо странно.

Тук ми попада на очи редица от документацията:

Следващия път, когато кликнете на линка от протоколния тип foo, ще ви бъде зададено с коя приложението да го отворите.

— Семен Семенович
— Ааа

Не кликваме по линка, а просто уеб страницата променя window.location чрез javascript. Пиша прост html файл с линк към conf протокола, отварям в браузера, кликвам по линка — Yos! Отваря се прозорец с въпрос в кое приложение да отворим линка и там в списъка вече е нашето приложение Lync — ние го регистрирахме по всички възможни начини. В прозорецът има отметка „запомни избора и винаги отваряй линкове в нашето приложение“, отбелязваме, натискаме ок. И това е втората победа — прозорецът на конференцията се отваря. При това, вече откритите конференции работят не само когато кликнем на линка, а и при преминаване от нужната страница за присъединяване в конференцията.

После проверих, премахването на параметрите network.protocol-handler.expose.conf никак не повлия на работата на протокола в Firefox. Линковете продължаваха да работят.

Заключение

Качих всичките си разработки в репозитория на GitHub, линкове към всички ресурси ще има в края на статията.
Ще ми бъде интересно да получа обратна връзка от тези, които искат да се възползват от моите разработки. Веднага ще отбележа, че всичко е направено единствено за моята система Linux Mint, така че други дистрибуции или десктопи може да не работят в този вариант. Всъщност, почти съм уверен в това, защото патчнах само 1 функция в xdg-open, свързана само с моя DE. Ако искате да добавите поддръжка за други системи или десктопи, пишете ми пул-реквести в GitHub.

Изпълнението на целия проект отне 1 вечер.

Линкове:

• Регистрация на протокола в Mozilla
• D-bus(wikipedia)
• rfc3986 URI
• проект на Github

Източник: habr.com