Instala opolyx en tu móvil y entra sin contraseña
opolyx ya es una app instalable de verdad, y hay cuatro maneras de entrar: enlace mágico, código por correo, Google o Apple. El código es el que funciona en todas partes.
En palabras sencillas
Puedes añadir opolyx a tu pantalla de inicio y abrirlo como cualquier otra aplicación: icono propio, sin barras del navegador y directo al vestíbulo. Ya funciona en Android e iOS desde el menú del navegador, y es la misma versión que estamos empaquetando para las tiendas.
- se abre a pantalla completa en el vestíbulo, no en la página de marketing;
- conserva su icono y su pantalla de carga en lugar de ser un acceso directo;
- muestra una página de opolyx cuando estás sin conexión, en vez de un error del navegador;
- nunca guarda en caché nada de una partida en curso: la app instalada está tan actualizada como la web.
Ahora hay cuatro formas de iniciar sesión, y puedes usar la que mejor le venga a tu dispositivo:
| Método | Cómo funciona |
|---|---|
| Enlace mágico | un enlace en tu correo: un toque, sin contraseña |
| Código por correo | un código de 8 caracteres que escribes en la página de acceso |
| el selector de cuentas de siempre | |
| Apple | incluido Hide My Email, tras el cual nunca vemos nada |
El código enviado por correo es la vía que funciona absolutamente en todas partes, incluso dentro de una app envuelta, donde un enlace se abre en otro navegador y no puede devolver la sesión.
Para los más técnicos
El service worker es deliberadamente estrecho. Es una lista de permitidos, no un cajón de sastre: las navegaciones van primero a la red con una página offline de respaldo, los recursos estáticos con hash usan stale-while-revalidate y todo lo demás —base de datos, servidor de juego, tiempo real, autenticación, cargas renderizadas en servidor— se ignora por completo, así que no puede servir un tablero caducado ni romper una partida en curso.
// 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));
});Lo interesante fue la versión iOS envuelta, donde ningún método de acceso llegaba a completarse aunque en todos los navegadores funcionaba. La causa es un ajuste de WebKit que la herramienta de empaquetado escribe por ti: con los dominios acotados a la app activados, WebKit cancela en silencio cualquier navegación de nivel superior a un host que no esté en la lista, y el primer salto de un flujo OAuth es exactamente esa navegación. Google, por su parte, rechaza los webviews integrados por política, y eso ninguna configuración lo arregla.
El enlace mágico tampoco habría funcionado allí: se abre en el navegador del sistema, cuyo almacén de cookies el webview de la app no puede ver. Por eso escribir un código es la única vía por correo dentro del mismo origen: se completa en el webview que lo pidió.
Para Google, la vía admitida es ejecutar el flujo en el navegador del sistema y devolver la sesión. El puente construye la URL de autorización a propósito sin PKCE, de modo que el flujo devuelve los tokens en el fragmento de la callback, que la app sí puede leer: un código de autorización solo podría canjearlo el navegador que guarda el verificador, que es el que no toca.