diff --git a/concept/index.html b/concept/index.html index f7406fb..0a0a247 100644 --- a/concept/index.html +++ b/concept/index.html @@ -463,11 +463,17 @@

Notification Management Registrierung einer ePA-FdV-Instanz Status In Review orange
  • Deregistrierung einer FdV-Instanz Status Draft red
  • Liste aktuelle Pushers enthalten Status Draft red
    • -
  • Versenden von Push-Notifications Status Draft red
    • +
  • Versenden von Push-Notifications Status Draft red + +
    • +
  • Themen für produktspezifische Implementierungen
  • Beispiele Status Draft red
      +
    • Device Registrierung
    • Event-Trigger
    • Apple Push
        @@ -489,7 +495,7 @@

        Notification Management Konzept

        -

        Versicherte können sich über das mobile FdV mittels Push-Notifications über Ereignisse in Fachdiensten (z.B. ePA-Aktensystem, E-Rezept-Fachdienst, Dienste der Kassen) informieren lassen. Der Versicherte kann im FdV aus den möglichen Ereignissen diejenigen auswählen, für die er benachrichtigt werden möchte. Standardmäßig werden keine Push-Notifications gesendet. Das Konzept sieht vor, dass der Versicherte Push-Notifications für verschiedene Fachdienste abonnieren kann. Die Push-Notifications werden verschlüsselt übermittelt und können nur von der ePA-FdV-Instanz entschlüsselt werden, für die sie bestimmt sind.

        +

        Versicherte können sich über das mobile FdV mittels Push-Notifications über Ereignisse in Fachdiensten (z.B. ePA-Aktensystem, E-Rezept-Fachdienst, Dienste der Kassen) informieren lassen. Der Versicherte kann im FdV aus den möglichen Ereignissen (zum Beispiel in Form von Channels) diejenigen auswählen, für die er benachrichtigt werden möchte. Standardmäßig werden keine Push-Notifications gesendet.

        Architektur Status In Review orange

        @@ -498,20 +504,33 @@

        Architektur
        -push overview +push overview
        Abbildung 1. Systemüberblick

        +
        +

        Der Zweck dieses Konzepts besteht darin, eine flexible und sichere Push Infrastruktur bereitzustellen, die es ermöglicht, dass verschiedene Fachdienste Push-Notifications an eine mobile Anwendung senden können. +Durch die Implementierung eines zentralen Push Gateways pro Frontend wird eine einheitliche Schnittstelle geschaffen, die als Fassade für die plattformspezifischen APIs von Anbietern wie Google und Apple fungiert. Dies erlaubt es mehreren Backends, gleichzeitig Push-Benachrichtigungen für eine fremde App bereitzustellen, ohne dass jedes Backend individuell mit den plattformspezifischen APIs interagieren muss. Ein wesentlicher Vorteil dieses Ansatzes ist die erhöhte Sicherheit: Die sensiblen Zugangsdaten und Schlüssel, die für die Nutzung der plattformspezifischen Push-APIs erforderlich sind, verbleiben beim Push Gateway und müssen nicht mit den einzelnen Fachdiensten geteilt werden. Dadurch wird das Risiko eines unbefugten Zugriffs auf diese Geheimnisse minimiert und die Integrität der Kommunikation gewährleistet. Als Vorbild dient die Push Implementierung wie sie im Matrix Protokoll beschrieben ist.

        +
        +
        +
        +secret channel.drawio +
        +
        Abbildung 2. Veschlüsselter Kanal zwischen Fachdienst und FdV
        +
        +
        +

        Um zusätzliche Sicherheit zu gewährleisten kann eine Push-Nachricht zwischen dem Fachdienst und dem FdV verschlüsselt werden. Weder Push Gateway noch Push Provider besitzen die Information um eine Entschlüsselung vorzunehmen. Die Entscheidung ob eine Push-Nachricht verschlüsselt werden muss oder unverschlüsselt bleiben kann wird durch die Spezifikation des jeweiligen Fachdienstes vorgenommen. Bisher wird davon ausgegangen, dass eine Verschlüsselung für ePA und E-Rezept notwending sein wird, diese jedoch bei TIM optional ist.

        +

        Fachdienst Status In Review orange

        -

        Der anwendungsspezifische Fachdienst verwalten die Push-Notifications für den jeweiligen Anwendungsfall. Der Fachdienst erstellt Push-Notifications für abonnierte Ereignisse und übermittelt diese an das zuständige Push Gateway. Er bietet Schnittstellen für Versicherte zur Registrierung und Konfiguration von Pushern. Ein Pusher bezieht sich auf eine FdV-Instanz und ist eine Konfiguration im Fachdienst, in der die Informationen zur Adressierung der Push-Notifications hinterlegt werden (u.a. das zu nutzende Push Gateway, Schlüssel zur Verschlüsselung von Nachrichteninhalten). Der Versicherte kann für beliebig viele Endgeräte Pusher im Fachdienst hinterlegen.

        +

        Der anwendungsspezifische Fachdienst verwaltet die Push-Notifications für den jeweiligen Anwendungsfall. Der Fachdienst erstellt Push-Notifications für abonnierte Ereignisse und übermittelt diese an das zuständige Push Gateway. Er bietet Schnittstellen für Versicherte zur Registrierung und Konfiguration von Pushern. Ein Pusher bezieht sich auf eine FdV-Instanz und ist eine Konfiguration im Fachdienst, in der die Informationen zur Adressierung der Push-Notifications hinterlegt werden (u.a. das zu nutzende Push Gateway, Schlüssel zur Verschlüsselung von Nachrichteninhalten). Der Versicherte kann für mehrere Endgeräte Pusher im Fachdienst hinterlegen.

        Push Gateway Status In Review orange

        -

        Das Push Gateway besitzt einen anwendungsübergreifenden Endpunkt, an den Push-Notifications übermittelt werden. Das Push Gateway leitet die Informationen der Push- Notification an den Push Provider weiter. Es wird vom Hersteller des FdV bereitgestellt, und es kann weitere Endpunkte für Kassendienste geben, die ebenfalls über dieses Push Gateway Notifications versenden.

        +

        Das Push Gateway besitzt einen anwendungsübergreifenden Endpunkt, an den Push-Notifications übermittelt werden. Das Push Gateway leitet die Informationen der Push-Notification an den Push Provider weiter. Es wird vom Hersteller des FdV bereitgestellt, und es kann weitere Endpunkte für Kassendienste geben, die ebenfalls über dieses Push Gateway Notifications versenden.

        @@ -523,7 +542,7 @@

        Push Provider

        FdV Instanz Status In Review orange

        -

        Die FdV-Instanz ist ein auf einem mobilen Endgerät installiertes FdV. Push-Notifications werden für eine FdV-Instanz registriert und an diese gesendet. Die FdV-Instanz kann mehrere Anwendungen integrieren (ePA, E-Rezept, TI-Messenger, Kassenanwendungen), für die der Versicherte jeweils Push Notifications auswählen kann.

        +

        Die FdV-Instanz ist ein auf einem mobilen Endgerät installiertes FdV. Push-Notifications werden für eine FdV-Instanz registriert und an diese gesendet. Die FdV-Instanz kann mehrere Anwendungen integrieren (ePA, E-Rezept, TI-Messenger, Kassenanwendungen), für die der Versicherte jeweils Push-Notifications auswählen kann.

        @@ -531,12 +550,9 @@

        FdV Instanz Authentisierung Status In Review orange

        -push overview authentication -
        -
        Abbildung 2. Authentisierung der beteiligten Komponenten
        +push overview authentication
        -
        -

        Die Verbindungen zwischen Push Gateway und den Fachdiensten sind beidseitig authentisiert und verschlüsselt.

        +
        Abbildung 3. Authentisierung der beteiligten Komponenten

        Die Verbindungen zwischen Push Gateway und den Fachdiensten sind beidseitig authentisiert und verschlüsselt. @@ -546,16 +562,16 @@

        Authentisierung

        Verschlüsselung des Benachrichtigungsinhaltes Status Draft red

        -

        Der Benachrichtigungsinhalt einer jeden Benachrichtigung wird mittels eines Authenticated-Encryption-Verfahrens verschlüsselt (AES/GCM), sodass der Inhalt der Benachrichtigung nicht von Dritten eingesehen oder veränderten werden kann.

        +

        Der Benachrichtigungsinhalt einer jeden Benachrichtigung wird mittels eines Authenticated-Encryption-Verfahrens verschlüsselt (AES/GCM), sodass der Inhalt der Benachrichtigung nicht von Dritten eingesehen oder verändert werden kann.

        -

        Wenn sich eine FdV-Installation beim Fachdienst für Benachrichtigungen registriert, erzeugt die App ein initiales gemeinsames Geheimnis (initial-shared-secret (ISS)) und überträgt dieses kryptographisch gesichert an den Fachdienst.

        +

        Wenn sich eine FdV-Instanz beim Fachdienst für Benachrichtigungen registriert, erzeugt die App ein initiales gemeinsames Geheimnis (initial-shared-secret (ISS)) und überträgt dieses kryptographisch gesichert an den Fachdienst.

        -

        Dieses gemeinsame Geheimnis ist die Grundlage der kryptographischen Sicherung des Benachrichtigungsinhaltes. Die Benachrichtigung wird vom Fachdienst mit verschlüsseltem Benachrichtigungsinhalt über das Push Gateway und den Push Provider an die FdV-Installation übermittelt.

        +

        Dieses gemeinsame Geheimnis ist die Grundlage der kryptographischen Sicherung des Benachrichtigungsinhaltes. Die Benachrichtigung wird vom Fachdienst mit verschlüsseltem Benachrichtigungsinhalt über das Push Gateway und den Push Provider an die FdV-Instanz übermittelt.

        -

        Ganz ähnlich wie bei vielen Messaging-Anwendungen werden die verwendeten Schlüssel für die kryptographische Absicherung der Nachrichten regelmäßig gewechselt auf eine Weise, dass eine Wiederherstellbarkeit von alten Schlüssel kryptographisch ausgeschlossen ist.

        +

        Ganz ähnlich wie bei vielen Messaging-Anwendungen werden die verwendeten Schlüssel für die kryptographische Absicherung der Nachrichten regelmäßig gewechselt auf eine Weise, dass eine Wiederherstellbarkeit von alten Schlüsseln kryptographisch ausgeschlossen ist.

        Der Fachdienst erhält ein ISS und einen Zeitstempel von dessen Erzeugung von dem FdV bei der Registrierung. Mittels einer "Hashed Message Authentication Code (HMAC)-based key derivation function" (HKDF) [RFC-5869] werden per HKDF(ISS, info="<Jahr>-<Monat>") zwei Werte abgeleitet:

        @@ -585,7 +601,7 @@

        Beispiel für einen Aust

        Alle shared-secret-Jahr-Monat und alle AES/GCM-Schlüssel-Jahr-Monat, die älter sind als zwei Monate werden, sowohl im Notification Service als auch im E-Rezept-FdV gelöscht, jedoch niemals das jüngste noch verfügbare (auch wenn es älter als zwei Monate ist). Der fachliche Hintergrund von "zwei Monaten" ist, dass sichergestellt sein muss, dass falls der E-Rezept-FD die Benachrichtigung Sekunden vor Monatsende erstellt, und diese im E-Rezept-FdV erst nach einigen Sekunden dann im Folgemonat empfangen werden, die Entschlüsselung im E-Rezept-FdV immer noch möglich sein muss.

        -

        Sollte erst im Januar 2024 die nächste Benachrichtigung gesendet werden, so muss die Ableitung für 2023-12 erzeugt werden und darauf basierend anschließend die Ableitung für 2024-01. Anschließend werden die Ableitungs- und Schlüsseldaten für 2023-11` gelöscht. Die Schlüsseldaten für 2024-01 werden für die kryptographische Sicherung verwendet.

        +

        Sollte erst im Januar 2024 die nächste Benachrichtigung gesendet werden, so muss die Ableitung für 2023-12 erzeugt werden und darauf basierend anschließend die Ableitung für 2024-01. Anschließend werden die Ableitungs- und Schlüsseldaten für 2023-11 gelöscht. Die Schlüsseldaten für 2024-01 werden für die kryptographische Sicherung verwendet.

        Somit erreicht man das Ziel, dass bei Kompromittierung eines AES/GCM-Jahr-Monat-Schlüssels nur die Benachrichtigungen der letzten zwei Monate entschlüsselt werden können.

        @@ -599,47 +615,47 @@

        Registrierung einer ePA-FdV-Instan

        -registration +registration
        -
        Abbildung 3. Registrierung einer FdV-Instanz für Push-Notifications im Fachdienst Status In Review orange
        +
        Abbildung 4. Registrierung einer FdV-Instanz für Push-Notifications im Fachdienst Status In Review orange
        1. -

          Die FdV-Instanz registriert sich beim Push Provider und erhält ein push_token, das die FdV-Instanz eindeutig identifiziert.

          +

          Die FdV-Instanz registriert sich beim Push Provider und erhält ein pushkey, das die FdV-Instanz eindeutig identifiziert.

        2. -

          Die FdV-Instanz erzeugt ein initial_shared_secret und speichert den Zeitpunkt (<Jahr>-<Monat>) zu welchem dieses erzeugt wurde als time_iss_created

          +

          Die FdV-Instanz erzeugt ein initial_shared_secret und speichert den Zeitpunkt (<Jahr>-<Monat>) zu welchem dieses erzeugt wurde als time_iss_created

        3. -

          Der Nutzer meldet sich beim Fachdienst (z.B. Aktensystem) an und registriert einen Pusher. Teil der Registrierungsdaten sind: {

          +

          Der Nutzer meldet sich beim Fachdienst (z.B. Aktensystem) an und registriert einen Pusher. Teil der Registrierungsdaten sind:

          • -

            das push_token,

            +

            der pushkey,

          • -

            die app_id,

            +

            die app_id,

          • -

            die Art des Pushers (normalerweise "http"),

            +

            die Art des Pushers (kind, hier immer "http"),

          • -

            die Adresse des Push Gateways

            +

            die Adresse des Push Gateways (data.url)

          • -

            das initial_shared_secret

            +

            das initial_shared_secret

          • -

            time_iss_created
            +

            time_iss_created

            -Die genauen Felder und Erklärungen dazu sind auf der OpenAPI-Seite zu finden. Die app_id und die Adresse des Push Gateways wurden vom Hersteller im FdV hinterlegt.

            +Die genauen Felder und Erklärungen dazu sind auf der OpenAPI-Seite zu finden. Die app_id und die Adresse des Push Gateways wurden vom Hersteller im FdV hinterlegt.

        4. -

          Die FdV-Instanz und der Fachdienst erzeugen den ersten Schlüssel aus dem initial_shared_secret und dem time_iss_created. Anschließend löschen sie das initial_shared_secret.

          +

          Die FdV-Instanz und der Fachdienst erzeugen den ersten Schlüssel aus dem initial_shared_secret und dem time_iss_created. Anschließend löschen sie das initial_shared_secret.

        @@ -667,13 +683,13 @@

        Registrierung einer ePA-FdV-Instan

        Deregistrierung einer FdV-Instanz Status Draft red

        -

        Der gleiche Endpunkt wird sowohl zur Deregistrierung als auch zur Registrierung bei einer FdV-Instanz verwendet. Bei der Deregistrierung werden nur das push_token, die app_id und die Art des Pushers benötigt. Die Art des Pushers muss dann null sein, damit der Fachdienst weiß, dass der Pusher gelöscht werden soll.

        +

        Der gleiche Endpunkt wird sowohl zur Deregistrierung als auch zur Registrierung bei einer FdV-Instanz verwendet. Bei der Deregistrierung werden nur das pushkey, die app_id und kind (die Art des Pushers benötigt). Die Art des Pushers muss dann null sein, damit der Fachdienst weiß, dass der Pusher gelöscht werden soll.

        Liste aktuelle Pushers enthalten Status Draft red

        -

        Die FdV-Instanz kann eine Liste aller registrierten Pusher durch eine GET Operation auf dem bestimmten Endpunkt des Fachdienstes erhalten. Die Details dazu sind auf der OpenAPI-Seite beschrieben.

        +

        Die FdV-Instanz kann eine Liste aller registrierten Pusher des Nutzers durch eine GET Operation auf dem bestimmten Endpunkt des Fachdienstes erhalten. Die Details dazu sind auf der OpenAPI-Seite beschrieben.

        @@ -683,9 +699,9 @@

        Versenden von Push-Notifications
        -send push +send push
        -
        Abbildung 4. Push-Notification-Versand
        +
        Abbildung 5. Push-Notification-Versand
          @@ -707,7 +723,7 @@

          Versenden von Push-Notifications
          1. -

            ciphertext = Nachrichteninhalt aus 1b, verschlüsselt mit dem aktuell gültigen Schlüssel.

            +

            ciphertext = Nachrichteninhalt aus 1a, Base64(IV || Chiffrat || Authentication Tag) verschlüsselt mit dem aktuell gültigen Schlüssel.

          2. time_message_encrypted = Zeitpunkt der Verschlüsselung des Nachrichteinhaltes.

            @@ -735,6 +751,102 @@

            Versenden von Push-Notifications

        +
        +

        Versenden aus Push Gateway Sicht Status Work In Progress red

        +
        +
        Apple
        + +++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

        HTTP-Header

        Wert

        Beschreibung

        :method

        POST

        :path

        /3/device/<pushkey>

        authorization

        <provider_token>

        Required for token-based authentication

        apns-push-type

        alert

        apns-id

        apns-expiration

        apns-priority

        <prio != high ? 5 : 10>

        apns-topic

        apns-collapse-id

        +
        +
        +

        +
        +

        Themen für produktspezifische Implementierungen

        +
        +

        Die folgenden Themen sind in diesem Dokument nicht enthalten, da sie zu stark von der produktspezifischen Implementierung abhängen:

        +
        +
        +
          +
        1. +

          Lokalisierung: Die genaue Implementierung der Lokalisierung ist stark abhängig vom Payload und damit vom spezifischen Anwendungsfall.

          +
          2. +
        2. +

          Channels: Die Anforderungen und Implementierung von Channels sind anwendungsfallspezifisch und können je nach Produkt variieren.

          +
          3. +
        3. +

          Payload: Die genaue Struktur und der Inhalt der Nutzdaten können je nach Anwendungsfall und Produktfunktionalität unterschiedlich sein.

          +
          4. +
        4. +

          Implementierung des Push Gateways: Die technische Umsetzung des Push-Mechanismus kann von der gewählten Infrastruktur und den spezifischen Anforderungen des Produkts abhängen. Die Technologie entwickelt sich schnell weiter, was auch die Kommunikation zwischen Push Gateway und Push Providers beeinflusst.

          +
          5. +
        5. +

          Berechtigung: Die Berechtigungen für die verschiedenen Endpunkte sind anwendungsfallspezifisch und können je nach Produkt variieren.

          +
          6. +
        +
        +
        +

        Für Hinweise zur Implementierung dieser Themen verweisen wir auf die produktspezifischen Spezifikationen und Implementierungsleitfäden.

        +
        +
        +

        Optionale Features können hier gefunden werden.

        +

        @@ -742,14 +854,104 @@

        Versenden von Push-Notifications Beispiele Status Draft red

        +

        Device Registrierung

        +
        +
        Variante 1, Platform via app_id
        +
        +
        {
+    "lang": "en",
+    "kind": "http",
+    "app_display_name": "Mat Rix",
+    "device_display_name": "iPhone 9",
+    "app_id": "com.example.app.ios",
+    "pushkey": "<APNS/GCM TOKEN>",
+    "data": {
+        "url": "https://push-gateway.location.here/_matrix/push/v1/notify"
+    },
+    "append": false
+}
        +
        +
        +
        +
        Variante 2, Platform via data
        +
        +
        {
+    "lang": "en",
+    "kind": "http",
+    "app_display_name": "Mat Rix",
+    "device_display_name": "iPhone 9",
+    "app_id": "com.example.app",
+    "pushkey": "<APNS/GCM TOKEN>",
+    "data": {
+        "url": "https://push-gateway.location.here/_matrix/push/v1/notify",
+        "platform": "ios"
+    },
+    "append": false
+}
        +
        +
        +
        +
        Variante 2, Platform via url
        +
        +
        {
+    "lang": "en",
+    "kind": "http",
+    "app_display_name": "Mat Rix",
+    "device_display_name": "iPhone 9",
+    "app_id": "com.example.app",
+    "pushkey": "<APNS/GCM TOKEN>",
+    "data": {
+        "url": "https://push-gateway.location.here/ios/_matrix/push/v1/notify"
+    },
+    "append": false
+}
        +
        +
        +
        +

        Event-Trigger

        Beispiel für ein Event-Trigger in ePA:

        -
        {
-    "trigger": "T001"
+
        function trigger001() {
+    user = getUser()
+    devices = getDevices(user)
+    channel = getChannel(trigger001)
+
+    for device in devices {
+        if device.channels[channel].isSubscribed {
+            notification = createNotification(trigger001, device)
+            sendNotification(notification, channel)
+        }
+    }
+}
+
+function createNotification(trigger, device) {
+    month = date.now().month // "2024-11"
+    encryptionKey = getEncryptionKey(device, month)
+
+    payload = {
+        event: "trigger001"
+    }
+
+    iv = random(32)
+    (cipher, authTag) = aesEncrypt(payload)
+
+    ciphertext = Base64(iv + cipher + authTag)
+
+    return {
+        month: month,
+        ciphertext: ciphertext,
+        devices: [
+            app_id: device.app_id,
+            pushkey: device.pushkey,
+            pushkey_ts: device.pushkey_ts,
+            data: device.data,
+            tweaks: {}
+        ]
+    }
 }
        @@ -763,25 +965,62 @@

        Push Gateway

        IN
        + +++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

        HTTP-Header

        Wert

        Beschreibung

        :method

        POST

        :path

        /3/device/<pushkey>

        authorization

        <provider_token>

        Required for token-based authentication

        apns-push-type

        alert

        apns-priority

        <prio != high ? 5 : 10>

        Push Gateway payload received
        "notification": {
     "month": "2024-11",
     "ciphertext": "asdfdfjksfjklsdljkdsf==",
-    "mac": "string",
     "prio": "high",
     "counts": {},
     "devices": [
         {
-            "app_id": "string",
-            "pushkey": "string",
+            "app_id": "de.gematikkk.app.ios",
+            "pushkey": "abcd-efghi-jklm-nopq",
             "pushkey_ts": 0,
             "data": {
-            "format": "string"
+                "format": "string"
             },
             "tweaks": {
-                "badge": 0
             }
         }
     ]
@@ -796,25 +1035,19 @@ 
        OUT
        
 
        
 
        Payload:
 {
-    type: alert,
-    mutable-content: true,
-    payload: {
-        ciphertext: notification.ciphertext,
-        month: notification.month,
-        sound: "default",
-        category: "message",
-        data: {
-            message: "Hallo Welt"
-        }
+    "aps": {
+        "mutable-content": true
     }
+    "ciphertext": notification.ciphertext,
+    "month": notification.month
 }
        Push Gateway pseudo code
        -
        if tweaks.badge > 0 then
-    payload.payload.badge = tweaks.badge
+
        if notification.counts.badge then
+    payload.aps.badge = notification.counts.badge
 end if
        @@ -847,6 +1080,9 @@
        OUT
        }
        +
        +

        Sync: 22.11.2024 14:56

        +
        @@ -855,7 +1091,7 @@
        OUT
        diff --git a/fd_openapi.html b/fd_openapi.html index fed58da..83c848f 100644 --- a/fd_openapi.html +++ b/fd_openapi.html @@ -244,6 +244,9 @@ data-styled.g61[id="sc-gcfzXs"]{content:"dnQByT,"}/*!sc*/ .feFoaC{color:#d41f1c;font-size:0.9em;font-weight:normal;margin-left:20px;line-height:1;}/*!sc*/ data-styled.g62[id="sc-hGZxvd"]{content:"feFoaC,"}/*!sc*/ +.YZnqP{border-radius:2px;word-break:break-word;background-color:rgba(51,51,51,0.05);color:rgba(51,51,51,0.9);padding:0 5px;border:1px solid rgba(51,51,51,0.1);font-family:Courier,monospace;}/*!sc*/ ++{margin-left:0;}/*!sc*/ +data-styled.g66[id="sc-cSzYSJ"]{content:"YZnqP,"}/*!sc*/ .dIXVzO:after{content:' and ';font-weight:normal;}/*!sc*/ .dIXVzO:last-child:after{content:none;}/*!sc*/ .dIXVzO a{text-decoration:auto;color:#32329f;}/*!sc*/ @@ -380,7 +383,7 @@ -
        API docs by Redocly
        API docs by Redocly

        Client-FD Push API (1.0.0)

        Download OpenAPI specification:Download

        License: Apache 2.0

        Fachdienst

        Gets the current pushers for the authenticated user

        Client-FD Push API (1.0.0)

        Download OpenAPI specification:Download

        License: Apache 2.0

        Setup

        Gets the current pushers for the authenticated user

        Gets all currently active pushers for the authenticated user.

        Authorizations:
        bearerAuth

        Responses

        Response samples

        Content type
        application/json
        {
        • "pushers": [
          ]
        }

        Modify a pusher for this user on the homeserver.

        Response samples

        Content type
        application/json
        {
        • "pushers": [
          ]
        }

        Modify a pusher for this user on the homeserver.

        One or more of the pusher values were invalid.

        Request samples

        Content type
        application/json
        Example
        {}

        Response samples

        Content type
        application/json
        { }
        +

        Request samples

        Content type
        application/json
        Example
        {}

        Response samples

        Content type
        application/json
        { }

        Fachdienst

        Gets channels for a specific device.

        Gets all channels and there configuration state of the users device identified by the pushtoken.

        +
        Authorizations:
        bearerAuth
        path Parameters
        pushtoken
        required
        string
        Example: 1234567890

        The pushtoken of the device.

        +
        Request Body schema: application/json
        Array of objects (channels)

        An array containing channels

        +

        Responses

        Request samples

        Content type
        application/json
        {
        • "channels": [
          ]
        }

        Response samples

        Content type
        application/json
        { }

        Modify the channels for a specific device.

        This endpoint allows the creation, modification and deletion of channel subscriptions +for a specific device identified by pushtoken.

        +
        Authorizations:
        bearerAuth
        path Parameters
        pushtoken
        required
        string
        Example: 1234567890

        The pushtoken of the device.

        +
        Request Body schema: application/json
        required

        The channel information.

        +
        Array of objects (channels)

        An array containing channels

        +

        Responses

        Request samples

        Content type
        application/json
        Example
        null

        Response samples

        Content type
        application/json
        { }

        Gets the available channels for the authenticated user

        Gets all all active channels for the authenticated user.

        +
        Authorizations:
        bearerAuth
        Request Body schema: application/json
        Array of objects (channels)

        An array containing channels

        +

        Responses

        Request samples

        Content type
        application/json
        {
        • "channels": [
          ]
        }

        Response samples

        Content type
        application/json
        { }