Хей Хабр!
За мен тази фраза е подобна на здравей свят, тъй като най-накрая стигнах до първата си публикация. Дълго време отлагах този прекрасен момент, тъй като нямаше за какво да пиша, а и не исках да смуча нещо, което вече беше смукано много пъти. Като цяло за първата си публикация исках нещо оригинално, полезно за другите и съдържащо някакво предизвикателство и решаване на проблеми. И сега мога да споделя това. Сега нека поговорим за всичко по ред.
Влизане
Всичко започна, когато преди време изтеглих Linux Mint на работния си компютър. Много хора вероятно знаят, че Pidgin с плъгина Sipe е напълно подходящ заместител на Microsoft Lync (сега наричан Skype за бизнеса) за Linux системи. Поради спецификата на работата ми често ми се налага да участвам в SIP конференции и когато работех в Windows, влизането в конференции беше елементарно: получаваме покана по пощата, кликваме върху връзката за вход и сме готови .
При преминаването към тъмната страна на Linux всичко стана малко по-сложно: разбира се, можете също да влизате в конференции в Pidgin, но за да направите това, трябва да изберете опцията за присъединяване към конференцията в менюто в свойствата на вашия SIP акаунт и в прозореца, който се отваря, поставете връзка към конференцията или въведете името на организатора и конф. И след известно време започнах да си мисля: „Възможно ли е по някакъв начин да опростя това?“ Да, може да кажете, защо, по дяволите, имате нужда от това? Предпочитам да седя на Windows и да не си шашкам.
Стъпка 1: Проучване
„Ако имаш каприз в главата си, не можеш да го избиеш с кол“, каза Некрасов в работата си „Кой живее добре в Русия“.
И така, след като ми хрумна мисълта, след известно време се появи първата идея за реализация. Всичко изглеждаше просто - трябва да прихванете достъпа до връзки — инсталирайте процес на локално уеб приложение на вашия автомобил на адрес 127.0.0.1 и в /etc/hosts добавете статичен запис за домейна на компанията, през който влизате в конференцията, сочещ към localhost. След това този уеб сървър трябва да обработи връзката, която е дошла до него, и по някакъв начин да я прехвърли вътре в Pidgin (веднага ще кажа, че на този етап все още нямах представа как изобщо да му я дам). Решението, разбира се, мирише на патерици, но ние сме програмисти, патериците не ни плашат (мамка му).
Тогава, случайно, някак си отворих връзката за покана в Google Chrome (и обикновено винаги използвам Mozilla Firefox). И за моя изненада уеб страницата изглеждаше съвсем различно - нямаше форма за въвеждане на потребителски данни и веднага след влизане в страницата имаше заявка за отваряне на нещо през XDG-отворен. Просто за забавление щраквам върху „да“ и се появява съобщение за грешка - връзката lync15:confjoin?url=https://meet.company.com/user/confid не може да бъде отворена. Хм. Що за xdg-open е това и какво му трябва, за да се отварят такива връзки? Следсмъртно четене на документацията разкри, че това е GUI манипулатор, който помага да се изпълняват свързани приложения или с протоколи за uri схемата, или със специфични типове файлове. Асоциациите се конфигурират чрез съпоставяне на тип mime. Така че виждаме, че изпълняваме търсене за съответстващо приложение за uri схема с име lync15 и връзката се предава на xdg-open, който след това, на теория, трябва да я предаде на някакво приложение, което отговаря за този тип връзка. Което, разбира се, нямаме в нашата система. Ако не, тогава какво правят в света с отворен код? Точно така, ще го напишем сами.
По-нататъшното потапяне в света на Linux и особено в изучаването на това как работи графичната обвивка (десктоп среда, DE), между другото, имам Xfce в Linux Mint, показа, че приложенията и типът mime, свързан с него, обикновено се пишат директно в файлове с преки пътища с разширение .desktop. Е, защо не, създавам прост пряк път на приложение, който трябва просто да стартира bash скрипт и да изведе подавания към него аргумент на конзолата, предоставям само самия файл с пряк път:
[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 типове с моето приложение. Това става с проста команда:
xdg-mime default lync.desktop x-scheme-handler/lync15
който просто редактира файла ~/.config/mimeapps.list.
Опит номер 2 с повикването xdg-open - и отново провал. Нищо, трудностите не ни плашат, а само подклаждат интереса ни. И въоръжени с цялата мощ на bash (т.е. проследяване), ние се потапяме с главата напред в отстраняването на грешки. Тук е важно да се отбележи, че xdg-open е просто шел скрипт.
bash -x xdg-open $url
Анализирайки изхода след проследяване, става малко ясно, че контролът след това се прехвърля към екзо-отворен. И това вече е двоичен файл и е по-трудно да се разбере защо връща неуспешен код за връщане при подаване на връзка към него в аргумент.
След като прегледах вътрешността на 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: съдържа само букви от латинската азбука. Бързо сменям обикновената проверка на буквено-цифрова. Готово, вие сте невероятни, всичко най-накрая започва, контролът след всички проверки се дава на нашето скриптово приложение, връзката ни се показва на конзолата, всичко е както трябва. След това започвам да подозирам, че всички проблеми с exo-open се дължат и на валидирането на формата на връзката поради числата в схемата. За да тествам хипотезата, променям регистрацията от тип mime на приложението само на схема рис и готово - всичко работи без да се отменя функцията open_xfce. Но това няма да ни помогне по никакъв начин, тъй като уеб страницата за влизане в конференцията създава връзка с lync15.
И така, първата част от пътуването е завършена. Ние знаем как да прихванем извикване на връзка и след това то трябва да бъде обработено по някакъв начин и предадено в Pidgin. За да разбера как работи вътрешно при въвеждане на данни чрез връзка в менюто „присъединяване към конференция“, клонирах Git хранилището на проекта Sipe и се приготвих да се потопя отново в кода. Но тогава, за щастие, бях привлечен от сценариите в каталога принос/dbus/:
- sipe-join-conference-with-uri.pl
- sipe-join-conference-with-organizer-and-id.pl
- sipe-call-phone-number.pl
- SipeHelper.pm
Оказва се, че плъгинът Sipe е достъпен за взаимодействие чрез dbus (настолна шина) и вътре в скриптовете има примери за присъединяване към конференция чрез връзка, или чрез името на организатора и conf-id, или можете да инициирате повикване чрез sip . Точно това ни липсваше.
Стъпка 2. Внедряване на манипулатор за автоматично присъединяване
Тъй като в Pearl има готови примери, реших просто да използвам sipe-join-conference-with-uri.pl и го модифицирайте малко според вашите нужди. Мога да пиша на Pearl, така че не предизвика особени затруднения.
След като тествах скрипта отделно, записах неговото извикване във файла lync.desktop. И това беше победа! Когато влезете в страницата за присъединяване към конференцията и позволите на xdg-open да работи, изскачащият прозорец на конференцията от Pidgin ще се отвори автоматично. Как се зарадвах.
Окуражен от успеха, реших да направя същото за основния си браузър Mozilla Firefox. При влизане през лисицата се отваря страница за авторизация и най-отдолу има бутон присъединете се с помощта на офис комуникатор. Тя беше тази, която привлече вниманието ми. Когато щракнете върху него в браузъра, той отива на адрес:
conf:sip:{user};gruu;opaque=app:conf:focus:id:{conf-id}%3Frequired-media=audio
на което той любезно ми казва, че не знае как да го отвори и може би нямам свързано приложение за такъв протокол. Е, вече сме минали през това.
Бързо регистрирам приложението си за скрипт и за uri схемата конф и... нищо не става. Браузърът все се оплаква, че няма приложение, което да обработва връзките ми. В този случай извикването на xdg-open от конзолата с параметри работи перфектно.
„Задаване на персонализиран манипулатор на протоколи във firefox“ - влязох онлайн с този въпрос. След като преминахме през няколко дискусии относно stackoverflow (и къде щяхме да бъдем без него), изглежда, че отговорът беше намерен. Трябва да създадете специален параметър в за: довереник (разбира се, замествайки foo с conf):
network.protocol-handler.expose.foo = false
Създаваме го, отваряме връзката и... няма такъв късмет. Браузърът, сякаш нищо не се е случило, казва, че не знае нашето приложение.
Чета официалната документация за регистриране на протокол от Mozilla, има опция за регистриране на асоциации в самия работен плот на gnome (заменяйки 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 протокола, отварям го в браузъра, щраквам върху връзката - Йос! Отваря се прозорец с въпрос в кое приложение трябва да отворим връзката си и там вече имаме нашето приложение Lync в списъка - честно го регистрирахме по всички възможни начини. Там в прозореца има квадратче за отметка „запомнете избора и винаги отваряйте връзки в нашето приложение“, маркирайте го, щракнете върху OK. И това е втората победа - прозорецът на конференцията се отваря. В същото време отварянето на конференции работи не само когато щракнете върху връзка, но и когато се преместите от страницата за присъединяване, от която се нуждаем, към конференцията.
След това проверих, изтривайки параметри network.protocol-handler.expose.conf по никакъв начин не повлия на работата на протокола във Fox. Връзките продължиха да работят.
Заключение
Качих цялата си работа в хранилището на GitHub; връзките към всички ресурси ще бъдат в края на статията.
Ще ми е интересно да получа обратна връзка от тези, които искат да използват работата ми. Веднага трябва да отбележа, че направих цялата разработка само за моята система Linux Mint, така че някои други дистрибуции или настолни компютри може да не работят в тази версия. Или по-скоро дори съм почти сигурен в това, защото закърпих само 1 функция в xdg-open, която се отнася само до моя DE. Ако искате да добавите поддръжка за други системи или настолни компютри, пишете ми заявки за изтегляне в Github.
Завършването на целия проект отне 1 вечер.
за справка:
Източник: www.habr.com