إضافة دعم مصادقة أكثر غنىً لبوب3

هذا رائع بالفعل، TLS هو أيضًا مطلب لـ Exchange Online. لكن لا يزال المصادقة تتم عبر المصادقة الأساسية (إذا فهمت الكود التالي بشكل صحيح، فلا توجد طريقة للاختيار بين أي آلية مصادقة أخرى مثل OAuth2) discourse/poll_mailbox.rb at tests-passed · discourse/discourse (github.com)

بتتبع الأمر أكثر قليلاً، يبدو أن مكتبة Class: Net::POP3 (Ruby 2.7.0) (ruby-doc.org) في Ruby لا تدعم مصادقة OAuth2، فقط المصادقة الأساسية.

للمرجع:

إنها تتوقع فقط اسم مستخدم وكلمة مرور، بدلاً من اسم مستخدم و رمز مميز، بالإضافة إلى أنها ستحتاج إلى استخدام تنسيق AUTH XOAUTH2 لتشفير وإرسال الرمز المميز.

آسف إذا لم أكن واضحًا في سؤالي، لكنني أسأل بشكل أساسي عن وجود نهج مشابه للأمثلة التالية:

ستسمح هذه الأساليب لـ Discourse بالاتصال بـ POP3 (وبالتالي IMAP) باستخدام مصادقة OAuth2، وبالتالي تلبية المتطلبات الخاصة بـ MS وربما لـ Gmail في المستقبل القريب إن لم يكن الآن ( OAuth 2.0 Mechanism | Gmail IMAP | Google Developers).

11 إعجابًا

أعتقد أن هذا طلب ميزة ممتاز وأنا أؤيد بشدة إضافة دعم OAuth2 إلى POP3.

لا يمكنني الالتزام بموعد بنائه، ولكن إذا ظهر طلب سحب (PR)، فسنعطي بالتأكيد الأولوية لمراجعته ودمجه.

10 إعجابات

رائع، شكراً جزيلاً! :clap:
أتطلع لرؤية هذه الميزة قريباً!

إعجاب واحد (1)

على حد علمي، قامت Google/Gmail بتعطيل مصادقة POP3 بخلاف OAuth في 30.5. لذلك، لم أعد أستطيع استرداد رسائل البريد الإلكتروني عبر POP3. سيكون رائعًا إذا كان Discourse يدعم OAuth2.

لم أتمكن من العثور على أي موضوع آخر بخلاف هذا. هل أنا الوحيد الذي يستخدم Gmail مع Discourse؟

إعجاب واحد (1)

لا يزال بإمكانك استخدام كلمة مرور التطبيق للمصادقة مع Gmail عبر POP3. إليك موضوع حديث ذو صلة:

4 إعجابات

فقط للمهتمين بالموضوع، هناك طلب سحب (PR) مفتوح من زميلنا @acosenza، نرحب بالملاحظات!

3 إعجابات

… ونهج بديل يعمل بكامل طاقته مقدم عبر مكون إضافي كما هو موضح في Microsoft Graph Mail Poller - plugin - Discourse Meta

آمل أن يثير هذا اهتمام المجتمع :tada: !

4 إعجابات

Bump لأن Google على وشك إيقاف حسابات Workspace أيضًا.

أرى أن طلب الدمج (PR) قد تم إغلاقه بسبب بعض مشكلات التبعية.
كلمات مرور التطبيقات لا تزال صالحة (في الوقت الحالي)، ولكن OAuth سيكون لطيفًا.

بريد إلكتروني من Google: ملخص - استخدم oauth2 بعد سبتمبر 2024

شعار Google Workspace

بدءًا من 30 سبتمبر 2024، ستسمح حسابات Google Workspace فقط بالوصول إلى التطبيقات التي تستخدم OAuth. لن يتم دعم الوصول المستند إلى كلمة المرور (باستثناء كلمات مرور التطبيقات) بعد الآن. بروتوكولات POP و IMAP لن تختفي ويمكن تمكينها مع التطبيقات التي تتصل باستخدام OAuth.

عزيزي المسؤول،

نكتب إليك لإعلامك بأنه كما شاركنا سابقًا في منشور المدونة هذا، سنقوم بإيقاف الوصول إلى التطبيقات الأقل أمانًا (LSA) - التطبيقات غير التابعة لـ Google التي يمكنها الوصول إلى حسابات Google باستخدام اسم مستخدم وكلمة مرور فقط (المصادقة الأساسية) - بدءًا من 15 يونيو 2024.

ما الذي تحتاج إلى معرفته؟

يجعل الوصول عبر المصادقة الأساسية الحسابات أكثر عرضة لمحاولات الاختطاق. للمضي قدمًا، ستتمكن فقط التطبيقات التي تدعم طريقة وصول أحدث وأكثر أمانًا تسمى OAuth من الوصول إلى حسابات Google Workspace.

سيتم إيقاف الوصول إلى التطبيقات الأقل أمانًا على مرحلتين:

  1. بدءًا من 15 يونيو 2024 - ستتم إزالة إعدادات التطبيقات الأقل أمانًا من لوحة تحكم المسؤول ولن يمكن تغييرها بعد ذلك. يمكن للمستخدمين المُمكّنين الاتصال بعد هذا التاريخ، ولكن لن يتمكن المستخدمون المعطلون من الوصول إلى التطبيقات الأقل أمانًا. يشمل ذلك جميع تطبيقات الطرف الثالث التي تتطلب الوصول بكلمة مرور فقط إلى Gmail، وتقويم Google، وجهات الاتصال عبر بروتوكولات مثل CalDAV، و CardDAV، و IMAP، و SMTP، و POP. ستتم إزالة إعدادات تمكين/تعطيل IMAP من إعدادات Gmail للمستخدمين. إذا كنت تستخدم التطبيقات الأقل أمانًا قبل هذا التاريخ، يمكنك الاستمرار في استخدامها حتى 30 سبتمبر 2024.
  2. بدءًا من 30 سبتمبر 2024 - سيتم إيقاف الوصول إلى التطبيقات الأقل أمانًا لجميع حسابات Google Workspace. لن تعمل بروتوكولات CalDAV و CardDAV و IMAP و POP عند تسجيل الدخول بكلمة مرور فقط - ستحتاج إلى تسجيل الدخول باستخدام نوع وصول أكثر أمانًا يسمى OAuth.

ما الذي تحتاج إلى القيام به؟

لكي يتمكن المستخدمون النهائيون لديك من الاستمرار في استخدام هذه الأنواع من التطبيقات مع حسابات Google Workspace الخاصة بهم، يجب عليهم التبديل إلى نوع وصول أكثر أمانًا يسمى OAuth (قائمة بالمستخدمين المتأثرين مرفقة). تسمح طريقة المصادقة هذه للتطبيقات بالوصول إلى الحسابات باستخدام مفتاح رقمي بدلاً من مطالبة المستخدم بالكشف عن اسم المستخدم وكلمة المرور الخاصة به. نوصي بأن تقوم بمشاركة تعليمات المستخدم (في ملف PDF هذا) مع الأفراد في مؤسستك لمساعدتهم على إجراء التغييرات اللازمة. بدلاً من ذلك، إذا كانت مؤسستك تستخدم أدوات مخصصة، يمكنك أن تطلب من مطور الأداة تحديثها لاستخدام OAuth. تعليمات المطور متاحة أيضًا في ملف PDF هذا.

تكوين MDM

إذا كانت مؤسستك تستخدم موفر إدارة الأجهزة المحمولة (MDM) لتكوين ملفات تعريف IMAP و CalDAV و CardDAV أو POP، فسيتم التخلص التدريجي من هذه الخدمات وفقًا للجدول الزمني أدناه:

  1. بدءًا من 15 يونيو 2024 - لن يعمل دفع MDM لـ IMAP و CalDAV و CardDAV و POP المستند إلى كلمة المرور للعملاء الذين يحاولون الاتصال لأول مرة. إذا كنت تستخدم Google MDM، فلن تتمكن من تشغيل إعدادات “تكوين الدفع المخصص” لـ CalDAV و CardDAV.
  2. بدءًا من 30 سبتمبر 2024 - لن يعمل دفع MDM لـ IMAP و CalDAV و CardDAV و POP المستند إلى كلمة المرور للمستخدمين الحاليين. سيحتاج المسؤولون إلى دفع حساب Google باستخدام موفر MDM الخاص بهم، والذي سيضيف حسابات Google الخاصة بهم مرة أخرى إلى أجهزة iOS باستخدام OAuth. إذا كنت تستخدم Google MDM، فإن “تكوين الدفع المخصص - CalDAV” و “تكوين الدفع المخصص - CardDAV” (مزيد من التفاصيل حول الإعدادات هنا) ستتوقف عن كونها فعالة.

تطبيقات أخرى أقل أمانًا

  • لأي تطبيق آخر أقل أمانًا، اطلب من مطور التطبيق الذي تستخدمه البدء في دعم OAuth.

الماسحات الضوئية والأجهزة الأخرى

بالنسبة للماسحات الضوئية أو الأجهزة الأخرى التي تستخدم بروتوكول نقل البريد البسيط (SMTP) أو التطبيقات الأقل أمانًا لإرسال رسائل البريد الإلكتروني، قم بتكوينها لاستخدام OAuth، أو استخدم طريقة بديلة، أو قم بتكوين كلمة مرور تطبيق لاستخدامها مع الجهاز. إذا قمت باستبدال جهازك، فابحث عن جهاز يرسل البريد الإلكتروني باستخدام OAuth.

إعجابَين (2)

نظرًا لأن طلب السحب (PR) محظور بواسطة طلب السحب upstream net-pop، فهل هناك أي حلول بديلة معروفة للحسابات المستضافة على GSuite؟

إعجاب واحد (1)

ربما يمكن لـ @team تزويدنا بتحديث حول خطط هذه الميزة؟

إعجاب واحد (1)

أولاً وقبل كل شيء، أود أن أشكر إسماعيل وزميلك أليسيو على العمل الشاق الذي قمتما به حتى الآن، خاصة فيما يتعلق بـ Add OAUTH2 support by AlessioC31 · Pull Request #16 · ruby/net-pop · GitHub.

نحن نخطط للعمل على هذا قبل الموعد النهائي الذي قدمته جوجل، ولا نريد أن نفقد استطلاع POP3 ونحن نتتبع الأمر داخليًا. من المخيب للآمال أن طلب الدمج الخاص بـ net-pop قد تم حظره.

نأمل أن نتوصل إلى حل، أرى أن شخصًا من ميتا قد نشر تعليقًا في طلب الدمج هذا، وسأفعل الشيء نفسه، ربما يمكننا تحقيق بعض التقدم في طلب الدمج هذا، وإلا فسيتعين علينا التوصل إلى حل بديل مثل “monkey-patching” لـ Net::POP3 في نواة discourse.

4 إعجابات

مرحباً، هل هناك أي تقدم في هذا الأمر؟ حيث أن الموعد النهائي لجوجل يقترب…

اكتشفنا أنه لا يوجد شيء يجب القيام به بعد. ستواصل Google دعم كلمات مرور التطبيقات وفقًا للمقالات التالية:

لذلك، الشيء الوحيد الذي يجب القيام به إذا كنت تستخدم SMPT/POP3 مع Discourse و Google هو التأكد من أنك تستخدم كلمة مرور تطبيق من Google.

5 إعجابات