App-Anfragen auf Websites

Optionen für App-Anfragen auf Ihrer Website

Unsere Apps können Websites in einer sogenannten Web View innerhalb Ihrer App anfordern und darstellen (im Grunde eine Browser-Engine innerhalb der nativen App). Während der URL-Anfrage kann sich die App gegenüber dem Webserver als Client identifizieren, sodass der Webserver die bereitgestellte Website eventuell anpasst oder Ihre Tracking-Tools den App-Traffic identifizieren können.

Option 1: User Agent

Es gibt bereits einen Industriestandard für die Geräteidentifikation, den wir nutzen. Es ist der User-Agent-String. Der User-Agent-String ist ein Feld im HTTP-Header, das die App identifizieren kann, die die Anfrage stellt. Beim Surfen im Web wird der User Agent vom Browser (der ebenfalls eine App ist) festgelegt.

Nun wird anstelle eines Browsers unsere native App die HTTP-Anfrage stellen. Wir können benutzerdefinierte Informationen in diesen User-Agent aufnehmen, die dem Webservice helfen, die App zu identifizieren.

Zusätzlich ist es auch möglich, ein bestimmtes Feld des Benutzerprofils zur Anfrage hinzuzufügen, um eine Unterscheidung zwischen bestimmten Produkten, Abonnements oder Mitgliedschaften zu ermöglichen. Die bereitgestellten Informationen könnten beispielsweise so aussehen:

💡 USER_AGENT;role=director

Ihr Webservice kann dann ganz einfach den Zugriff auf bestimmte Inhalte so steuern, wie es auch im Web geschieht.

Option 2: Benutzerdefinierte URL

Wenn Sie ein eigenes Template einrichten und dieses in der App verwenden möchten, können Sie dieses auch auf ein benutzerdefiniertes URL-Schema legen. Dies ist in der Regel ein einfacher und sicherer Weg, dies in einem Web-CMS wie WordPress einzurichten.

So könnten Sie dieses benutzerdefinierte Template beispielsweise auf einer URL bereitstellen, die „/app“ nach Ihrer Domain anfügt, wie ihredomain.de/app/123 anstelle von ihredomain.de/123.

Das Gute daran: Einmal auf ein bestimmtes Schema geeinigt, kann die App dieses an alle Ihre Domains anhängen, die in einer Web View in der App geöffnet werden. Wenn Benutzer diese URL mit anderen teilen möchten, verwendet die App natürlich die Basis-URL ohne die Manipulation.

Option 3: Benutzerdaten

Für Apps, die einen Benutzer-Login enthalten, besteht auch die Möglichkeit, dedizierte Benutzerdaten bereitzustellen, falls der Benutzer eingeloggt ist. Dies ermöglicht es dem Webserver, Anpassungen basierend auf einem bestimmten Benutzertyp vorzunehmen, beispielsweise um Zugriff auf bestimmte Funktionen oder Inhaltstypen zu gewähren.

Wir können alle Benutzerdaten bereitstellen, die wir in unserer Benutzerverwaltung haben und die wir über SSO erhalten. Das kann oft eine spezifische ID sein, die Ihrer Benutzerverwaltung hilft, Clients (oder Gruppen von Clients) zu identifizieren.

Bestimmte Parameter können auch hinzugefügt werden, um die App basierend auf UTM-Parametern in Google Analytics ganz einfach als Client anzuzeigen. Die URL könnte dann so aussehen:

https://domain.com/articles/hello-word?utm_source=4.0.0&utm_medium=app&utm_campaign=reader

Als Alternative zur Verwendung des benutzerdefinierten Headers kann die App auch ein bestimmtes Cookie setzen, das bei der Identifizierung des Benutzers hilft (im Grunde wie im Browser). Die App kann jeden vorhandenen Wert oder jede Identifikation in den Cookie-Manager der App schreiben und auch definieren, auf welchen URLs dieser verwendet werden soll.

Option 4: Browser-Token via API

In einigen fortgeschrittenen Setups ist es möglich, ein Session-Cookie von Ihrem eigenen Backend über eine API zu übertragen und direkt in der WebView der App zu verwenden.

In diesem Fall identifiziert sich die App nicht nur selbst — sie übernimmt die aktive Browser-Sitzung des Benutzers, sodass die Webseite den Benutzer als eingeloggt erkennt, ohne dass ein zusätzlicher Login-Schritt erforderlich ist.

Wie es funktioniert:

1. Ihr Backend stellt eine API bereit, die sowohl Benutzerdaten als auch ein Browser-Session-Token (z. B. ein JWT oder ein Cookie-Äquivalent) zurückgibt.

2. Die tchop-App empfängt dieses Token über die API.

3. Das Token wird in die WebView injiziert, sodass die Webinhalte so geladen werden, als ob der Benutzer im Browser authentifiziert wäre.

Dieser Ansatz ermöglicht eine nahtlose Integration zwischen App und Website — erfordert aber auch:

• Einen benutzerdefinierten API-Endpunkt, der sowohl Benutzerdaten als auch das gültige Browser-Token bereitstellt.

• Sorgfältige Sicherheitsvorkehrungen, da das Token verschlüsselt, kurzlebig und auf die Domain beschränkt sein muss.

Diese Option ist ideal für anspruchsvolle Enterprise-Setups, bei denen Sie ein völlig einheitliches Web- und App-Login-Erlebnis wünschen.

Wie man es einrichtet

Die Einrichtung ist recht einfach und umfasst folgende Schritte:

Optionen besprechen und definieren:

• Informationen im User Agent definieren - Der User Agent kann eine beliebige Textzeichenfolge sein

• Benutzerdaten definieren - Benutzerdaten können eine beliebige eindeutige Kennung sein (ID oder sogar E-Mail)

• Zu setzendes Cookie definieren (falls dies anstelle des Headers verwendet wird)

Implementieren:

• User Agent und Benutzerdaten zur App-Anfrage hinzufügen oder der App erlauben, Cookies zu setzen (wird von uns über ein App-Update durchgeführt, ist aber nur eine Einstellung auf unserer Plattform)

• Logik zu Ihrem Webservice hinzufügen (muss von Ihnen durchgeführt werden, je nachdem, was Sie erreichen wollen, was machbar ist usw.)

Testen

• Bereitstellen und testen - wir stellen die aktualisierten Apps zur Verfügung, die dann einfach URLs anfordern können

Was wir damit machen können

Diese Logik kann für verschiedene Zwecke genutzt werden:

• Inhalte ohne Paywall an die App oder bestimmte Nutzer ausliefern

• den Header der mobilen Website ausblenden, um das Nutzererlebnis beim Konsumieren der Inhalte zu verbessern

• andere Modal-Overlays wie Cookie-Banner, Newsletter-Anzeigen oder andere Module ausblenden

• andere Arten von Website-Manipulationen hinzufügen, wie das Ausblenden von Anzeigen oder anderen Werbemodulen

Was machbar ist und wie schwierig es ist, hängt natürlich von Ihrem Web-Setup, Ihrem Server und Ihrer Benutzerverwaltung ab.

Wir besprechen gerne die Optionen und Möglichkeiten mit Ihnen!