المشكلتان 1 و 2 ناتجتان عن خيار تنفيذ متعمد من شركة أبل. لذا، لا يُعتبران حادثة تقنية بحتة، ويمكننا العمل على تجاوزهما. أما المشكلة 3 فتتعلق بمكتبة omniauth-apple، لذا يمكننا إصلاحها.
هذا السلوك صحيح؛ حيث تُرسل معلومات المستخدم فقط في كائن ASAuthorizationAppleIDCredential عند تسجيل المستخدم لأول مرة. أما عمليات تسجيل الدخول اللاحقة إلى تطبيقك باستخدام ميزة “تسجيل الدخول عبر أبل” باستخدام نفس الحساب، فلا تُشارك أي معلومات مستخدم، بل تُرجع فقط معرف المستخدم في كائن ASAuthorizationAppleIDCredential. يُوصى بتخزين كائن ASAuthorizationAppleIDCredential الأولي الذي يحتوي على معلومات المستخدم بشكل آمن حتى يتم التأكد من إنشاء الحساب بنجاح على خادمك.
ومع ذلك، أنا فضولي: هل رأى أحدكم مواقع ويب أخرى تستخدم ميزة “تسجيل الدخول عبر أبل”؟ أعتقد أنني رأيت فقط التطبيقات الأصلية تستخدمها
هذه الميزة تبدو منطقية للغاية بالنسبة لي، حيث يربط تطبيقنا على iOS بموقع discourse الإلكتروني، ولا يتطلب التطبيق أي متطلبات تسجيل دخول للميزات الأخرى.
إنه مريح جدًا للمستخدمين لتسجيل الدخول باستخدام هذه الطريقة، لأن معظمهم مسجلون بالفعل في الجهاز، وتستخدم Apple Pay للمشتريات داخل التطبيق نفس الحساب.
في رأيي، لا يزال من المنطقي الاتصال بفريق دعم مطوري آبل (DTS) بشأن هذا الأمر لمعرفة ما يقترحونه كحل بديل، ولتزويدهم أيضًا بتغذية راجعة مفادها أن هذا الأمر يتسبب في مشاكل. (للأسف، لا أملك المعرفة الكافية بهذا الشأن لإجراء هذا الحوار معهم بنفسي.)
إنه بعيد كل البعد عن الانتشار الواسع مثل جوجل أو فيسبوك وما إلى ذلك، لكنني رأيت استخدامه في عدة أماكن، مثل ebay.comوwordpress.comوkayak.com.
أعتقد أن كايك ووردبريس يخزنان معلومات المستخدم مؤقتًا من محاولة المصادقة الأولى، وفقًا لتوصيات أبل.
أظن أن هذا هو النهج الذي سنضطر إلى اعتماده، لكنه ليس قويًا بشكل خاص (على سبيل المثال: إذا انقطع الاتصال بالشبكة أثناء المحاولة الأولى، أو تم استعادة ديسكورس من نسخة احتياطية، أو غيّر المستخدم عنوان بريده الإلكتروني الخاص بأبل). ومن وجهة نظري، يعتبر هذا النهج أسوأ قليلاً من منظور الخصوصية (علينا تخزين عناوين البريد الإلكتروني للمستخدمين الذين لم يسجلوا حتى الآن!)
هل حدث أي تغيير متعلق بتسجيل الدخول عبر Apple مؤخرًا؟
بالتأكيد يمكننا جعله يعمل كما هو - سيتطلب ذلك بضعة أيام من التغلب على هذه المشكلات. لكننا سنظل عالقين في استقبال البريد الإلكتروني والاسم فقط عند أول تسجيل دخول على الإطلاق.
أعتقد أنهم قاموا بتحسينه قليلاً، لكنني لا أستطيع بسهولة العثور على أي تغييرات محددة.
أعتقد أن استلام البريد الإلكتروني مرة واحدة فقط ليس مشكلة كبيرة؟ أظن أننا بحاجة إلى اختبار ما يحدث عند تغيير بريدك الإلكتروني المرتبط بحساب Apple ID الخاص بك؟
قرأت هذا الموضوع 2-3 مرات لكنني لا أتذكر ما إذا كنتم قد حاولتم استخراج البريد الإلكتروني من رمز JWT المقدم.
هذا هو الطريقة التي أقوم بها في الكود الأصلي. لست متأكدًا مما إذا كانت واجهة الويب API تسمح بذلك.
في تسجيل الدخول الأول، يمكنك الحصول على البريد الإلكتروني مباشرة من ASAuthorizationAppleIDCredential.email.
أما في تسجيلات الدخول اللاحقة، فيمكن العثور على البريد الإلكتروني إذا قمت بفك تشفير بيانات JWT واستخراج حقل “email”.
بهذا يمكن تنفيذ الميزة، أليس كذلك؟
سيكون البريد الإلكتروني المقدم هو الذي اختاره المستخدم، سواء كان شخصيًا أو عشوائيًا.
أمر غريب جدًا، لأنني نجحت في تشغيله على النسخة الأصلية باستخدام خاصية البريد الإلكتروني في JWT فقط.
إذا لم يقوموا بتحديث النسخة على الويب لتكون مشابهة، فقد تكون الحل الوحيد هو توليد بريد إلكتروني وهمي تلقائيًا (مؤكد تلقائيًا) والسماح للمستخدم بتغييره لاحقًا إذا رغب في ذلك.
هذا يعني الاعتماد على المعرّف الذي توفره Apple، وهو ليس حلاً سيئًا جدًا، لكنه يثير بعض الشكوك قليلاً.
نحن نعلم أنه يمكننا جعل هذا يعمل. ما يصبح معقداً هو:
عنوان بريدك الإلكتروني لـ Apple ID هو jane.champion@somewhere.com
قمت بالتسجيل في Discourse باستخدام Apple
قمت بتغيير عنوان بريد Apple ID إلى jane.row@somewhere.com
قمت بتسجيل الدخول إلى Discourse … ما زلنا نعتقد أنك jane.champion@somewhere.com
ستبدأ إشعارات البريد الإلكتروني في Discourse في الارتداد إلى الأبد.
نحن غير واضحين بشأن الإجراء المتبع عند تغيير عناوين البريد الإلكتروني لـ Apple ID وكيف يمكننا الرد عليه إن أمكن.
رأيي في هذا الشأن هو أننا… نتعايش ببساطة مع هذه الحالة الحدية، وعلى الأقل يمكن للمستخدمين اختيار تغيير عناوين البريد الإلكتروني في Discourse لمثل هذه الحالات الحدية.
أود القول إن هذا بالتأكيد مرشح للإصدار مع Discourse. يجب أن نسعى لسحب الكود إلى النواة أو على الأقل تجميع الإضافة للإصدار الرئيسي التالي. (بالتأكيد ليس الإصدار الأسبوع القادم )