Ehi Habr!
Per me, questa frase è simile a ciao mondo, dal momento che sono finalmente arrivato alla mia prima pubblicazione. Ho rimandato a lungo questo momento meraviglioso, perché non c'era niente di cui scrivere, e inoltre non volevo succhiare qualcosa che era già stato succhiato un sacco di volte. In generale, per la mia prima pubblicazione volevo qualcosa di originale, utile agli altri e che contenesse una sorta di sfida e di risoluzione dei problemi. E ora posso condividerlo. Ora parliamo di tutto in ordine.
Iscrizione
Tutto è iniziato quando qualche tempo fa ho scaricato Linux Mint sul mio computer di lavoro. Molte persone probabilmente sanno che Pidgin con il plugin Sipe è un sostituto perfettamente adatto a Microsoft Lync (ora chiamato Skype for business) per i sistemi Linux. A causa delle specificità del mio lavoro, devo spesso partecipare a conferenze SIP e quando ero un Windows Worker, partecipare alle conferenze era elementare: riceviamo un invito via mail, clicchiamo sul collegamento di accesso e siamo pronti a partire .
Passando al lato oscuro di Linux, tutto è diventato un po' più complicato: ovviamente puoi anche accedere alle conferenze in Pidgin, ma per farlo devi selezionare l'opzione partecipa alla conferenza nel menu nelle proprietà del tuo account SIP e nella finestra che si apre inserisci il link al convegno oppure inserisci il nome dell'organizzatore e il conf id. E dopo un po' ho cominciato a pensare: "è possibile semplificarlo in qualche modo?" Sì, potresti dire, perché diavolo ne hai bisogno? Preferirei sedermi su Windows e non lasciarmi a bocca aperta.
Passaggio 1: ricerca
"Se ti viene in mente qualche capriccio, non puoi metterlo fuori gioco con un paletto", ha detto Nekrasov nella sua opera "Chi vive bene in Rus'".
Quindi, una volta che l'idea mi è venuta in mente, dopo un po' è nata la prima idea per l'implementazione. Tutto sembrava semplice: devi intercettare l'accesso ai collegamenti — installa un processo di applicazione web locale sulla tua auto su 127.0.0.1 e in /etc/hosts aggiungi una voce statica per il dominio aziendale attraverso il quale accedi alla conferenza, puntando a localhost. Successivamente, questo server web deve elaborare il collegamento che gli è arrivato e in qualche modo trasferirlo all'interno di Pidgin (dirò subito che in questa fase non avevo ancora idea di come darglielo). La soluzione, ovviamente, puzza di stampelle, ma noi siamo programmatori, le stampelle non ci spaventano (merda).
Poi, per caso, in qualche modo ho aperto il link di invito in Google Chrome (e di solito utilizzo sempre Mozilla Firefox). E con mia sorpresa, la pagina web sembrava completamente diversa: non c'era alcun modulo per l'inserimento dei dati dell'utente e subito dopo l'accesso alla pagina c'era una richiesta di aprire qualcosa tramite xdg-open. Solo per divertimento, faccio clic su "sì" e viene visualizzato un messaggio di errore: il collegamento lync15:confjoin?url=https://meet.company.com/user/confid non può essere aperto. Hmm. Che tipo di xdg-open è questo e di cosa ha bisogno per aprire tali collegamenti? Una lettura post mortem della documentazione ha rivelato che si tratta di un gestore GUI che aiuta a eseguire le applicazioni associate con protocolli per lo schema URI o con tipi di file specifici. Le associazioni vengono configurate tramite la mappatura di tipo MIME. Vediamo quindi che stiamo eseguendo una ricerca per un'applicazione corrispondente per uno schema URI denominato lync15 e il collegamento viene passato a xdg-open, che poi, in teoria, dovrebbe passarlo a qualche applicazione responsabile di questo tipo di collegamento. Che, ovviamente, non abbiamo nel nostro sistema. In caso contrario, cosa fanno nel mondo open source? Esatto, lo scriveremo noi stessi.
Un'ulteriore immersione nel mondo di Linux e soprattutto nello studio di come funziona la shell grafica (ambiente desktop, DE), tra l'altro, ho Xfce in Linux Mint, ha dimostrato che le applicazioni e il tipo MIME ad essa associato sono solitamente scritti direttamente in file di collegamento con estensione .desktop. Bene, perché no, creo un semplice collegamento all'applicazione, che dovrebbe semplicemente avviare uno script bash e inviare alla console l'argomento passato, fornisco solo il file di collegamento stesso:
[Desktop Entry]
Name=Lync
Exec=/usr/local/bin/lync.sh %u
Type=Application
Terminal=false
Categories=Network;InstantMessaging;
MimeType=x-scheme-handler/lync15;
Lancio xdg-open dalla console, passando lo stesso collegamento che arriva dal browser e... peccato. Ancora una volta dice che non è possibile elaborare il collegamento.
A quanto pare, non ho aggiornato la directory dei tipi MIME associati alla mia applicazione. Questo viene fatto con un semplice comando:
xdg-mime default lync.desktop x-scheme-handler/lync15
che modifica semplicemente il file ~/.config/mimeapps.list.
Tentativo numero 2 con la chiamata xdg-open - e ancora fallimento. Niente, le difficoltà non ci spaventano, ma alimentano solo il nostro interesse. E armati di tutta la potenza di bash (ovvero del tracciamento), ci tuffiamo a capofitto nel debug. È importante notare qui che xdg-open è solo uno script di shell.
bash -x xdg-open $url
Analizzando l'output dopo il tracciamento diventa un po' chiaro a chi verrà poi trasferito il controllo exo-aperta. E questo è già un file binario ed è più difficile capire perché restituisce un codice di ritorno non riuscito quando si passa un collegamento ad esso in un argomento.
Dopo aver esaminato le parti interne di xdg-open, ho scoperto che analizza vari parametri ambientali e passa ulteriormente il controllo ad alcuni strumenti per l'apertura di collegamenti di file specifici per un particolare DE, oppure ha una funzione di 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
}
Incorporerò qui rapidamente un piccolo hack con l'analisi dell'argomento passato e se la nostra sottostringa specifica si trova lì lync15:, trasferiamo immediatamente il controllo alla funzione open_generic.
Tentativo numero 3 e pensi che abbia funzionato? Sì, adesso, ovviamente. Ma il messaggio di errore è già cambiato, questo è già un progresso - ora mi diceva che il file non è stato trovato e sotto forma di file mi ha scritto lo stesso collegamento passato come argomento.
Questa volta si è rivelata una funzione is_file_url_o_percorso, che analizza il collegamento al file passato all'input: file:// o il percorso del file o qualcos'altro. E il controllo non ha funzionato correttamente perché il nostro prefisso (schema URL) contiene numeri e l'espressione regolare controlla solo il set di caratteri composto da :alpha: punti e trattini. Dopo aver consultato lo standard rfc3986 per identificatore di risorsa uniforme È diventato chiaro che questa volta Microsoft non sta violando nulla (anche se avevo una versione del genere). Solo la classe di caratteri :alpha: contiene solo lettere dell'alfabeto latino. Cambio rapidamente l'assegno normale in alfanumerico. Fatto, sei fantastico, finalmente tutto inizia, il controllo dopo tutti i controlli viene dato alla nostra applicazione di script, il nostro collegamento viene visualizzato sulla console, tutto è come dovrebbe essere. Dopodiché comincio a sospettare che tutti i problemi con exo-open siano dovuti anche alla convalida del formato del collegamento a causa dei numeri nello schema. Per verificare l'ipotesi, modifico la registrazione di tipo MIME dell'applicazione in un semplice schema Lync e voilà: tutto funziona senza sovrascrivere la funzione open_xfce. Ma questo non ci aiuterà in alcun modo, perché la pagina web per accedere alla conferenza crea un collegamento con lync15.
Quindi, la prima parte del viaggio è stata completata. Sappiamo come intercettare una chiamata di collegamento e quindi deve essere in qualche modo elaborata e passata all'interno di Pidgin. Per capire come funziona internamente quando si inseriscono i dati tramite un collegamento nel menu “partecipa a una conferenza”, ho clonato il repository Git del progetto Sipe e mi sono preparato a tuffarmi nuovamente nel codice. Ma poi, fortunatamente, sono stato attratto dalle sceneggiature del catalogo contributo/dbus/:
- sipe-partecipa-alla-conferenza-con-uri.pl
- sipe-partecipa-alla-conferenza-con-l'organizzatore-e-id.pl
- sipe-call-phone-number.pl
- SipeHelper.pm
Si scopre che il plug-in Sipe è disponibile per l'interazione tramite dbus (desktop bus) e all'interno degli script ci sono esempi di partecipazione a una conferenza tramite un collegamento, tramite il nome dell'organizzatore e l'id conf, oppure è possibile avviare una chiamata tramite sip . Questo è esattamente quello che ci mancava.
Passaggio 2. Implementazione di un gestore di autojoin
Dato che in Pearl ci sono esempi già pronti, ho deciso di usarli semplicemente sipe-partecipa-alla-conferenza-con-uri.pl e modificalo un po' per adattarlo alle tue esigenze. So scrivere in Pearl, quindi non ha causato particolari difficoltà.
Dopo aver testato lo script separatamente, ho scritto la sua chiamata nel file lync.desktop. Ed è stata una vittoria! Quando si accede alla pagina di partecipazione alla conferenza e si consente l'esecuzione di xdg-open, la finestra popup della conferenza da Pidgin si aprirà automaticamente. Quanto ho gioito.
Incoraggiato dal successo, ho deciso di fare lo stesso per il mio browser principale, Mozilla Firefox. Quando accedi tramite Fox, si apre una pagina per l'autorizzazione e in fondo c'è un pulsante partecipare utilizzando Office Communicator. È stata lei ad attirare la mia attenzione. Quando si fa clic su di esso nel browser, si va all'indirizzo:
conf:sip:{user};gruu;opaque=app:conf:focus:id:{conf-id}%3Frequired-media=audio
al che mi dice gentilmente che non sa come aprirlo e, forse, non ho un'applicazione associata per tale protocollo. Bene, ci siamo già passati.
Registro rapidamente la mia applicazione di script anche per lo schema URI conf e... non succede nulla. Il browser continua a lamentarsi del fatto che non esiste alcuna applicazione che gestisca i miei collegamenti. In questo caso, chiamare xdg-open dalla console con i parametri funziona perfettamente.
"Imposta gestore di protocollo personalizzato in Firefox": sono andato online con questa domanda. Dopo aver affrontato diverse discussioni su StackOverflow (e dove saremmo senza di esso), sembra che la risposta sia stata trovata. È necessario creare un parametro speciale in about: config (ovviamente sostituendo foo con conf):
network.protocol-handler.expose.foo = false
Lo creiamo, apriamo il collegamento e... nessuna fortuna. Il browser, come se nulla fosse, dice che non conosce la nostra applicazione.
Sto leggendo la documentazione ufficiale sulla registrazione di un protocollo da Mozilla, c'è un'opzione per registrare le associazioni nel desktop gnome stesso (sostituendo foo con conf, ovviamente):
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
Mi registro, apro il browser... e ancora la barba.
Qui una riga della documentazione attira la mia attenzione:
La prossima volta che farai clic su un collegamento di tipo protocollo foo ti verrà chiesto con quale applicazione aprirlo.
— Semyon Semenych
- Ahh
Non clicchiamo sul collegamento, ma la pagina web cambia semplicemente window.location tramite javascript. Scrivo un semplice file html con un collegamento al protocollo conf, lo apro nel browser, faccio clic sul collegamento - Yos! Si apre una finestra che ci chiede in quale applicazione dobbiamo aprire il nostro collegamento, e lì abbiamo già la nostra applicazione Lync nell'elenco: l'abbiamo registrata onestamente in tutti i modi possibili. Lì nella finestra c'è una casella di controllo "ricorda la scelta e apri sempre i collegamenti nella nostra applicazione", contrassegnala, fai clic su OK. E questa è la seconda vittoria: si apre la finestra della conferenza. Allo stesso tempo, l'apertura delle conferenze funziona non solo quando si fa clic su un collegamento, ma anche quando si passa dalla pagina di partecipazione di cui abbiamo bisogno alla conferenza.
Poi ho controllato, cancellando i parametri network.protocol-handler.expose.conf non ha in alcun modo influenzato il funzionamento del protocollo in Fox. I collegamenti hanno continuato a funzionare.
conclusione
Ho caricato tutto il mio lavoro nel repository GitHub; i collegamenti a tutte le risorse saranno alla fine dell'articolo.
Sarò interessato a ricevere feedback da chi vorrà utilizzare il mio lavoro. Dovrei subito notare che ho fatto tutto lo sviluppo solo per il mio sistema Linux Mint, quindi alcune altre distribuzioni o desktop potrebbero non funzionare con quella versione. O meglio, ne sono quasi sicuro, perché ho patchato solo 1 funzione in xdg-open che riguarda solo il mio DE. Se vuoi aggiungere il supporto per altri sistemi o desktop, scrivimi richieste pull su Github.
Il completamento dell'intero progetto ha richiesto 1 sera.
Links:
Fonte: habr.com