Seit Sommer 2024 hat Google die alte Push-API abgeschaltet. In der V9.0.311 wurde daher eine neue API implementiert, welche für die Zustellung der Pushnachrichten benötigt wird. |
Wenn Sie von einem der Folgenden Themen betroffen sind, liegt die Ursache häufig darin, dass mit der Push-Konfiguration etwas noch nicht stimmt.
Übersicht:
Legende zu den gelben Punkten (siehe Portübersicht Dokumentation):
Konfiguration
Step 0 - DNS und Proxy-Server und HTTP Verben (PUT, DELETE, ...)
DNS
Überprüfen Sie, ob der XPhone Server alle benötigten Servernamen im öffentlichen DNS auflösen kann. Wenn z.B. die Servernamen "mobile.c4b.de", "api.push.apple.com", " https://fcm.googleapis.com/" oder "https://oauth2.googleapis.com" nicht in IP Adressen aufgelöst werden können, können keine Push-Nachrichten zugestellt werden.
Sie können das z.B. mit dem Kommando "nslookup" überprüfen. Es darf nicht zu einem Timeout kommen, wie in diesem Fehler-Beispiel:
Proxy-Server
Welche Proxy-Einstellungen gelten auf dem XPhone Server? Konfigurieren Sie ggf. einen Proxy-Server in der XPhone Administration und aktivieren Sie diese Einstellung auch für den Push-Dienst.
Umgekehrt kann es ebenso sein, dass für den XPhone Server eine explizite Ausnahme im konfiguriert ist, so dass er den Proxy umgehen darf. In diesem Fall kann es notwendig sein, dass die automatische Proxy-Erkennung in Windows dauerhaft abgeschaltet wird:
Spezielle HTTP Verben (PUT, DELETE, ...)
Es gibt Reverse Proxies oder (Web Application-) Firewalls, die nicht alle HTTP Verben zulassen. Im Normalfall sind GET und POST erlaubt.
Unsere Mobile Anwendung verwendet jedoch auch PUT und DELETE, insbesondere zum Schreiben des für Push-Nachrichten notwendigen DeviceTokens. Wenn dieser Token nicht in die XPhone Datenbank geschrieben werden kann, werden keine Push-Nachrichten an das Mobile Device gesendet.
Die Mobile Anwendung erkennt die gesperrten HTTP Verben u.U. nicht einmal als Fehler an. Grund: der Reverse Proxy bzw. die WAF returniert ein "200 OK" an den Client.
Wenn unklar ist, ob die DeviceTokens korrekt in der XPhone Datenbank hinterlegt wurden, werfen Sie einen Blick in diese Tabelle über das SQL Server Management Studio:
[XPDATA].[dbo].[EfUserPushNotificationDevices]
Step 1 - Installation auf dem IIS des XPhone Connect Servers
Auf dem IIS des XPhone Servers (selbst wenn vorhanden, nicht auf dem ausgelagerten IIS) muss die Web-Anwendung "IIS\Sites\Default Web Site\XPhoneConnect\PushProxy" installiert sein.
Zusätzlich muss die Web-Anwendung "PushProxy" unter dem Application-Pool "XPhoneConnectPushProxy" laufen (rechte Maustaste → Erweiterte Einstellungen):
Der Anwendungs-Pool "XPhoneConnectPushProxy" läuft standardmäßig unter der Identität "ApplicationPoolIdentity":
Je nachdem, welche Berechtigungen für die Firewall oder evtl. für einen Proxy-Server im Unternehmen benötigt werden, um die beteiligten Dienste im Internet zu erreichen, muss die Identität des Anwendungs-Pools umgestellt werden, z.B. auf einen berechtigten Domänen-User. Dazu klickt man auf die den Butten mit den drei Punkten (neben dem roten Rahmen) und gelangt in einen Dialog zum Eintragen der neuen Identität. In der Regel wird man ein "Benutzerdefiniertes Konto:" wählen und die Anmeldinformationen über den Butten "Festlegen:" definieren:
WICHTIG: Dieser Account braucht ebenfalls Schreibrechte auf dem Verzeichnis "C:\Program Files\C4B\XPhone Connect Server\PushProxy"!
Hintergrund: Der PushProxy muss dort im Filesystem die Zertifikate ablegen, die er sich von "mobile.c4b.de" beschafft hat:
Step 2 - Zugriff des XPhone Server Dienstes auf die Web-Anwendung "PushProxy"
Dieser lokale HTTP-Zugriff (Port 80) sollte immer funktionieren. Im Auslieferungszustand versucht der XPhone Server den PushProxy auf dieser URL zu erreichen:
http://localhost/XPhoneConnect/PushProxy/
Man kann die Erreichbarkeit des PushProxy-Dienstes mit Hilfe eines "healthcheck" überprüfen. Dazu gibt man im Browser, der auf dem XPhone Server Rechner geöffnet ist, diese URL ein:
http://localhost/XPhoneConnect/PushProxy/healthcheck
Als Ergebnis sollte man eine weiße Seite und eine HTTP Response 200 erhalten. Wenn das nicht der Fall ist, helfen die folgenden "ACHTUNG" Hinweise weiter.
Ein guter Einstiegspunkt in die Analyse sind die im IIS eingestellten "Bindungen" für die Default Webseite:
Im obigen Beispiel sind keine Einschränkungen bzgl. Hostname oder IP-Adresse für Port 80 eingestellt. Das ist auch der Default. Je nachdem, welche Einstellungen in Ihrem System vorhanden sind, kann es sein, dass man mit "localhost" nicht auf dem IIS kommt. In einem solchen Fall befolgen Sie bitte die "ACHTUNG" Hinweise:
ACHTUNG (1): Es gibt Kunden, die auch für den lokalen Zugriff auf den IIS (also auf "localhost") immer SSL erzwingen. In diesem Fall kann der XPhone Server den PushProxy nicht auf Port 80 erreichen. Abhilfe: Erlauben Sie im IIS für den PushProxy auch den Zugriff über HTTP (Port 80).
Bei der Analyse haben die Eventlogs für das PushProxyModule geholfen (Detaillierte Debugmeldungen). Dort steht, dass HTTP nicht erlaubt ist, weil HTTPS zwingend erforderlich ist.
ACHTUNG (2): Manche Kunden stellen im IIS ein (auch auf dem IIS, der auf dem XPhone Server läuft), dass jeder HTTP Request automatisch auf HTTPS umgeleitet wird. Dann ist HSTS aktiviert und der Haken bei "HTTP an HTTPS umleiten" gesetzt:
(Der Punkt 'HSTS...' ist in der rechten Menüleiste zu finden, wenn im IIS die 'Default Web Site' markiert ist).
Damit kommt unser Push-Mechanismus nicht ohne weiteres zurecht. Der XPhone Server sucht den PushProxy standardmäßig auf "http://localhost/xphoneconnect/pushproxy/". Durch die erzwungene Umleitung auf HTTPS erreicht er ihn dort nicht mehr.
Um das zu lösen, muss in der Datei atlas.xml die korrekte URL für den PushProxy eingetragen werden. Man fügt in der schon vorhandenen Sektion <PushNotificationSettings> das neue Attribut "proxyBaseAddress" hinzu und trägt dort die passende URL für den PushProxy ein:
<PushNotificationSettings
proxyBaseAddress="https://servername_not_localhost/xphoneconnect/pushproxy" ... />
ACHTUNG (3): In einem Kundenfall war es so, dass weder URL "http://localhost/..." noch die URL "http://127.0.0.1/...." auf dem IIS des XPhone Servers erreichbar waren. Der XPhone Server lief in diesem Szenario auf einem ausgelagerten Rechenzentrum. Genaue Ursachen wurden nicht erforscht.
Abhilfe: genau wie im vorigen ACHTUNG (2) hat es geholfen den Eintrag in der atlas.xml zu setzen (lokale IP Adresse ungleich localhost und ungleich 127.0.0.1).
ACHTUNG (4): In manchen IIS Installationen ist das Feature "IP- und Domäneneinschränkungen" aktiviert:
Achten Sie in diesem Fall darauf, dass der XPhone Server Dienst auf die Web-Anwendung "PushProxy" ausreichend Zugriffberechtigungen hat. Es müssen also i.d.R. alle lokalen IP-Adressen erlaubt sein.
Ist das Feature installiert, aber nicht konfiguriert, kann es sich wie eine Art Blacklist verhalten und ebenfalls den Zugriff auf die localhost-Adresse sperren.
Ein Indiz für diesen Fall ist, dass die reguläre XPhone Connect Administrationsoberfläche nicht über localhost aufrufbar ist. Hier hilft es, das Feature einfach wieder zu deinstallieren.
Wichtig: Klären Sie zuvor mit dem Kunden, ob das Feature absichtlich und für einen bestimmten Grund installiert wurde und falls dem so ist, prüfen Sie stattdessen die Zugriffsberechtigungen.
Step 3 - Zugriff auf https://mobile.c4b.de/pushconfig
Der Dienste-Account des XPhone Connect Servers muss auf die URL https://mobile.c4b.de/pushconfig zugreifen können. Dazu muss Port 443 ausgehend in der Firewall geöffnet sein.
Der Aufruf dieser URL muss diese Anmeldemaske anzeigen. Damit ist die Erreichbarkeit gegeben. Man muss sich nicht anmelden können (die Credentials sind "geheim").
Der PushProxy holt sich von dort die Zugriffs-Tokens für die Anmeldung am Apple / Google Push Service. Diese Tokens speichert er lokal im Verzeichnis "C:\Program Files\C4B\XPhone Connect Server\PushProxy" ab. Dazu benötigt er Schreibrechte auf diesem Verzeichnis!
Die Berechtigungen müssen dem technischen Windows-User "IIS APPPOOL\XPhoneConnectPushProxy" vergeben werden:
Fehlen diese Berechtigungen, können die Tokens nicht gespeichert werden und in der Folge werden auch keine Push-Nachrichten an den Apple / Google Push Service geschickt.
Step 4 - Zugriff der Web-Anwendung "PushProxy" auf die Push-Services
Die Firewall muss so konfiguriert werden, dass alle Ports der Push-Services von Google und Apple ausgehend erreichbar sind.
Wenn man ein Tool zur Hand hat (z.B. Postman), mit dem man HTTP POST Aufrufe absetzen kann, kann man die Erreichbarkeit der Apple Services wie folgt überprüfen:
Für IOS:
URL: http://localhost/XPhoneConnect/PushProxy/applepush/sendpush
Body:
{
"DeviceToken":"35bcc4a98613f55788bf7c3db77c1ec5e48eb7a66577ab2de9fd05173d1c4b6e",
"Payload":"{\"aps\":{\"alert\":\"Push-Test\", \"sound\":\"default\", \"badge\":10}, \"data\":{\"MessageType\":\"IM\"}}",
"Priority":10,
"Topic":"com.c4b.mxphoneconnect",
"PushType":1,
"Id":"2c3d2bce-fd41-42bb-a96c-8e5d0196b4b9",
"Secret":"C$B"
}
Für Android:
URL: http://localhost/XPhoneConnect/PushProxy/androidpush/sendpush
Body:
{
"Secret":"C$B",
"DeviceToken":"eWtIimAzQyiicOLAXvvSaJ:APA91bH15qf9ab9NsSwSD7STfsWC3rtnLBVgsnaEiIvJDszr85ii7-flpBwy3vxBFQ7KcYPR82VgTr7IxpEsD1clJtEnMXtepS_ltbr-giOdi_plX2b0kOy9Q11mIYXokggjDn3Um4a9",
"Id":"2c3d2bce-fd41-42bb-a96c-8e5d0196b4b9",
"Priority": 10,
"Body":"Push-Test",
"Badge": 3,
"App": "XPhoneMobile",
"Payload": {"MessageType": "IM"}
}
Wichtig: Einen gültigen DeviceToken für erhält man aus den Logs des Mobile Clients. Man sucht dort nach einer subscriptionId (Quelle PushNotifications):
Der Token ist alles innerhalb der eckigen Klammern (ohne die Klammern) aus dem oberen Screenshot. Hinweis: Bei Android enthalten die Tokens mehr Zeichen bspw.:
eWtIimAzQyiicOLAXvvSaJ:APA91bH15qf9ab9NsSwSD7STfsWC3rtnLBVgsnaEiIvJDszr85ii7-flpBwy3vxBFQ7KcYPR82VgTr7IxpEsD1clJtEnMXtepS_ltbr-giOdi_plX2b0kOy8Q11mIYXokggjDn3Um4a9
Auf diese Weise kann man sich eine "echte" Push-Notification an sein iPhone schicken.
Als Ergebnis wird man im Erfolgsfall ein "200 OK" erhalten, am Handy erhält man die Push Nachricht "Push-Test".
Verwendung von CURL anstatt Postman
Wer Postman gerade nicht zur Hand hat, kann den PushProxy-Test auch mit dem standardmäßig installierten Tool CURL ausführen. Dazu verwendet man je nach Smartphone-Betriebssystem die folgenden Batch Dateien:
Android: https://github.com/C4BCSMORG/tmp/raw/main/androidpush.bat
IOS: https://github.com/C4BCSMORG/tmp/raw/main/applepush.bat
Bearbeiten Sie die Batch Datei (Rechtsklick > Öffnen mit Editor) und ergänzen Sie den DeviceToken (siehe oben). Hier ein Beispiel:
@SET _DEVICETOKEN=35bcc3a98613f55778bf7c3db77c1ec5e48eb7a66577ab2de9fd05553d1c4b6e @SET _MESSAGE=Push-Test @ECHO PushProxy Test @ECHO ==============
[...]
Speichern Sie die Datei anschließend ab und führen Sie diese auf dem XPhone Server aus. Sie erhalten ein Ergebnis wie Folgt, aus dem Sie Fehler / Erfolg entnehmen können:
Step 5 - Funktionstest
Richten Sie die XPhone Connect Mobile App auf einem Smartphone (Android, iOS) ein und verbinden Sie sich mit einem XPhone User Account ("Mobile User").
Aktivieren Sie in der Mobile App die Push-Benachrichtigungen (Hamburger-Menü → Einstellungen → Push-Benachrichtigungen).
Dieser Mobile User muss jetzt alle laufenden XPhone Connect Desktop Clients und die Mobile App auf dem Smartphone beenden. Hinweis: so lange noch ein Desktop-Client läuft, werden keine Push-Nachrichten verschickt!
Szenario 1: ein anderer XPhone User schickt eine IM-Nachricht an den Mobile User. Der Mobile User muss in kurzer Zeit eine Push-Nachricht darüber empfangen.
Szenario 2: Der Mobile User stellt als aktives Gerät seine Office Leitung ein. Jetzt wird er von einem anderen XPhone User oder von einem externen Teilnehmer auf seiner Office-Nummer angerufen. Kurze Zeit später sollte er eine Push-Nachricht über einen verpassten Anruf erhalten.
Sind beide Tests erfolgreich, wurde Push korrekt eingerichtet.
Relevante Links:
https://help.c4b.com/xphone-connect-9/doc/de/admin/config/feat/mobile.html#push-benachrichtigungen
https://help.c4b.com/xphone-connect-9/doc/de/admin/start/sys-req/infrstrctr.html#inst-mobile-push
Kommentare
0 Kommentare
Zu diesem Beitrag können keine Kommentare hinterlassen werden.