Installez opolyx sur votre téléphone — et connectez-vous sans mot de passe
opolyx est désormais une véritable application installable, avec quatre façons d’entrer : lien magique, code par e-mail, Google ou Apple. Le code est celui qui fonctionne partout.
En clair
Vous pouvez ajouter opolyx à votre écran d’accueil et l’ouvrir comme n’importe quelle application : icône dédiée, sans barres de navigateur, directement dans le hall. Cela fonctionne aujourd’hui sur Android et iOS depuis le menu du navigateur, et c’est la même version que nous préparons pour les boutiques.
- elle s’ouvre en plein écran sur le hall, et non sur la page marketing ;
- elle garde son icône et son écran de lancement au lieu d’être un simple raccourci ;
- elle affiche une vraie page opolyx hors connexion, plutôt qu’une erreur du navigateur ;
- elle ne met jamais en cache le moindre élément d’une partie en cours : l’application installée est aussi à jour que le site.
La connexion propose maintenant quatre voies, et vous prenez celle qui convient à votre appareil :
| Méthode | Fonctionnement |
|---|---|
| Lien magique | un lien dans votre e-mail : une pression, sans mot de passe |
| Code par e-mail | un code de 8 caractères à saisir sur la page de connexion |
| le sélecteur de compte habituel | |
| Apple | y compris Hide My Email, derrière lequel nous ne voyons jamais rien |
Le code envoyé par e-mail est la voie qui fonctionne absolument partout — y compris dans une application encapsulée, où un lien s’ouvre dans un autre navigateur et ne peut pas restituer la session.
Pour les curieux techniques
Le service worker est volontairement étroit. C’est une liste d’autorisations et non un fourre-tout : les navigations passent d’abord par le réseau avec une page hors ligne en secours, les ressources statiques hachées sont servies en stale-while-revalidate, et tout le reste — base de données, serveur de jeu, temps réel, authentification, charges rendues côté serveur — est ignoré, si bien qu’il ne peut ni servir un plateau périmé ni casser une partie en cours.
// 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));
});Le morceau intéressant fut la version iOS encapsulée, où aucune méthode de connexion n’aboutissait alors que tous les navigateurs fonctionnaient. En cause : un réglage WebKit que l’outil d’empaquetage écrit à votre place. Avec les domaines liés à l’application activés, WebKit annule silencieusement toute navigation de premier niveau vers un hôte absent de la liste — et le premier saut d’un flux OAuth est précisément cela. Par ailleurs, Google refuse les webviews intégrés par politique, ce qu’aucune configuration ne corrige.
Le lien magique n’aurait de toute façon jamais pu aboutir là : il s’ouvre dans le navigateur système, dont le webview de l’application ne voit pas les cookies. C’est ce qui fait du code saisi la seule voie e-mail de même origine : elle se termine dans le webview qui l’a demandée.
Pour Google, la voie officielle consiste à exécuter le flux dans le navigateur système puis à restituer la session. Le pont construit l’URL d’autorisation délibérément sans PKCE, afin que le flux renvoie les jetons dans le fragment de rappel que la coque peut lire : un code d’autorisation ne serait échangeable que par le navigateur détenant le vérificateur, c’est-à-dire le mauvais.