Inicio de sesión automático nas conferencias de Lync en Linux

Ola Habr!

Para min, esta frase é semellante a ola mundo, xa que por fin cheguei á miña primeira publicación. Adiantei durante moito tempo este momento marabilloso, xa que non había nada que escribir, e tampouco quería chupar algo que xa fora chupado unha chea de veces. En xeral, para a miña primeira publicación quería algo orixinal, útil para os demais e que conteña algún tipo de desafío e resolución de problemas. E agora podo compartir isto. Agora imos falar de todo en orde.

Entrada

Todo comezou cando hai un tempo descarguei Linux Mint no meu ordenador de traballo. Moita xente probablemente sabe que Pidgin co complemento Sipe é un substituto completamente axeitado para Microsoft Lync (agora chamado Skype para empresas) para sistemas Linux. Debido ás especificidades do meu traballo, moitas veces teño que participar en conferencias SIP, e cando era un traballador de Windows, entrar nas conferencias era elemental: recibimos unha invitación por correo, facemos clic na ligazón de inicio de sesión e xa estamos listos para ir. .

Ao cambiar ao lado escuro de Linux, todo se complicou algo máis: por suposto, tamén podes iniciar sesión en conferencias en Pidgin, pero para iso cómpre seleccionar a opción de unirse á conferencia no menú das propiedades da túa conta SIP e na xanela que se abre, insira unha ligazón á conferencia ou introduza o nome do organizador e conf id. E despois dun tempo comecei a pensar: "É posible simplificar isto dalgún xeito?" Si, podes dicir, por que diaños necesitas isto? Prefiro sentarme en Windows e non deixarme caer.

Paso 1: Investigación

"Se tes algún capricho na cabeza, non podes eliminalo cunha estaca", dixo Nekrasov na súa obra "Who Lives Well in Rus'".

Entón, unha vez que o pensamento entrou na miña cabeza, despois dun tempo xurdiu a primeira idea de implementación. Todo parecía sinxelo: cómpre interceptar o acceso ás ligazóns meet.company.com/user/confid — instala un proceso de aplicación web local no teu coche en 127.0.0.1 e en /etc/hosts engade unha entrada estática para o dominio da empresa a través do cal entras na conferencia, apuntando a localhost. A continuación, este servidor web debe procesar a ligazón que chegou a el e, dalgún xeito, transferila dentro de Pidgin (deseguido direi que neste momento aínda non tiña idea de como darlle nada). A solución, por suposto, cheira a muletas, pero nós somos programadores, as muletas non nos asustan (merda).

Entón, por casualidade, abrín dalgún xeito a ligazón de invitación en Google Chrome (e normalmente sempre uso Mozilla Firefox). E para a miña sorpresa, a páxina web parecía completamente diferente: non había ningún formulario para ingresar os datos do usuario e inmediatamente despois de entrar na páxina houbo unha solicitude para abrir algo a través xdg-open. Só por diversión, fago clic en "si" e aparece unha mensaxe de erro: non se pode abrir a ligazón lync15:confjoin?url=https://meet.company.com/user/confid. Hmm. Que tipo de xdg-open é este e que necesita para que se abra este tipo de ligazóns? Unha lectura post mortem da documentación revelou que é un manejador de GUI que axuda a executar aplicacións asociadas con protocolos para o esquema uri ou con tipos de ficheiros específicos. As asociacións configúranse mediante mapeamento tipo MIME. Entón vemos que estamos a buscar unha aplicación coincidente para un esquema uri chamado linc15 e pásase a ligazón a xdg-open, que despois, en teoría, debería pasarllo a algunha aplicación que se encargue deste tipo de ligazóns. Que, por suposto, non temos no noso sistema. Se non, que fan no mundo de código aberto? É certo, escribirémolo nós.

Unha inmersión máis profunda no mundo de Linux e, sobre todo, no estudo de como funciona o shell gráfico (entorno de escritorio, DE), por certo, teño Xfce en Linux Mint, demostrou que as aplicacións e o tipo mímico asociado a ela adoitan escribirse directamente en ficheiros de atallo coa extensión .desktop. Ben, por que non, creo un sinxelo atallo de aplicación, que simplemente debería lanzar un script bash e mostrar o argumento que se lle pasou á consola, fornezo só o propio ficheiro de atallo:

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

Lanzo xdg-open dende a consola, pasando a mesma ligazón que ven do navegador e... mágoa. De novo di que non pode procesar a ligazón.

Como resultado, non actualicei o directorio de tipos MIME asociados coa miña aplicación. Isto faise cun comando sinxelo:

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

que simplemente edita o ficheiro ~/.config/mimeapps.list.

Intento número 2 coa chamada xdg-open e de novo fracaso. Nada, as dificultades non nos asustan, senón que só alimentan o noso interese. E armados con todo o poder de bash (é dicir, o rastrexo), mergullámonos de cabeza na depuración. É importante notar aquí que xdg-open é só un script de shell.

bash -x xdg-open $url

Analizando a saída despois de rastrexar, queda un pouco claro que o control se transfire exo-aberto. E este xa é un ficheiro binario e é máis difícil entender por que devolve un código de retorno sen éxito ao pasar unha ligazón a el nun argumento.

Despois de revisar os elementos internos de xdg-open, descubrín que analiza varios parámetros ambientais e pasa o control aínda máis a algunhas ferramentas para abrir ligazóns de ficheiros específicas dun DE en particular ou ten unha función de reserva. aberto_xenérico

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
}

Axiña inserirei aquí un pequeno truco coa análise do argumento pasado e se a nosa subcadea específica se atopa alí lync15:, entón transferimos inmediatamente o control á función aberto_xenérico.

Intenta o número 3 e cres que funcionou? Si, agora, claro. Pero a mensaxe de erro xa cambiou, isto xa é progreso - agora dicíame que non se atopaba o ficheiro e en forma de ficheiro escribiume a mesma ligazón pasou como argumento.

Esta vez resultou ser unha función is_file_url_or_path, que analiza a ligazón do ficheiro pasada á entrada: file:// ou a ruta do ficheiro ou outra cousa. E a comprobación non funcionou correctamente debido ao feito de que o noso prefixo (esquema URL) ten números, e a expresión regular só verifica o conxunto de caracteres composto por :alpha: puntos e guións. Despois de consultar o estándar rfc3986 para identificador de recurso uniforme Quedou claro que esta vez Microsoft non está a violar nada (aínda que eu tiña unha versión deste tipo). Só a clase de caracteres :alpha: contén só letras do alfabeto latino. Cambio rapidamente a verificación normal a alfanumérico. Feito, estás incrible, por fin todo comeza, o control despois de todas as comprobacións dáselle á nosa aplicación de scripts, a nosa ligazón móstrase na consola, todo está como debería ser. Despois disto, comezo a sospeitar que todos os problemas con exo-open tamén se deben á validación do formato da ligazón debido aos números do esquema. Para probar a hipótese, cambio o rexistro de tipo mime da aplicación por só un esquema linc e listo - todo funciona sen anular a función open_xfce. Pero isto non nos servirá de nada, porque a páxina web para entrar na conferencia crea unha ligazón con lync15.

Así, a primeira parte da viaxe xa está rematada. Sabemos como interceptar unha chamada de ligazón e, a continuación, debe ser procesada e transmitida dalgún xeito dentro de Pidgin. Para comprender como funciona internamente ao introducir datos a través dunha ligazón no menú "Únete a unha conferencia", clonei o repositorio Git do proxecto Sipe e prepareime para mergullarme de novo no código. Pero despois, afortunadamente, atraéronme os guións do catálogo contribución/dbus/:

  • sipe-join-conference-with-uri.pl
  • sipe-join-conference-con-organizador-e-id.pl
  • sipe-call-phone-number.pl
  • SipeHelper.pm

Resulta que o complemento Sipe está dispoñible para a interacción a través de dbus (bus de escritorio) e dentro dos scripts hai exemplos de unirse a unha conferencia a través dunha ligazón, xa sexa a través do nome e conf-id do organizador, ou ben pode iniciar unha chamada a través de sip . Isto é exactamente o que nos faltaba.

Paso 2. Implementación dun controlador de unión automática

Como hai exemplos preparados en Pearl, decidín só usalos sipe-join-conference-with-uri.pl e modificalo un pouco para que che guste. Podo escribir en Pearl, polo que non causou ningunha dificultade especial.

Despois de probar o script por separado, escribín a súa chamada no ficheiro lync.desktop. E foi unha vitoria! Ao entrar na páxina de unión á conferencia e permitir que xdg-open se execute, a ventá emerxente da conferencia de Pidgin abrirase automaticamente. Como me alegrei.
Animado polo éxito, decidín facer o mesmo co meu navegador principal, Mozilla Firefox. Cando inicias sesión a través do raposo, ábrese unha páxina para a autorización e na parte inferior hai un botón únase mediante Office Communicator. Ela foi a que me chamou a atención. Cando fai clic nel no navegador, vai ao enderezo:

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

ao que amablemente me di que non sabe como abrilo e, se cadra, non teño unha aplicación asociada para tal protocolo. Pois xa o pasamos.

Rexistro rapidamente a miña aplicación de script tamén para o esquema uri conf e... non pasa nada. O navegador segue queixándose de que non hai ningunha aplicación que manexa as miñas ligazóns. Neste caso, chamar a xdg-open desde a consola con parámetros funciona perfectamente.

"Establecer un manejador de protocolo personalizado en Firefox" - En liña con esta pregunta. Despois de pasar por varias discusións sobre stackoverflow (e onde estaríamos sen el), parece que se atopou a resposta. Debes crear un parámetro especial en sobre: ​​config (por suposto, substituíndo foo por conf):

network.protocol-handler.expose.foo = false

Creámolo, abrimos o enlace e... non hai tanta sorte. O navegador, coma se nada pasase, di que non coñece a nosa aplicación.

Estou lendo a documentación oficial sobre o rexistro dun protocolo de Mozilla, hai unha opción para rexistrar asociacións no propio escritorio gnome (substituíndo foo por conf, por suposto):

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

Rexístrome, abro o navegador... e de novo a barba.

Aquí me chama a atención unha liña da documentación:

A próxima vez que faga clic nunha ligazón de protocolo tipo foo, preguntaráselle con que aplicación queres abrila.

- Semyon Semenych
- Ahh

Non facemos clic na ligazón, pero a páxina web simplemente cambia a xanela.localización mediante javascript. Escribo un ficheiro html sinxelo cunha ligazón ao protocolo conf, ábroo no navegador, fai clic na ligazón - Yos! Ábrese unha xanela preguntando en que aplicación necesitamos abrir a nosa ligazón, e alí xa temos a nosa aplicación Lync na lista: rexistrámola honestamente de todas as formas posibles. Alí, na xanela hai unha caixa de verificación "lembra a elección e abra sempre as ligazóns na nosa aplicación", márcao, fai clic en Aceptar. E esta é a segunda vitoria: ábrese a xanela da conferencia. Ao mesmo tempo, abrir conferencias non só funciona cando fai clic nunha ligazón, senón tamén ao pasar da páxina de unión que necesitamos á conferencia.

Despois comprobei, eliminando parámetros network.protocol-handler.expose.conf non afectou de ningún xeito ao funcionamento do protocolo en Fox. As ligazóns seguiron funcionando.

Conclusión

Carguei todo o meu traballo ao repositorio de GitHub; as ligazóns a todos os recursos estarán ao final do artigo.
Estarei interesado en recibir comentarios dos que queiran utilizar o meu traballo. Debo notar inmediatamente que fixen todo o desenvolvemento só para o meu sistema Linux Mint, polo que algunhas outras distribucións ou escritorios poden non funcionar nesa versión. Ou mellor dito, estou case seguro diso, porque só parcheguei 1 función en xdg-open que só se relaciona co meu DE. Se queres engadir soporte para outros sistemas ou escritorios, escríbeme solicitudes de extracción en Github.

Todo o proxecto tardou 1 noite en completarse.

Referencias:

Fonte: www.habr.com

Engadir un comentario