Deep Links zuverlässig hosten: Cloudflare Pages für assetlinks.json & Co.

Die Einrichtung von Deep Links in mobilen Apps erfordert nicht nur eine korrekte Implementierung in der Anwendung selbst, sondern auch die Bereitstellung spezifischer Verifizierungsdateien auf einem Webserver. Doch wo und wie hostet man diese Dateien zuverlässig und ohne technische Einschränkungen? Dieser Leitfaden zeigt, wie Cloudflare Pages als Hosting-Lösung für assetlinks.json und apple-app-site-association dient – insbesondere in Kombination mit einer .dev-Domain.

Warum Cloudflare Pages die ideale Wahl ist

Für die korrekte Funktionsweise von Deep Links müssen zwei zentrale Dateien zugänglich sein: assetlinks.json für Android und apple-app-site-association für iOS. Diese Dateien unterliegen strengen technischen Anforderungen:

• HTTPS ohne Weiterleitungen: Android akzeptiert assetlinks.json nur, wenn die Anfrage direkt über HTTPS erfolgt – Weiterleitungen oder Protokollwechsel führen zur Ablehnung.
• Steuerbare Content-Type-Header: Die Datei apple-app-site-association besitzt keine Dateiendung. Der Webserver muss daher den MIME-Type application/json explizit zuweisen.
• Identische Domain: Beide Dateien müssen auf derselben Domain liegen, die in der App konfiguriert ist.

Cloudflare Pages erfüllt diese Bedingungen mit minimalem Aufwand. Durch die direkte Integration mit GitHub erfolgt der Deploy automatisch bei jedem Push – ideal für Entwickler, die auf manuelle Schritte verzichten möchten.

Die Vorzüge einer .dev-Domain

Die Top-Level-Domain (TLD) .dev bietet einen entscheidenden Vorteil: Sie ist in der HSTS-Preload-Liste von Chrome enthalten. Das bedeutet, dass der Browser jede HTTP-Anfrage automatisch auf HTTPS umleitet – noch bevor die Anfrage den Server erreicht. Diese Funktion spart nicht nur Konfiguration, sondern eliminiert auch potenzielle Sicherheitslücken.

Die Kosten für eine .dev-Domain liegen bei etwa 60 bis 80 Euro pro Jahr. Wer bereits Cloudflare für DNS oder Hosting nutzt, kann den Domain-Registrar direkt bei Cloudflare einrichten und somit die Verwaltung der Nameserver vereinfachen.

Projektstruktur und Konfiguration

Um die Verifizierungsdateien korrekt zu hosten, sollte das Projekt folgende Ordner- und Dateistruktur aufweisen:

meinedomain.dev/
├── .well-known/
│   ├── assetlinks.json
│   └── apple-app-site-association
├── signup.html
├── index.html
└── _headers

• Die Datei signup.html dient als Brücke zwischen dem Deep Link und dem App Store. Sie wurde bereits in vorherigen Teilen dieser Serie erstellt und kann direkt übernommen werden.
• Der Ordner .well-known ist der Standardpfad für Verifizierungsdateien und wird von Android und iOS automatisch erkannt.
• Die Datei _headers steuert die HTTP-Header für die Verifizierungsdateien und stellt sicher, dass der Content-Type korrekt gesetzt wird.

Die _headers-Datei: Präzision ist entscheidend

Die Datei _headers definiert die HTTP-Header für die Verifizierungsdateien. Ohne diese Konfiguration würde der Server den MIME-Type nicht automatisch zuweisen – insbesondere bei apple-app-site-association, das keine Dateiendung besitzt. Die korrekte Syntax lautet:

/.well-known/apple-app-site-association
  Content-Type: application/json

/.well-known/assetlinks.json
  Content-Type: application/json

Ein häufiger Fehler sind Leerzeichen oder falsche Einrückungen, die dazu führen, dass der Header ignoriert wird. Daher sollte die Datei sorgfältig geprüft werden, bevor sie deployed wird.

Inhalte der Verifizierungsdateien

Die Datei assetlinks.json für Android muss folgende Struktur aufweisen:

[
  {
    "relation": ["delegate_permission/common.handle_all_urls"],
    "target": {
      "namespace": "android_app",
      "package_name": "com.meineapp",
      "sha256_cert_fingerprints": [
        "AA:BB:CC:DD:EE:FF:..."
      ]
    }
  }
]

Wichtig ist die Angabe des Paketnamens (package_name) und des SHA-256-Fingerabdrucks des Signaturzertifikats der App. Dieser Fingerabdruck kann mit Tools wie keytool oder openssl ermittelt werden.

Die Datei apple-app-site-association für iOS hat folgende Struktur:

{
  "applinks": {
    "apps": [],
    "details": [
      {
        "appID": "TEAM_ID.com.meineapp",
        "paths": ["/signup", "/signup/*"]
      }
    ]
  }
}

Hier muss die appID im Format TEAM_ID.BundleIdentifier angegeben werden. Die Pfade definieren, welche URLs von der App geöffnet werden sollen.

Schritt-für-Schritt: Deploy auf Cloudflare Pages

Der Deploy der Verifizierungsdateien auf Cloudflare Pages erfolgt in wenigen Schritten:

1. Repository erstellen: Erstellen Sie ein GitHub-Repository mit der oben genannten Struktur und pushen Sie die Dateien.
2. Cloudflare Pages einrichten: Navigieren Sie zu Workers & Pages → Create → Pages → Connect to Git. Wählen Sie das Repository aus und lassen Sie die Build-Kommandos leer. Als Output-Verzeichnis geben Sie / an.
3. Domain zuweisen: Fügen Sie im Abschnitt Custom Domains Ihre .dev-Domain hinzu. Falls Sie den Domain-Registrar bei Cloudflare nutzen, wird das SSL-Zertifikat automatisch innerhalb weniger Minuten bereitgestellt.

Validierung: Ist alles korrekt eingerichtet?

Nach dem Deploy sollten die HTTP-Header der Verifizierungsdateien überprüft werden. Nutzen Sie dazu den Befehl:

curl -I 
curl -I 

Die Ausgabe sollte für beide Dateien den Header content-type: application/json enthalten. Fehlt dieser Header, überprüfen Sie die _headers-Datei auf Syntaxfehler oder falsche Einrückungen.

Für eine zusätzliche Validierung der Android-Konfiguration bietet Google ein offizielles Tool an, das die korrekte Einrichtung der assetlinks.json überprüft.

Fazit: Ein zuverlässiges Setup für Deep Links

Mit Cloudflare Pages und einer .dev-Domain steht eine robuste Lösung für das Hosting von Deep-Link-Verifizierungsdateien zur Verfügung. Die automatisierte Bereitstellung über GitHub, die HSTS-Unterstützung der .dev-Domain und die präzise Header-Kontrolle machen den Prozess effizient und weniger fehleranfällig.

Dieser Ansatz ist besonders für Entwickler geeignet, die Wert auf Automatisierung und Zuverlässigkeit legen. Die vorgestellte Projektstruktur kann als Vorlage für zukünftige Projekte dienen und lässt sich leicht an individuelle Anforderungen anpassen.