Ciao, Habr!
Per me, questa frase è simile a hello world, perché finalmente sono arrivato alla mia prima pubblicazione. Ho rimandato a lungo questo momento speciale, poiché non avevo nulla di interessante da scrivere e non volevo ripetere ciò che era già stato ampiamente trattato. In effetti, per la mia prima pubblicazione, desideravo qualcosa di originale, utile per gli altri e che includesse una certa sfida e una soluzione a problemi. E ora posso finalmente condividerlo. Ora, andiamo con ordine.
Introduzione
Tutto è iniziato quando, qualche tempo fa, ho installato Linux Mint sul mio computer di lavoro. Molti sapranno che Pidgin con il plugin Sipe è una valida alternativa a Microsoft Lync (ora chiamato Skype for Business) per i sistemi Linux. A causa della mia attività, mi capita spesso di partecipare a conferenze sip, e quando usavo Windows, entrare in conferenze era un gioco da ragazzi: ricevevo un invito via email, cliccavo sul link per accedere e voilà, eravamo dentro.
Passando al lato oscuro di Linux, tutto è diventato un po' più complicato: partecipare alle conferenze in Pidgin è possibile, ma per farlo è necessario selezionare l'opzione di partecipazione alla conferenza nelle proprietà del proprio account sip e inserire nel pop-up il link alla conferenza o il nome dell'organizzatore insieme all'ID della conferenza. E dopo un po' ho iniziato a riflettere: 'non si potrebbe semplificare questo processo?'. Aha, direte voi, perché ti serve, avresti potuto rimanere su Windows senza stress.
Passo 1. Ricerca
«Se una bizzarria si infila in testa, non la scrollerai mai via», così diceva Nekrasov nella sua opera «Chi vive bene in Russia».
Quindi, una volta che il pensiero ha trovato spazio, è emersa anche la prima idea per la sua realizzazione. Sembrava tutto semplice: bisognava intercettare le chiamate ai link. — impostare un processo web locale dell'applicazione su 127.0.0.1 e aggiungere una registrazione statica per il dominio dell'azienda nel /etc/hosts, che viene utilizzato per accedere alle conferenze, puntando a localhost. Successivamente, questo server web deve elaborare il link ricevuto e in qualche modo trasmetterlo a Pidgin (devo dire che in questa fase non avevo ancora idea di come darglielo). Certo, la soluzione puzza di ripiego, ma noi siamo programmatori, i ripieghi non ci spaventano (scherzo).
Poi, per caso, ho aperto un link di invito in Google Chrome (di solito utilizzo sempre Mozilla Firefox). E con mia sorpresa, la pagina web sembrava completamente diversa: non c'era il modulo per l'inserimento dei dati utente e subito dopo l'accesso alla pagina compare una richiesta per aprire qualcosa tramite xdg-open. Per curiosità, clicco su "sì" e compare un messaggio di errore: il link lync15:confjoin?url=https://meet.company.com/user/confid non può essere aperto. Hmm. Cos'è xdg-open e di cosa ha bisogno per aprire questi link? Un'attenta lettura della documentazione ha rivelato che si tratta di un gestore della shell grafica, che aiuta ad avviare applicazioni associate sia a protocolli per schema URI che a tipi di file specifici. Le associazioni vengono configurate attraverso la corrispondenza dei mime-type. Dunque, vediamo che stiamo avviando la ricerca di un'applicazione associata per lo schema URI chiamato lync15 e il link viene passato a xdg-open, che dovrebbe a sua volta passarla a un'applicazione incaricata di gestire questo tipo di link. Ovviamente, noi non abbiamo tale applicazione nel sistema. E se non ce l'abbiamo, come si comportano nel mondo dell'open source? Esatto, lo scriveremo noi stessi.
Un'immersione più profonda nel mondo di Linux e, in particolare, nello studio di come funziona l'ambiente grafico (desktop environment, DE), nel mio caso Xfce in Linux Mint, ha rivelato che le applicazioni e il relativo mime-type sono generalmente specificati direttamente nei file di collegamento con estensione .desktop. Quindi, perché non farlo? Creerò un semplice collegamento a un'applicazione che deve semplicemente avviare uno script bash e visualizzare l'input ricevuto sulla console; ecco solo il file di collegamento:
[Desktop Entry]
Name=Lync
Exec=/usr/local/bin/lync.sh %u
Type=Application
Terminal=false
Categories=Network;InstantMessaging;
MimeType=x-scheme-handler/lync15;
Avvio xdg-open dalla console con lo stesso link utilizzato dal browser e… purtroppo. Ripete che non può elaborare il link.
Come si è scoperto, non ho aggiornato il catalogo dei mime-type associati alla mia applicazione. Questo si fa con un semplice comando:
xdg-mime default lync.desktop x-scheme-handler/lync15
che modifica semplicemente il file ~/.config/mimeapps.list.
Secondo tentativo con xdg-open — e ancora un fallimento. Niente paura, le difficoltà non ci spaventano, anzi, stimolano la curiosità. Armati di tutta la potenza di bash (cioè di tracciamento), ci immergiamo completamente nel debug. È importante notare che xdg-open è semplicemente uno script shell.
bash -x xdg-open $url
Analizzando l'output dopo il tracciamento, inizia a diventare un po' chiaro che il controllo passa a exo-open. Questo è già un file binario, e capire perché ritorna un codice di errore quando gli viene passato un link come argomento è più complicato.
Esaminando il funzionamento interno di xdg-open, ho scoperto che analizza vari parametri ambientali e passa il controllo a strumenti specifici per aprire file/link a seconda dell'ambiente desktop, oppure ha un fallback in forma della funzione 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
}
Sto rapidamente implementando qui un piccolo hack che analizza l'argomento passato e se contiene la nostra specifica sottostringa lync15:, allora passiamo immediatamente il controllo alla funzione open_generic.
Tentativo numero 3 e pensate che funzioni? Ah, certo, come no. Ma il messaggio di errore è già cambiato, questo è un progresso: ora mi ha detto che il file non è stato trovato e come file mi ha restituito proprio quel link, passato come argomento.
Questa volta si trattava della funzione is_file_url_or_path, che analizza il link del file file:// o il percorso di un file o altro. Il controllo non funzionava correttamente a causa del fatto che il nostro prefisso (url scheme) contiene numeri, mentre l'espressione regolare verifica solo un insieme di caratteri composto da :alpha:, punti e trattini. Dopo una consultazione con lo standard rfc3986 per uniform resource identifier è diventato chiaro che questa volta Microsoft non sta violando nulla (anche se avevo una tale versione). Semplicemente, la classe di caratteri :alpha: contiene solo lettere dell'alfabeto latino. Cambio rapidamente il controllo della regex in alphanumeric. Fatto, siete meravigliosi, tutto finalmente si avvia, il controllo passa al nostro script-applicazione, il nostro link viene stampato sulla console, tutto come dovrebbe essere. Dopo di ciò inizio a sospettare che tutti i problemi con exo-open derivi anche dalla validazione del formato del link a causa dei numeri nello schema. Per verificare l'ipotesi modifico la registrazione del mime-type dell'applicazione su semplicemente lo schema lync e voilà — tutto funziona senza ridefinire la funzione open_xfce. Ma non ci aiuterà in alcun modo, perché la pagina web per accedere alla conferenza crea precisamente un link con lync15.
Quindi, la prima parte del percorso è completata. Siamo in grado di intercettare la richiesta del link e ora dobbiamo in qualche modo elaborarla e passarla all'interno di Pidgin. Per capire come funziona quando si immettono dati tramite il link nel menu "partecipa a una conferenza", ho clonato il repository git del progetto Sipe e mi sono preparato per un'altra immersione nel codice. Ma, per fortuna, sono stato attratto dagli script nella cartella contrib/dbus/:
- sipe-join-conference-with-uri.pl
- sipe-join-conference-with-organizer-and-id.pl
- sipe-call-phone-number.pl
- SipeHelper.pm
Si scopre che il plugin Sipe è accessibile per l'interazione tramite dbus (desktop bus) e all'interno degli script ci sono esempi di partecipazione a conferenze tramite link, o tramite il nome dell'organizzatore e conf-id, oppure è possibile avviare una chiamata tramite sip. Questo è proprio ciò che ci mancava.
Passo 2. Implementazione del gestore per l'auto-join
Poiché ci sono esempi pronti in perl, ho deciso di usarli semplicemente sipe-join-conference-with-uri.pl e modificarli un po' per il mio utilizzo. So scrivere in perl, quindi non ho avuto particolari difficoltà.
Dopo aver testato lo script separatamente, ho inserito la sua chiamata nel file lync.desktop. E questa è stata una vittoria! Quando accedevo alla pagina di join della conferenza e autorizzavo l'apertura di xdg-open, la finestra pop-up della conferenza da Pidgin si apriva automaticamente. Che gioia!
Ispirato dal successo, ho deciso di fare lo stesso anche per il mio browser principale Mozilla Firefox. Quando accedo tramite il 'riccio', si apre la pagina di autorizzazione e in fondo c'è un pulsante join using office communicator. Questo ha catturato la mia attenzione. Cliccando su di esso, il browser reindirizza all'indirizzo:
conf:sip:{user};gruu;opaque=app:conf:focus:id:{conf-id}required-media=audio
il quale mi comunica gentilmente che non sa come aprirlo e, probabilmente, non ho un'applicazione associata per questo protocollo. Beh, questo lo abbiamo già affrontato.
Registro rapidamente la mia applicazione-script anche per lo schema uri conf e… non succede nulla. Il browser continua a lamentarsi che non c'è un'applicazione che gestisca i miei link. Tuttavia, la chiamata dalla console xdg-open con i parametri funziona alla grande.
«Imposta un gestore di protocollo personalizzato in firefox» — ho cercato questo problema su Internet. Dopo aver esplorato diverse discussioni su stackoverflow (come si può fare altrimenti), sembrava che avessi trovato una risposta. È necessario creare un parametro speciale in about:config (ovviamente sostituendo foo con conf):
network.protocol-handler.expose.foo = false
Creiamo, apriamo il link e… non è andata. Il browser dice tranquillamente che non conosce la nostra applicazione.
Leggo la documentazione ufficiale sulla registrazione dei protocolli di Mozilla, c'è un modo per scrivere le associazioni direttamente nel desktop gnome (sostituendo naturalmente foo con 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
Registrando, apro il browser… e di nuovo è un disastro.
Qui mi capita sotto gli occhi una riga della documentazione:
La prossima volta che clicchi su un link di tipo protocollo foo ti verrà chiesto quale applicazione usare per aprirlo.
— Semën Semënyč
— Aaaa
Non clicchiamo sul link, ma è la pagina web a cambiare window.location tramite JavaScript. Scrivo un semplice file HTML con un collegamento al protocollo di conferenza, lo apro nel browser, clicco sul link — Yos! Si apre una finestra con la domanda in quale applicazione vogliamo aprire il nostro link, e nella lista c'è già la nostra applicazione Lync — l'abbiamo registrata in tutti i modi possibili. Nella finestra c'è anche l'opzione 'ricorda la scelta e apri sempre i link nella nostra applicazione', la selezioniamo e clicchiamo su ok. E questa è la seconda vittoria: la finestra della conferenza si apre. Inoltre, l'apertura delle conferenze funziona, non solo cliccando sul link, ma anche passando dalla pagina di accesso alla conferenza necessaria.
Poi ho controllato, la rimozione dei parametri network.protocol-handler.expose.conf non ha influito sul funzionamento del protocollo in Firefox. I link continuavano a funzionare.
Conclusione
Ho caricato tutto il mio lavoro nel repository su GitHub, i link a tutte le risorse saranno alla fine dell'articolo.
Mi interesserebbe ricevere feedback da chi desidera utilizzare il mio lavoro. È importante notare che ho sviluppato tutto esclusivamente per il mio sistema Linux Mint, quindi potrebbero non funzionare su altre distribuzioni o desktop. Anzi, sono quasi certo di questo, poiché ho patchato solo 1 funzione in xdg-open, relativa esclusivamente al mio DE. Se desiderate aggiungere supporto per altri sistemi o desktop, sentitevi liberi di inviarmi delle pull request su GitHub.
L'implementazione dell'intero progetto ha richiesto una sola sera.
Link:
Fonte: habr.com
