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

¡Hola, Habr!

Para mí esta frase es como hola mundo, ya que finalmente llegué a mi primera publicación. Pospuse este maravilloso momento por mucho tiempo, ya que no había nada que escribir, y tampoco quería chupar algo que ya había sido chupado muchas veces. En general, para mi primera publicación quería algo original, útil para los demás y que contuviera algún tipo de desafío y resolución de problemas. Y ahora puedo compartir esto. Ahora hablemos de todo en orden.

Entrada

Todo empezó cuando hace un tiempo descargué Linux Mint en la computadora de mi trabajo. Probablemente mucha gente sepa que Pidgin con el complemento Sipe es un sustituto completamente adecuado de Microsoft Lync (ahora llamado Skype empresarial) para sistemas Linux. Debido a las características específicas de mi trabajo, a menudo tengo que participar en conferencias SIP, y cuando era un trabajador de Windows, ingresar a las conferencias era elemental: recibimos una invitación por correo, hacemos clic en el enlace de inicio de sesión y estamos listos para comenzar. .

Al pasar al lado oscuro de Linux, todo se volvió un poco más complicado: por supuesto, también puedes iniciar sesión en conferencias en Pidgin, pero para ello debes seleccionar la opción unirse a la conferencia en el menú de las propiedades de tu cuenta SIP y en la ventana que se abre, inserte un enlace a la conferencia o ingrese el nombre del organizador y su identificación. Y después de un tiempo comencé a pensar: "¿es posible simplificar esto de alguna manera?" Sí, podrías decir, ¿por qué diablos necesitas esto? Prefiero sentarme en Windows y no volverme loco.

Paso 1: Investigación

"Si se te ocurre algún capricho en la cabeza, no podrás eliminarlo con una estaca", dijo Nekrasov en su obra "Quién vive bien en Rusia".

Entonces, una vez que se me ocurrió la idea, después de un tiempo surgió la primera idea para implementarla. Todo parecía simple: es necesario interceptar el acceso a los enlaces. meet.company.com/user/confid — instale un proceso de aplicación web local en su automóvil en 127.0.0.1 y en /etc/hosts agregue una entrada estática para el dominio de la empresa a través del cual ingresa a la conferencia, apuntando a localhost. A continuación, este servidor web debe procesar el enlace que le llegó y de alguna manera transferirlo dentro de Pidgin (diré de inmediato que en esta etapa todavía no tenía idea de cómo entregárselo). La solución, por supuesto, huele a muletas, pero somos programadores, las muletas no nos asustan (mierda).

Luego, por casualidad, de alguna manera abrí el enlace de invitación en Google Chrome (y normalmente siempre uso Mozilla Firefox). Y para mi sorpresa, la página web se veía completamente diferente: no había ningún formulario para ingresar datos de usuario e inmediatamente después de ingresar a la página había una solicitud para abrir algo a través de xdg-open. Solo por diversión, hago clic en "sí" y aparece un mensaje de error: el enlace lync15:confjoin?url=https://meet.company.com/user/confid no se puede abrir. Mmm. ¿Qué tipo de xdg-open es este y qué se necesita para que se abran dichos enlaces? Una lectura post mortem de la documentación reveló que se trata de un controlador GUI que ayuda a ejecutar aplicaciones asociadas, ya sea con protocolos para el esquema uri o con tipos de archivos específicos. Las asociaciones se configuran mediante mapeo tipo mime. Entonces vemos que estamos ejecutando una búsqueda de una aplicación coincidente para un esquema de URI llamado lync15 y el enlace se pasa a xdg-open, que luego, en teoría, debería pasarlo a alguna aplicación que sea responsable de este tipo de enlace. Lo cual, por supuesto, no tenemos en nuestro sistema. Si no, ¿qué hacen en el mundo del código abierto? Así es, lo escribiremos nosotros mismos.

Una mayor inmersión en el mundo de Linux y especialmente en el estudio de cómo funciona el shell gráfico (entorno de escritorio, DE), por cierto, tengo Xfce en Linux Mint, demostró que las aplicaciones y el tipo mime asociado a él generalmente se escriben directamente en archivos de acceso directo con la extensión .desktop. Bueno, ¿por qué no? Creo un acceso directo a una aplicación simple, que simplemente debería iniciar un script bash y enviar el argumento que se le pasó a la consola; solo proporciono el archivo de acceso directo:

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

Ejecuto xdg-open desde la consola, pasando el mismo enlace que viene desde el navegador y... que fastidio. Nuevamente dice que no puede procesar el enlace.

Resulta que no actualicé el directorio de tipos mime asociados con mi aplicación. Esto se hace con un simple comando:

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

que simplemente edita el archivo ~/.config/mimeapps.list.

Intento número 2 con la llamada xdg-open y nuevamente fracaso. Nada, las dificultades no nos asustan, sólo alimentan nuestro interés. Y armados con todo el poder de bash (es decir, rastreo), nos sumergimos de cabeza en la depuración. Es importante señalar aquí que xdg-open es sólo un script de shell.

bash -x xdg-open $url

Al analizar el resultado después del seguimiento, queda un poco claro que el control luego se transfiere a exo-abierto. Y este ya es un archivo binario y es más difícil entender por qué devuelve un código de retorno fallido cuando se le pasa un enlace en un argumento.

Después de examinar las partes internas de xdg-open, descubrí que analiza varios parámetros ambientales y pasa el control a algunas herramientas para abrir enlaces de archivos específicos para un DE en particular, o tiene una función alternativa. abierto_generico

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
}

Rápidamente insertaré aquí un pequeño truco con un análisis del argumento pasado y si nuestra subcadena específica se encuentra allí. lync15:, luego transferimos inmediatamente el control a la función abierto_generico.

Intento número 3 y ¿crees que funcionó? Sí, ahora, por supuesto. Pero el mensaje de error ya cambió, esto ya es progreso - ahora me decía que no se encontró el archivo y en forma de archivo me escribió el mismo enlace pasado como argumento.

Esta vez resultó ser una función. es_url_archivo_o_ruta, que analiza el enlace del archivo pasado a la entrada: file:// o la ruta al archivo o algo más. Y la verificación no funcionó correctamente debido al hecho de que nuestro prefijo (esquema de URL) tiene números y la expresión regular solo verifica el conjunto de caracteres que consta de :alfa: puntos y guiones. Después de consultar el estándar rfc3986 para identificador uniforme de recursos Quedó claro que esta vez Microsoft no está violando nada (aunque yo tenía esa versión). Sólo la clase de caracteres :alpha: contiene sólo letras del alfabeto latino. Rápidamente cambio el cheque regular a alfanumérico. Listo, eres increíble, finalmente todo comienza, el control después de todas las comprobaciones se le da a nuestra aplicación de script, nuestro enlace se muestra en la consola, todo es como debería ser. Después de esto, empiezo a sospechar que todos los problemas con exo-open también se deben a la validación del formato del enlace debido a los números en el esquema. Para probar la hipótesis, cambio el registro tipo mime de la aplicación a solo un esquema. Lync y listo, todo funciona sin anular la función open_xfce. Pero esto no nos ayudará de ninguna manera, porque la página web para ingresar a la conferencia crea un enlace con lync15.

Así, la primera parte del viaje ha sido completada. Sabemos cómo interceptar una llamada de enlace y luego es necesario procesarla de alguna manera y pasarla dentro de Pidgin. Para comprender cómo funciona internamente al ingresar datos a través de un enlace en el menú "unirse a una conferencia", cloné el repositorio Git del proyecto Sipe y me preparé para sumergirme en el código nuevamente. Pero luego, afortunadamente, me atrajeron los guiones del catálogo. contribuir/dbus/:

  • sipe-unirse-a-la-conferencia-con-uri.pl
  • sipe-unirse-a-la-conferencia-con-el-organizador-y-id.pl
  • sipe-llamar-número-de-teléfono.pl
  • SipeHelper.pm

Resulta que el complemento Sipe está disponible para interactuar a través de dbus (bus de escritorio) y dentro de los scripts hay ejemplos de cómo unirse a una conferencia a través de un enlace, ya sea a través del nombre del organizador y el confi-id, o puede iniciar una llamada a través de sip. . Esto es exactamente lo que nos faltaba.

Paso 2. Implementar un controlador de unión automática

Como hay ejemplos ya preparados en Pearl, decidí usar simplemente sipe-unirse-a-la-conferencia-con-uri.pl y modifícalo un poco para que se adapte a ti. Puedo escribir en Pearl, así que no me causó ninguna dificultad particular.

Después de probar el script por separado, escribí su llamada en el archivo. lync.desktop. ¡Y fue una victoria! Al ingresar a la página para unirse a la conferencia y permitir que se ejecute xdg-open, la ventana emergente de la conferencia de Pidgin se abriría automáticamente. Cómo me alegré.
Animado por el éxito, decidí hacer lo mismo con mi navegador principal, Mozilla Firefox. Cuando inicia sesión a través de Fox, se abre una página de autorización y en la parte inferior hay un botón unirse usando el comunicador de oficina. Ella fue quien me llamó la atención. Al hacer clic en él en el navegador, se dirige a la dirección:

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

a lo que amablemente me dice que no sabe cómo abrirlo y, tal vez, no tengo una aplicación asociada a dicho protocolo. Bueno, ya hemos pasado por esto.

Registro rápidamente mi aplicación de script también para el esquema uri conf y... no pasa nada. El navegador sigue quejándose de que no hay ninguna aplicación que maneje mis enlaces. En este caso, llamar a xdg-open desde la consola con parámetros funciona perfectamente.

"Establecer un controlador de protocolo personalizado en Firefox": me conecté con esta pregunta. Después de pasar por varias discusiones sobre stackoverflow (y dónde estaríamos sin él), parece que se encontró la respuesta. Necesita crear un parámetro especial en about: config (por supuesto reemplazando foo con conf):

network.protocol-handler.expose.foo = false

Lo creamos, abrimos el enlace y... no hay tanta suerte. El navegador, como si nada, dice que no conoce nuestra aplicación.

Estoy leyendo la documentación oficial sobre cómo registrar un protocolo de Mozilla, hay una opción para registrar asociaciones en el escritorio gnome (reemplazando foo con conf, por supuesto):

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

Me registro, abro el navegador... y de nuevo la barba.

Aquí me llama la atención una línea de la documentación:

La próxima vez que haga clic en un enlace de tipo protocolo foo se le preguntará con qué aplicación abrirlo.

- Semión Semenych
- Ah

No hacemos clic en el enlace, sino que la página web simplemente cambia la ubicación de la ventana a través de javascript. Escribo un archivo html simple con un enlace al protocolo conf, lo abro en el navegador, hago clic en el enlace - ¡Sí! Se abre una ventana que pregunta en qué aplicación necesitamos abrir nuestro enlace, y allí ya tenemos nuestra aplicación Lync en la lista; honestamente, la registramos de todas las formas posibles. Allí, en la ventana hay una casilla de verificación "recordar la elección y abrir siempre enlaces en nuestra aplicación", márquela y haga clic en Aceptar. Y esta es la segunda victoria: se abre la ventana de la conferencia. Al mismo tiempo, abrir conferencias funciona no solo cuando hace clic en un enlace, sino también cuando pasa de la página para unirse que necesitamos a la conferencia.

Luego verifiqué, eliminando parámetros. network.protocol-handler.expose.conf no afectó de ninguna manera el funcionamiento del protocolo en Fox. Los enlaces continuaron funcionando.

Conclusión

He subido todo mi trabajo al repositorio de GitHub; los enlaces a todos los recursos estarán al final del artículo.
Me interesará recibir comentarios de aquellos que quieran utilizar mi trabajo. Debo señalar de inmediato que hice todo el desarrollo solo para mi sistema Linux Mint, por lo que es posible que otras distribuciones o escritorios no funcionen en esa versión. O más bien, estoy casi seguro de esto, porque parcheé solo 1 función en xdg-open que se relaciona solo con mi DE. Si desea agregar soporte para otros sistemas o computadoras de escritorio, escríbame solicitudes de extracción en Github.

Todo el proyecto tardó 1 noche en completarse.

Enlaces:

Fuente: habr.com

Añadir un comentario