هل ستكون خدمة ‘تسجيل الدخول عبر Apple’ طريقة تسجيل دخول مدعومة عندما تصبح متاحة للعامة في وقت لاحق من هذا العام؟
لم يُعيّن أحد له بعد، لكنني أظن أنه سيحدث إذا اكتسب زخماً. حتى لو لم نفعل ذلك بسرعة في جوهر discourse، أعتقد أنه من المرجح أن ينشئ شخص ما في المجتمع إضافة.
12 إعجابًا
رائع. لم أكن قد رأيت ذكره في أي مكان حتى الآن، لذا اعتقدت أنني سأثير الأمر!
يمكنني محاولة القيام بذلك، نظرًا لأنني قدمت للتو طلب دمج (PR) للملحق الخاص بـ Discord… فكم يمكن أن يكون الأمر صعبًا؟ 
كما أشعر بأنه من المهم دعم إدارة الهوية مع شركة تركز أكثر على الخصوصية من، ههه، شركات أخرى يمكن ذكرها.
13 إعجابًا
افعل ذلك @merefield!
بما أن هناك استراتيجية omniauth-apple موجودة بالفعل، فيجب أن يكون ذلك ممكنًا GitHub - nhosoya/omniauth-apple: OmniAuth strategy for Sign In with Apple · GitHub
16 إعجابًا
مفيد جداً، شكرًا لك رافائيل
أصبحت الأمور قريبة جداً من الحل الآن، لكن واجهت عقبة:
تتطلب استراتيجية OAuth ملف مفتاح pem (الذي تحصل عليه من أولئك الأشخاص اللطفاء في Apple)
عندما أحاول تخزين هذا الملف في SiteSetting، يتم تشويه النص بطريقة ما، ويفشل توليد المفتاح الخاص:
::OpenSSL::PKey::EC.new(options.pem)
# OpenSSL::PKey::ECError
## invalid curve name
لقد حاولت استخدام \n لتحويل الأسطر الجديدة إلى أحرف هروب حيث توجد أسطر جديدة.
لا أستطيع رؤية كيفية إمكانية النشر ما لم نتمكن من تخزين محتويات هذا الملف في SiteSetting بطريقة ما؟
إعجاب واحد (1)
ملف .pem هو مجرد المفتاح العام، أليس كذلك؟
في هذه الحالة، يتضمن المفتاح الخاص (يبدو أن هناك عناصر أخرى مشفرة بداخله).
يتابع الكود استخدام هذا المفتاح الخاص لتوليد سر العميل.
لقد اختبرت المكتبة باستخدام ملف PEM، وهو صالح، ولكن بمجرد لصق الملف في إعداد موقع، يتغير بشكل خفي (وربما بشكل متوقع).
تحديث: يبدو أن \n يتم استبدالها بـ \\n في إعدادات الموقع، لذا قد يكون من الممكن البحث عن \\ عند الاسترجاع وتقليلها بمقدار واحد.
يبدو أنني تمكنت من التعامل مع الأمر، عذراً على الإزعاج.
7 إعجابات
تحديث:
يبدو أن إضافةي تعمل حتى نقطة معينة، ومع ذلك، أحصل حاليًا على رسالة خطأ غامضة من Apple عند محاولة المصادقة باستخدام بيانات الاعتماد التي قمت بإعدادها كمطور Apple:
“تعذر إكمال طلبك بسبب خطأ. يرجى المحاولة مرة أخرى لاحقًا”
وكما تتخيل، لا تقدم لي هذه الرسالة الكثير من التوجيه.
وتتفاقم المشكلة قليلاً لأن مخطط التفويض الخاص بهم يختلف كثيرًا عن معيار OAuth 2.0.
للأسف، لا يمكنني فتح تذكرة دعم كاملة (TSI) مع Apple بعد لأن الميزة ما زالت في مرحلة ما قبل الإصدار، لكنني سأقدم مشكلة عبر نظام Feedback.
المستودع موجود هنا:
ملاحظة: استخدمها على مسؤوليتك الخاصة - لم يتم اختبارها بنجاح بعد!
7 إعجابات
ربما نستخدم تحميل ملف لملف pem؟ ما حجمه؟
إنه صغير جدًا 
يبدو أن ملف ‘PEM’ (كسلسلة نصية في إعدادات الموقع) تتم معالجته بشكل صحيح، لذا لا يبدو أن هذه هي المشكلة بعد الآن.
لقد اختفى الخطأ الأصلي. ويبدو أن JWT يعالجه بشكل صحيح الآن.
لقد حللت المشكلة عن طريق استبدال أسطر جديدة بعلامة ، ثم استبدال علامة بأسطر جديدة عند تمريرها إلى دالة JWT. هذا غير قياسي، لكنه يعمل. فإدخال ‘/’ يسبب مشاكل بسبب طريقة تعامل Ruby معها. (أقرّ مع ذلك أنه رغم عدم رفع أي استثناء، فقد تظل هذه المنطقة مشكلة محتملة)
أنت مدعو تمامًا لاستخدام بيانات اعتماد Apple الخاصة بك وتجربتها.
أخشى أن يكون هناك خطأ ما في بيانات الاعتماد الخاصة بي.
تحتاج إلى توفير ما يلي:
- معرف الفريق (Team ID)
- معرف العميل (Client ID)
- ملف PEM
- معرف المفتاح (Key ID)
إن إعداد كل هذا على موقع Apple الإلكتروني أمر معقد جدًا
8 إعجابات
@merefield نجحت في تشغيله بنجاح على sandbox.dtaylor.uk 
كان علي إجراء بعض التغييرات في نسخة التفرع الخاصة بنا للسماح بالتحقق من النطاق. كما أضفت بعض الأوصاف الأكثر تحديدًا لإعدادات الموقع، وفعلت دعم الأسطر المتعددة لمفتاح PEM.
يبدو أن مكتبة omniauth-apple لا تدعم (بعد؟) تمرير أي معلومات حول المستخدم… وهو أمر غير مفيد بشكل خاص بالنسبة لنا. يبدو أن خدمة تسجيل الدخول باستخدام Apple متوافقة تقريبًا مع OpenID-Connect، لذا من الممكن أن نتمكن من إعادة استخدام بعض الوظائف من تلك الإضافة.
من حيث إعداد بيانات الاعتماد، وجدت أن هذه المدونة (التي تحمل اسمًا مناسبًا جدًا) أكثر فائدة من وثائق Apple:
11 إعجابًا
هذا رائع! آه، textarea جديد بالنسبة لي. لقد تجنب بشكل أنيق «الحيلة» التي أضفتها. مثالي! لو كنتُ قد عرفتُ ذلك من قبل! 
أعجبني فحص ملف txt الذي أضفته، لمسة لطيفة. لقد قمت بذلك يدويًا، لكن هذا يُعدّ مساعدة رائعة عند النشر.
نعم، استخدمتُ ذلك أيضًا.
للأسف، ما زلتُ أحصل على نفس الخطأ من جانب أبل بعد دمج نسختك المشتقة، لذا أظن أنني ما زلتُ أرتكب شيئًا سخيفًا فيما يتعلق ببيانات الاعتماد. قد أرسل لك رسالة خاصة إذا أمكن لتبادل الملاحظات!
7 إعجابات
حسنًا، اتضح أن مشكلتي كانت على الأرجح محاولة الوصول عبر موقع تطوير جزئي (يعمل عبر nginx ومعبرًا عبر HTTPS).
أعدت المحاولة مع موقع إنتاجي و:تادا:
لكن للأسف، وكما تقول، لا يتم إرجاع “الاسم”، ويجب أن يكون هذا هو الوسيط، أليس كذلك؟ يبدو أن هذا من Apple للسماح لك بالمصادقة على هذا.
هل نحن متأكدون من أنه سيعيد اسمًا؟ من منظور الخصوصية، يُعد اختيار المستخدم للاسم أفضل تقريبًا من الكشف عن أي معلومات تعريف شخصية عامة في هذه العملية.
من الناحية التقنية، يجب أن يفعل ذلك؟ لكنني أتفق مع نقطتك، رغم أنه يمكنك اختيار عدم عرضه في صفحة آبل. الأمر غير ذي جدوى، كما اتضح حتى الآن!
نعم، كان شخص ما قد أثار مشكلة بشأن هذا، لكنها أُغلقت لاحقًا.
أظن أن هذا هو منطقة الكود التي نهتم بها؟:
info do
{ sub: id_token['sub'] }
end
بينما في مكتبة مصادقة Discord، على سبيل المثال، نحصل على هذا:
info do
{
name: raw_info['username'],
email: raw_info['verified'] ? raw_info['email'] : nil,
image: "https://cdn.discordapp.com/avatars/#{raw_info['id']}/#{raw_info['avatar']}"
}
end
ملاحظة: لا يوجد ذكر لتلك الحقول في وثائق واجهة برمجة تطبيقات Apple…
يبدو أن هذا طلب السحب (PR) يضيف معلومات المستخدم المفيدة: Use JWT gem and some refactor by fjaeger · Pull Request #7 · nhosoya/omniauth-apple · GitHub. نأمل أن يتم دمجه قريبًا، أو إذا لم يحدث ذلك، يمكننا النظر في استخدام نسخة مُعدّلة.
5 إعجابات
نعم، أنت محق، لقد رأيت ذلك الطلب (PR) لكنني لم أغوص في الكود واعتقدت أنه مجرد تبديل لاعتماد مختلف. يجب على الناس التفكير في عدم تقديم طلبات بمثل هذا النطاق الواسع، إذ يمكن أن تضيع تفاصيل مثل هذه.
كما قلت:
{
sub: id_info['sub'],
email: user_info.dig('email'),
first_name: user_info.dig('name', 'firstName'),
last_name: user_info.dig('name', 'lastName'),
extra: {
raw_info: id_info.merge(user_info)
}
}
لقد أضفت تعليقًا لدعم هذا الطلب (PR).
4 إعجابات