ثبّت opolyx على هاتفك — وسجّل الدخول بلا كلمة مرور
صارت opolyx تطبيقًا قابلًا للتثبيت فعلًا، وأمامك أربع طرق للدخول: رابط سحري، أو رمز بالبريد، أو Google، أو Apple. والرمز هو ما يعمل في كل مكان.
بكلمات بسيطة
يمكنك إضافة opolyx إلى شاشتك الرئيسية وفتحها كأي تطبيق آخر: أيقونة خاصة بها، بلا أشرطة متصفح، ومباشرةً إلى الردهة. هذا متاح اليوم على Android وiOS من قائمة المتصفح، وهو البناء نفسه الذي نحزمه لمتاجر التطبيقات.
- تفتح بملء الشاشة على الردهة لا على الصفحة التسويقية؛
- تحتفظ بأيقونتها وشاشة بدئها بدل اختصار متصفح؛
- تعرض صفحة opolyx لائقة حين تكون دون اتصال، بدلًا من خطأ المتصفح؛
- ولا تخزّن مؤقتًا أي شيء من مباراة جارية، فالتطبيق المثبَّت محدَّث تمامًا كالموقع.
لتسجيل الدخول الآن أربعة مسارات، ولك أن تستخدم ما يناسب جهازك:
| الطريقة | كيف تعمل |
|---|---|
| الرابط السحري | رابط في بريدك — نقرة واحدة، بلا كلمة مرور |
| رمز البريد | رمز من 8 خانات تكتبه في صفحة تسجيل الدخول |
| نافذة اختيار الحساب المعتادة | |
| Apple | بما في ذلك Hide My Email، فلا نرى ما وراءه أبدًا |
أما الرمز المُرسل بالبريد فهو المسار الذي يعمل في كل الأحوال — بما في ذلك داخل غلاف تطبيق، حيث يُفتح الرابط في متصفح منفصل لا يستطيع إعادة الجلسة.
للمهتمين بالتفاصيل التقنية
عامل الخدمة ضيّق النطاق عن قصد. فهو قائمة سماح لا قاعدة شاملة: عمليات التنقل تعتمد الشبكة أولًا مع صفحة دون اتصال كبديل، والأصول الثابتة المُبصَّمة تُخدَّم من الذاكرة مع تحديثها في الخلفية، وكل ما عداها — قاعدة البيانات وخادم اللعبة والاتصال الفوري والمصادقة والحمولات المُصيَّرة على الخادم — يُتجاوز كليًا، فلا يمكنه أبدًا تقديم لوحة قديمة أو تعطيل مباراة جارية.
// 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));
});أما الجزء المثير فكان بناء iOS المغلَّف، إذ لم يكتمل فيه أي أسلوب لتسجيل الدخول بينما كانت كل المتصفحات تعمل بلا مشكلة. والسبب إعداد في WebKit تكتبه أداة التغليف نيابةً عنك: فمع تفعيل النطاقات المقيَّدة بالتطبيق، يلغي WebKit بصمت أي تنقل على المستوى الأعلى إلى مضيف غير مدرج — والقفزة الأولى في تدفق OAuth هي بالضبط تنقل من هذا النوع. كما ترفض Google بشكل منفصل عروض الويب المضمّنة كسياسة، وهو ما لا يصلحه أي إعداد.
ولم يكن الرابط السحري ليعمل هناك أصلًا: فهو يُفتح في متصفح النظام، وجرة ملفات تعريف الارتباط الخاصة به لا يراها عرض الويب داخل التطبيق. ولهذا فإن كتابة رمز هي مسار البريد الوحيد ضمن الأصل نفسه — إذ يكتمل داخل عرض الويب الذي طلبه.
أما بالنسبة إلى Google فالمسار المعتمد هو تشغيل التدفق في متصفح النظام ثم إعادة الجلسة. ويبني الجسر رابط التفويض عمدًا بلا PKCE، فيُعيد التدفق الرموز في جزء العنوان الذي يمكن للغلاف قراءته — أما رمز التفويض فلن يستطيع استبداله إلا المتصفح الذي يحمل المُتحقِّق، وهو المتصفح الخطأ هنا.