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
Du kannst opolyx auf deinen 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 du offline bist, 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 du kannst den nehmen, der zu deinem Gerät passt:
| Methode | So funktioniert es |
|---|---|
| Magic Link | ein Link in deiner E-Mail – ein Tipp, kein Passwort |
| E-Mail-Code | ein 8-stelliger Code, den du auf der Anmeldeseite eintippst |
| die übliche Kontoauswahl | |
| Apple | einschließlich „E-Mail 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 dich 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.