Login automático em conferências do Lync no Linux

Oi, Habr!

Para mim, essa frase é parecida com olá mundo, já que finalmente cheguei à minha primeira publicação. Adiei por muito tempo esse momento maravilhoso, pois não tinha o que escrever, e também não queria chupar algo que já havia sido chupado um monte de vezes. Em geral, para minha primeira publicação queria algo original, útil para outras pessoas e que contivesse algum tipo de desafio e resolução de problemas. E agora posso compartilhar isso. Agora vamos conversar sobre tudo em ordem.

Entrada

Tudo começou quando, há algum tempo, baixei o Linux Mint no meu computador de trabalho. Muitas pessoas provavelmente sabem que o Pidgin com o plugin Sipe é um substituto totalmente adequado para o Microsoft Lync (agora chamado Skype for Business) para sistemas Linux. Devido às especificidades do meu trabalho, muitas vezes tenho que participar de conferências SIP, e quando eu trabalhava no Windows, entrar em conferências era elementar: recebemos um convite por correio, clicamos no link de login e estamos prontos para começar .

Ao mudar para o lado negro do Linux, tudo ficou um pouco mais complicado: claro, você também pode fazer login em conferências no Pidgin, mas para fazer isso você precisa selecionar a opção ingressar na conferência no menu nas propriedades da sua conta SIP e na janela que se abre, insira um link para a conferência ou digite o nome do organizador e o conf id. E depois de algum tempo comecei a pensar: “é possível simplificar isso de alguma forma?” Sim, você pode dizer, por que diabos você precisa disso? Prefiro sentar no Windows e não me surpreender.

Etapa 1: Pesquisa

“Se você tiver algum capricho na cabeça, não poderá derrubá-lo com uma estaca”, disse Nekrasov em sua obra “Quem Vive Bem na Rússia”.

Assim, assim que o pensamento entrou na minha cabeça, depois de algum tempo surgiu a primeira ideia de implementação. Tudo parecia simples - você precisa interceptar o acesso aos links meet.company.com/user/confid — instale um processo de aplicação web local em seu carro em 127.0.0.1 e em /etc/hosts adicione uma entrada estática para o domínio da empresa através do qual você entra na conferência, apontando para localhost. Em seguida, este servidor web deve processar o link que chegou até ele e de alguma forma transferi-lo para dentro do Pidgin (direi desde já que nesta fase ainda não tinha ideia de como fornecê-lo). A solução, claro, cheira a muletas, mas somos programadores, muletas não nos assustam (merda).

Então, por acaso, de alguma forma abri o link do convite no Google Chrome (e normalmente sempre uso o Mozilla Firefox). E para minha surpresa, a página da web parecia completamente diferente - não havia formulário para inserir os dados do usuário e imediatamente após entrar na página havia uma solicitação para abrir algo através xdg-open. Só por diversão, clico em “sim” e uma mensagem de erro aparece - o link lync15:confjoin?url=https://meet.company.com/user/confid não pode ser aberto. Hum. Que tipo de xdg-open é esse e o que é necessário para que esses links sejam abertos? Uma leitura post-mortem da documentação revelou que se trata de um manipulador GUI que ajuda a executar aplicativos associados com protocolos para o esquema uri ou com tipos de arquivo específicos. As associações são configuradas por meio de mapeamento de tipo MIME. Portanto, vemos que estamos executando uma busca por um aplicativo correspondente para um esquema uri chamado lync15 e o link é passado para o xdg-open, que então, em tese, deveria passá-lo para alguma aplicação responsável por esse tipo de link. O que, claro, não temos em nosso sistema. Se não, então o que eles fazem no mundo do código aberto? Isso mesmo, nós mesmos escreveremos.

Uma maior imersão no mundo Linux e principalmente no estudo de como funciona o shell gráfico (ambiente desktop, DE), aliás, tenho o Xfce no Linux Mint, mostrou que os aplicativos e o tipo MIME associado a ele geralmente são escritos diretamente em arquivos de atalho com a extensão .desktop. Bem, por que não, eu crio um atalho de aplicativo simples, que deve simplesmente iniciar um script bash e enviar o argumento passado a ele para o console, forneço apenas o próprio arquivo de atalho:

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

Eu lanço o xdg-open no console, passando o mesmo link que vem do navegador e... que chatice. Novamente diz que não pode processar o link.

Acontece que não atualizei o diretório de tipos MIME associados ao meu aplicativo. Isso é feito com um comando simples:

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

que simplesmente edita o arquivo ~/.config/mimeapps.list.

Tentativa número 2 com a chamada xdg-open - e novamente falha. Nada, as dificuldades não nos assustam, apenas alimentam o nosso interesse. E armados com todo o poder do bash (ou seja, rastreamento), mergulhamos de cabeça na depuração. É importante notar aqui que xdg-open é apenas um script de shell.

bash -x xdg-open $url

Analisando a saída após o rastreamento, fica um pouco claro que o controle é então transferido para exo-aberto. E este já é um arquivo binário e é mais difícil entender por que ele retorna um código de retorno malsucedido ao passar um link para ele em um argumento.

Depois de examinar o interior do xdg-open, descobri que ele analisa vários parâmetros ambientais e passa o controle para algumas ferramentas para abrir links de arquivos específicos para um DE específico ou tem uma função de fallback 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
}

Incorporarei rapidamente aqui um pequeno hack com análise do argumento passado e se nossa substring específica está localizada lá Lync15:, então transferimos imediatamente o controle para a função open_generic.

Tentativa número 3 e você acha que funcionou? Sim, agora, claro. Mas a mensagem de erro já mudou, isso já é um progresso - agora ele estava me dizendo que o arquivo não foi encontrado e em forma de arquivo ele me escreveu o mesmo link passado como argumento.

Desta vez acabou sendo uma função is_file_url_or_path, que analisa o link do arquivo passado para a entrada: file:// ou o caminho para o arquivo ou qualquer outra coisa. E a verificação não funcionou corretamente devido ao fato de nosso prefixo (esquema de URL) possuir números, e a expressão regular apenas verifica o conjunto de caracteres composto por :alpha: pontos e traços. Depois de consultar o padrão rfc3986 para Identificador de Recurso Uniforme Ficou claro que desta vez a Microsoft não está violando nada (embora eu tivesse essa versão). Apenas a classe de caracteres :alpha: contém apenas letras do alfabeto latino. Mudo rapidamente a verificação regular para alfanumérica. Pronto, você é incrível, tudo finalmente começa, o controle após todas as verificações é dado ao nosso aplicativo de script, nosso link é exibido no console, tudo está como deveria estar. Depois disso, começo a suspeitar que todos os problemas do exo-open também se devem à validação do formato do link devido aos números do esquema. Para testar a hipótese, altero o registro tipo MIME da aplicação para apenas um esquema Lync e pronto - tudo funciona sem substituir a função open_xfce. Mas isso não nos ajudará em nada, pois a página web de entrada na conferência cria um link com o lync15.

Assim, a primeira parte da jornada foi concluída. Sabemos como interceptar uma chamada de link e então ela precisa ser processada de alguma forma e passada dentro do Pidgin. Para entender como funciona internamente ao inserir dados por meio de um link no menu “participar de uma conferência”, clonei o repositório Git do projeto Sipe e me preparei para mergulhar novamente no código. Mas então, felizmente, fui atraído pelos roteiros do catálogo contribua/dbus/:

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

Acontece que o plugin Sipe está disponível para interação via dbus (desktop bus) e dentro dos scripts há exemplos de ingresso em uma conferência através de um link, seja através do nome do organizador e conf-id, ou você pode iniciar uma chamada via sip . Isso é exatamente o que estávamos perdendo.

Etapa 2. Implementando um manipulador de autojoin

Como existem exemplos prontos no Pearl, decidi usar apenas sipe-join-conference-with-uri.pl e modifique-o um pouco para se adequar a você. Posso escrever em Pearl, por isso não causou nenhuma dificuldade particular.

Depois de testar o script separadamente, escrevi sua chamada no arquivo Lync.desktop. E foi uma vitória! Ao entrar na página de ingresso na conferência e permitir a execução do xdg-open, a janela pop-up da conferência do Pidgin abriria automaticamente. Como me alegrei.
Encorajado pelo sucesso, decidi fazer o mesmo com meu navegador principal, o Mozilla Firefox. Ao fazer login pelo fox, uma página de autorização é aberta e na parte inferior há um botão junte-se usando o office comunicador. Foi ela quem me chamou a atenção. Ao clicar nele no navegador, ele vai para o endereço:

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

ao que ele gentilmente me diz que não sabe como abri-lo e, talvez, eu não tenha um aplicativo associado para tal protocolo. Bom, já passamos por isso.

Eu rapidamente registro meu aplicativo de script também para o esquema uri conf e... nada acontece. O navegador continua reclamando que não existe um aplicativo que lide com meus links. Neste caso, chamar xdg-open do console com parâmetros funciona perfeitamente.

“Definir manipulador de protocolo personalizado no Firefox” - entrei online com esta pergunta. Depois de passar por diversas discussões sobre stackoverflow (e onde estaríamos sem ele), parece que a resposta foi encontrada. Você precisa criar um parâmetro especial em about: config (claro substituindo foo por conf):

network.protocol-handler.expose.foo = false

Criamos, abrimos o link e... não tivemos essa sorte. O navegador, como se nada tivesse acontecido, diz que não conhece nossa aplicação.

Estou lendo a documentação oficial sobre registro de protocolo da Mozilla, existe uma opção para registrar associações no próprio desktop gnome (substituindo foo por conf, é claro):

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 cadastro, abro o navegador... e novamente a barba.

Aqui, uma linha da documentação chama minha atenção:

Na próxima vez que você clicar em um link do tipo de protocolo foo, você será questionado sobre qual aplicativo deseja abri-lo.

- Semyon Semenych
- Ahh

Não clicamos no link, mas a página da web simplesmente muda window.location via javascript. Eu escrevo um arquivo html simples com um link para o protocolo conf, abro no navegador, clico no link - Ei! Uma janela se abre perguntando em qual aplicativo precisamos abrir nosso link, e aí já temos nosso aplicativo Lync na lista - honestamente o registramos de todas as maneiras possíveis. Lá na janela existe um checkbox “lembrar da escolha e sempre abrir links em nosso aplicativo”, marque, clique em ok. E esta é a segunda vitória - a janela da conferência se abre. Ao mesmo tempo, a abertura de conferências funciona não apenas quando você clica em um link, mas também ao passar da página de adesão necessária para a conferência.

Então eu verifiquei, excluindo parâmetros rede.protocol-handler.expose.conf não afetou de forma alguma o funcionamento do protocolo na Fox. Os links continuaram funcionando.

Conclusão

Carreguei todo o meu trabalho no repositório GitHub; links para todos os recursos estarão no final do artigo.
Terei interesse em receber feedback de quem deseja utilizar meu trabalho. Devo observar imediatamente que fiz todo o desenvolvimento apenas para meu sistema Linux Mint, portanto, algumas outras distribuições ou desktops podem não funcionar nessa versão. Ou melhor, tenho quase certeza disso, porque corrigi apenas 1 função no xdg-open que se relaciona apenas ao meu DE. Se você deseja adicionar suporte para outros sistemas ou desktops, escreva-me pull requests no Github.

Todo o projeto levou 1 noite para ser concluído.

Links:

Fonte: habr.com

Adicionar um comentário