opolyx aufs Handy – und ohne Passwort anmelden
opolyx ist jetzt eine richtige installierbare App, und es gibt vier Wege hinein: einen Magic Link, einen per E-Mail geschickten Code, Google oder Apple. Der Code ist der, der überall funktioniert.
Kurz gesagt
Sie können opolyx auf Ihren Startbildschirm legen und wie jede andere App öffnen: eigenes Symbol, keine Browserleisten, direkt in die Lobby. Das funktioniert heute schon auf Android und iOS über das Browsermenü, und es ist derselbe Build, den wir für die App-Stores verpacken.
- startet bildschirmfüllend in der Lobby statt auf der Marketingseite;
- behält ein eigenes Symbol und einen eigenen Startbildschirm statt einer Browserverknüpfung;
- zeigt eine richtige opolyx-Seite, wenn Sie offline sind, statt eines Browserfehlers;
- speichert nie etwas aus einer laufenden Partie zwischen, eine installierte App ist also genauso aktuell wie die Website.
Für die Anmeldung gibt es jetzt vier Wege, und Sie können den nehmen, der zu Ihrem Gerät passt:
| Methode | So funktioniert es |
|---|---|
| Magic Link | ein Link in Ihrer E-Mail – ein Fingertipp, kein Passwort |
| E-Mail-Code | ein 8-stelliger Code, den Sie auf der Anmeldeseite eintippen |
| die übliche Kontoauswahl | |
| Apple | einschließlich „E-Mail-Adresse verbergen“, hinter die wir nie sehen |
Der per E-Mail geschickte Code ist der Weg, der wirklich überall funktioniert – auch in einer App-Hülle, wo ein Link in einem separaten Browser aufgeht und die Sitzung nicht zurückreichen kann.
Für technisch Neugierige
Der Service Worker ist bewusst eng gefasst. Er ist eine Erlaubnisliste, kein Auffangnetz: Navigationen laufen zuerst über das Netz mit einer Offline-Seite als Rückfall, mit Hash versehene statische Dateien laufen als stale-while-revalidate, und alles andere – die Datenbank, der Spielserver, Realtime, die Anmeldung, serverseitig gerenderte Nutzdaten – wird komplett umgangen. Er kann also unmöglich ein veraltetes Brett ausliefern oder eine laufende Partie zerstören.
// public/sw.js — allow-list, not catch-all
self.addEventListener('fetch', (event) => {
const url = new URL(event.request.url);
if (url.origin !== self.location.origin) return; // Supabase, daemon: untouched
if (BYPASS.some((p) => url.pathname.startsWith(p))) return; // /auth, /api, RSC
if (event.request.mode === 'navigate') return event.respondWith(networkFirst(event));
if (HASHED.test(url.pathname)) return event.respondWith(staleWhileRevalidate(event));
});Der interessante Teil war der verpackte iOS-Build, in dem überhaupt keine Anmeldemethode zum Abschluss kam, während jeder Browser einwandfrei funktionierte. Ursache war eine WebKit-Einstellung, die das Verpackungswerkzeug für Sie schreibt: Sind app-gebundene Domains aktiviert, bricht WebKit stillschweigend jede Navigation auf oberster Ebene zu einem Host ab, der nicht auf der Liste steht – und der erste Sprung eines OAuth-Ablaufs ist genau so eine Navigation. Google lehnt eingebettete Webviews davon unabhängig aus Prinzip ab, was keine Konfiguration beheben kann.
Der Magic Link hätte dort ohnehin nie funktionieren können: Er öffnet sich im Systembrowser, dessen Cookie-Speicher der Webview der App nicht sehen kann. Genau deshalb ist ein eingetippter Code der einzige E-Mail-Weg auf derselben Herkunft – er wird in dem Webview abgeschlossen, der ihn angefordert hat.
Für Google ist der zugelassene Weg, den Ablauf im Systembrowser auszuführen und die Sitzung zurückzureichen. Die Brücke baut die Autorisierungs-URL bewusst ohne PKCE, sodass der Ablauf Tokens im Callback-Fragment zurückgibt, die die Hülle lesen kann – ein Autorisierungscode wäre nur von dem Browser einlösbar, der den Verifier hält, und das ist der falsche.