Automatische Anmeldung bei Lync-Konferenzen unter Linux

Hey Habr!

Für mich ist dieser Satz so etwas wie „Hallo Welt“, da ich endlich zu meiner ersten Veröffentlichung gekommen bin. Ich habe diesen wundervollen Moment lange aufgeschoben, da es nichts gab, worüber ich schreiben könnte, und ich auch nicht an etwas lutschen wollte, an dem schon ein paar Mal gelutscht worden war. Im Allgemeinen wollte ich für meine erste Veröffentlichung etwas Originelles, das für andere nützlich ist und eine Art Herausforderung und Problemlösung enthält. Und jetzt kann ich das teilen. Lassen Sie uns nun der Reihe nach über alles sprechen.

Eintrag

Alles begann damit, dass ich vor einiger Zeit Linux Mint auf meinen Arbeitscomputer heruntergeladen habe. Viele wissen wahrscheinlich, dass Pidgin mit dem Sipe-Plugin ein durchaus passender Ersatz für Microsoft Lync (heute Skype for Business) für Linux-Systeme ist. Aufgrund der Besonderheiten meiner Arbeit muss ich oft an SIP-Konferenzen teilnehmen, und als Windows-Mitarbeiter war die Teilnahme an Konferenzen elementar: Wir erhalten eine Einladung per E-Mail, klicken auf den Login-Link und schon kann es losgehen .

Beim Umstieg auf die dunkle Seite von Linux wurde alles etwas komplizierter: Natürlich kann man sich auch in Pidgin in Konferenzen einloggen, dafür muss man aber im Menü in den Eigenschaften seines SIP-Kontos die Option „Konferenz beitreten“ auswählen und Fügen Sie im sich öffnenden Fenster einen Link zur Konferenz ein oder geben Sie den Namen des Organisators und die Conf-ID ein. Und nach einiger Zeit begann ich zu denken: „Ist es möglich, das irgendwie zu vereinfachen?“ Ja, könnte man sagen: „Warum zum Teufel brauchen Sie das?“ Ich würde lieber unter Windows sitzen und mich nicht umhauen.

Schritt 1: Recherche

„Wenn einem eine Laune in den Sinn kommt, kann man sie nicht mit einem Pflock ausschalten“, sagte Nekrasov in seinem Werk „Who Lives Well in Rus“.

Als mir also der Gedanke in den Sinn kam, entstand nach einiger Zeit die erste Idee zur Umsetzung. Alles schien einfach – Sie müssen den Zugriff auf Links abfangen meet.company.com/user/confid – Installieren Sie einen lokalen Webanwendungsprozess auf Ihrem Auto unter 127.0.0.1 und fügen Sie in /etc/hosts einen statischen Eintrag für die Unternehmensdomäne hinzu, über die Sie an der Konferenz teilnehmen und auf localhost verweisen. Als nächstes muss dieser Webserver den Link, der zu ihm gelangt ist, verarbeiten und ihn irgendwie in Pidgin übertragen (ich muss gleich sagen, dass ich zu diesem Zeitpunkt noch keine Ahnung hatte, wie ich ihn ihm überhaupt geben soll). Die Lösung riecht natürlich nach Krücken, aber wir sind Programmierer, Krücken machen uns keine Angst (Scheiße).

Dann habe ich zufällig den Einladungslink in Google Chrome geöffnet (und normalerweise verwende ich immer Mozilla Firefox). Und zu meiner Überraschung sah die Webseite ganz anders aus – es gab kein Formular zur Eingabe von Benutzerdaten und direkt nach dem Betreten der Seite kam die Aufforderung, etwas zu öffnen xdg-offen. Aus Spaß klicke ich auf „Ja“ und es erscheint eine Fehlermeldung: Der Link lync15:confjoin?url=https://meet.company.com/user/confid kann nicht geöffnet werden. Hmm. Was für ein xdg-open ist das und was braucht es, damit sich solche Links öffnen? Eine Nachprüfung der Dokumentation ergab, dass es sich um einen GUI-Handler handelt, der die Ausführung zugehöriger Anwendungen entweder mit Protokollen für das URI-Schema oder mit bestimmten Dateitypen unterstützt. Assoziationen werden über MIME-Type-Mapping konfiguriert. Wir sehen also, dass wir nach einer passenden Anwendung für ein URI-Schema mit dem Namen suchen lync15 und der Link wird an xdg-open übergeben, das ihn dann theoretisch an eine Anwendung weiterleiten sollte, die für diese Art von Link verantwortlich ist. Was wir natürlich nicht in unserem System haben. Wenn nicht, was machen sie dann in der Open-Source-Welt? Genau, wir schreiben es selbst.

Das weitere Eintauchen in die Welt von Linux und insbesondere das Studium der Funktionsweise der grafischen Shell (Desktop-Umgebung, DE), ich habe übrigens Xfce in Linux Mint, hat gezeigt, dass Anwendungen und der damit verbundene Mime-Typ normalerweise direkt geschrieben werden Verknüpfungsdateien mit der Erweiterung .desktop. Warum nicht? Ich erstelle eine einfache Anwendungsverknüpfung, die einfach ein Bash-Skript starten und das übergebene Argument an die Konsole ausgeben soll. Ich stelle nur die Verknüpfungsdatei selbst bereit:

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

Ich starte xdg-open von der Konsole aus, übergebe den gleichen Link, der vom Browser kommt, und ... Mist. Wieder heißt es, dass der Link nicht verarbeitet werden kann.

Wie sich herausstellte, habe ich das Verzeichnis der mit meiner Anwendung verknüpften Mime-Typen nicht aktualisiert. Dies geschieht mit einem einfachen Befehl:

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

wodurch die Datei einfach bearbeitet wird ~/.config/mimeapps.list.

Versuch Nummer 2 mit dem xdg-open-Aufruf – und wieder Misserfolg. Nichts, Schwierigkeiten machen uns keine Angst, sondern wecken nur unser Interesse. Und bewaffnet mit der ganzen Kraft von Bash (d. h. Tracing) stürzen wir uns kopfüber in die Fehlersuche. Es ist wichtig zu beachten, dass xdg-open nur ein Shell-Skript ist.

bash -x xdg-open $url

Wenn man die Ausgabe nach dem Tracing analysiert, wird ein wenig klar, dass die Kontrolle dann übertragen wird exo-offen. Und dies ist bereits eine Binärdatei und es ist schwieriger zu verstehen, warum sie einen erfolglosen Rückkehrcode zurückgibt, wenn in einem Argument ein Link darauf übergeben wird.

Nachdem ich mir die Interna von xdg-open angesehen habe, habe ich herausgefunden, dass es verschiedene Umgebungsparameter analysiert und die Kontrolle entweder an einige Tools zum Öffnen von Dateiverknüpfungen weitergibt, die für ein bestimmtes DE spezifisch sind, oder dass es über eine Fallback-Funktion verfügt 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
}

Ich werde hier schnell einen kleinen Hack mit der Analyse des übergebenen Arguments und der Frage, ob sich unser spezifischer Teilstring dort befindet, einbetten lync15:, dann übergeben wir sofort die Kontrolle an die Funktion open_generic.

Versuch Nummer 3 und glauben Sie, dass es funktioniert hat? Ja, jetzt natürlich. Aber die Fehlermeldung hat sich bereits geändert, das ist schon ein Fortschritt – jetzt sagte er mir, dass die Datei nicht gefunden wurde und in Form einer Datei schrieb er mir den gleichen Link, der als Argument übergeben wurde.

Diesmal stellte sich heraus, dass es eine Funktion war is_file_url_or_path, das den an die Eingabe übergebenen Dateilink analysiert: file:// oder den Pfad zur Datei oder etwas anderes. Und die Prüfung funktionierte nicht richtig, da unser Präfix (URL-Schema) Zahlen enthält und der reguläre Ausdruck nur den Zeichensatz prüft, der aus :alpha: Punkten und Bindestrichen besteht. Nach Rücksprache mit dem RFC3986-Standard für einheitlicher Ressourcenbezeichner Es wurde klar, dass Microsoft diesmal nichts verletzt (obwohl ich eine solche Version hatte). Nur die Zeichenklasse :alpha: enthält nur Buchstaben des lateinischen Alphabets. Ich ändere den regulären Scheck schnell auf alphanumerisch. Fertig, Sie sind großartig, alles startet endlich, die Kontrolle nach allen Prüfungen liegt an unserer Skriptanwendung, unser Link wird auf der Konsole angezeigt, alles ist so, wie es sein sollte. Danach beginne ich zu vermuten, dass alle Probleme mit exo-open auch auf die Validierung des Linkformats aufgrund der Zahlen im Schema zurückzuführen sind. Um die Hypothese zu testen, ändere ich die Mime-Typ-Registrierung der Anwendung in ein reines Schema Lync und voila – alles funktioniert, ohne die Funktion open_xfce zu überschreiben. Dies hilft uns jedoch überhaupt nicht, da die Webseite für die Teilnahme an der Konferenz eine Verknüpfung mit lync15 herstellt.

Der erste Teil der Reise ist also abgeschlossen. Wir wissen, wie man einen Link-Aufruf abfängt und dieser dann irgendwie verarbeitet und in Pidgin weitergeleitet werden muss. Um zu verstehen, wie es intern funktioniert, wenn Daten über einen Link im Menü „An einer Konferenz teilnehmen“ eingegeben werden, habe ich das Git-Repository des Sipe-Projekts geklont und mich darauf vorbereitet, erneut in den Code einzutauchen. Aber dann haben mich glücklicherweise die Drehbücher im Katalog angezogen contrib/dbus/:

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

Es stellt sich heraus, dass das Sipe-Plugin für die Interaktion über dbus (Desktop-Bus) verfügbar ist und in den Skripten Beispiele für den Beitritt zu einer Konferenz über einen Link enthalten sind, entweder über den Namen und die Conf-ID des Organisators, oder Sie können einen Anruf über sip einleiten . Genau das hat uns gefehlt.

Schritt 2. Implementieren eines Autojoin-Handlers

Da es in Pearl vorgefertigte Beispiele gibt, habe ich mich für die Verwendung entschieden sipe-join-conference-with-uri.pl und modifizieren Sie es ein wenig, um es an Ihre Bedürfnisse anzupassen. Ich kann in Pearl schreiben, daher bereitete es keine besonderen Schwierigkeiten.

Nachdem ich das Skript separat getestet hatte, schrieb ich seinen Aufruf in die Datei lync.desktop. Und es war ein Sieg! Wenn Sie die Konferenzbeitrittsseite aufrufen und die Ausführung von xdg-open zulassen, wird das Konferenz-Popup-Fenster von Pidgin automatisch geöffnet. Wie ich mich gefreut habe.
Ermutigt durch den Erfolg, beschloss ich, dasselbe für meinen Hauptbrowser, Mozilla Firefox, zu tun. Wenn Sie sich über den Fox anmelden, öffnet sich eine Seite zur Autorisierung und ganz unten befindet sich ein Button Nehmen Sie über den Office Communicator teil. Sie war diejenige, die meine Aufmerksamkeit erregte. Wenn man im Browser darauf klickt, gelangt man zur Adresse:

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

Daraufhin teilt er mir freundlicherweise mit, dass er nicht weiß, wie man es öffnet, und dass ich möglicherweise keinen zugehörigen Antrag für ein solches Protokoll habe. Nun ja, das haben wir schon durchgemacht.

Ich registriere meine Skriptanwendung schnell auch für das URI-Schema conf und... nichts passiert. Der Browser beschwert sich ständig darüber, dass es keine Anwendung gibt, die meine Links verarbeitet. In diesem Fall funktioniert der Aufruf von xdg-open über die Konsole mit Parametern einwandfrei.

„Benutzerdefinierten Protokollhandler in Firefox festlegen“ – ich bin mit dieser Frage online gegangen. Nach mehreren Diskussionen zum Thema Stackoverflow (und wo wären wir ohne Stackoverflow) scheint die Antwort gefunden worden zu sein. Sie müssen einen speziellen Parameter erstellen about: config (natürlich foo durch conf ersetzen):

network.protocol-handler.expose.foo = false

Wir erstellen es, öffnen den Link und ... kein Glück. Der Browser sagt, als wäre nichts passiert, dass er unsere Anwendung nicht kennt.

Ich lese die offizielle Dokumentation zum Registrieren eines Protokolls von Mozilla. Es gibt eine Option zum Registrieren von Zuordnungen im Gnome-Desktop selbst (wobei natürlich „foo“ durch „conf“ ersetzt wird):

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

Ich registriere mich, öffne den Browser... und schon wieder der Bart.

Hier fällt mir eine Zeile aus der Dokumentation ins Auge:

Wenn Sie das nächste Mal auf einen Link vom Protokolltyp „foo“ klicken, werden Sie gefragt, mit welcher Anwendung Sie ihn öffnen möchten.

— Semyon Semenych
- Ahh

Wir klicken nicht auf den Link, sondern die Webseite ändert einfach window.location per Javascript. Ich schreibe eine einfache HTML-Datei mit einem Link zum Conf-Protokoll, öffne sie im Browser, klicke auf den Link – Yos! Es öffnet sich ein Fenster mit der Frage, in welcher Anwendung wir unseren Link öffnen müssen, und dort haben wir bereits unsere Lync-Anwendung in der Liste – wir haben sie auf alle möglichen Arten ehrlich registriert. Dort im Fenster gibt es ein Kontrollkästchen „Auswahl merken und Links immer in unserer Anwendung öffnen“, markieren Sie es und klicken Sie auf „OK“. Und das ist der zweite Sieg – das Konferenzfenster öffnet sich. Gleichzeitig funktioniert das Öffnen von Konferenzen nicht nur, wenn Sie auf einen Link klicken, sondern auch, wenn Sie von der benötigten Beitrittsseite zur Konferenz wechseln.

Dann habe ich nachgesehen und Parameter gelöscht network.protocol-handler.expose.conf hatte in keiner Weise Einfluss auf den Betrieb des Protokolls in Fox. Die Links funktionierten weiterhin.

Abschluss

Ich habe meine gesamte Arbeit in das GitHub-Repository hochgeladen; Links zu allen Ressourcen finden Sie am Ende des Artikels.
Ich bin daran interessiert, Feedback von denjenigen zu erhalten, die meine Arbeit nutzen möchten. Ich sollte sofort anmerken, dass ich die gesamte Entwicklung nur für mein Linux Mint-System durchgeführt habe, sodass einige andere Distributionen oder Desktops möglicherweise nicht in dieser Version funktionieren. Oder besser gesagt, ich bin mir dessen sogar fast sicher, da ich in xdg-open nur eine Funktion gepatcht habe, die sich nur auf meine DE bezieht. Wenn Sie Unterstützung für andere Systeme oder Desktops hinzufügen möchten, schreiben Sie mir Pull-Requests auf Github.

Die Fertigstellung des gesamten Projekts dauerte einen Abend.

Links:

Source: habr.com

Kommentar hinzufügen