أرغب في القدرة على تغيير بريد المستخدم الإلكتروني تلقائيًا دون الحاجة إلى إرسال بريد تأكيد، وذلك عبر استدعاء واجهة برمجة التطبيقات الخاصة بالمسؤول. أنا موافق على أن يكون هذا الإضافة مفتوح المصدر أو حتى دمجه في نواة Discourse كطلب سحب (إذا رغب المطور الرئيسي في إضافة مثل هذه الوظائف).
حالة الاستخدام الخاصة بي هي أنني أقوم بالتحقق من بريد المستخدم الإلكتروني باستخدام كودي الخاص، لذا لا حاجة لطلب تحقق آخر من Discourse.
لا تحتاج إلى ملحق؛ بل تحتاج إلى تعديل الكود الخاص بك لجعل واجهة برمجة التطبيقات (API) تفعل ما تريد.
بأي لغة كُتب كودك؟
هل لديك ميزانية؟
إذا كنت تتحقق من البريد الإلكتروني خارجيًا، فهل يعني ذلك SSO؟ إذا كان الأمر كذلك، فقم بتضمين أن البريد الإلكتروني قد تم التحقق منه بالفعل في الاستدعاء (callback).
بحسب علمي، لا يحتوي discourse على استدعاء API لتعديل بريد المستخدم الإلكتروني دون تأكيد. ومع ذلك، يوجد أمر shell للقيام بذلك، لكنه غير مناسب لظروفي.
لقد كتبت الـ API الخاص بي باستخدام PHP.
في الحقيقة، لا أعرف التكلفة المطلوبة. الكود مُطبّق بالفعل في النواة الأساسية كأمر shell. لست متأكدًا من التكلفة اللازمة لتقديمه عبر الـ API.
يدعم SSO بالفعل التحقق من البريد الإلكتروني الخارجي. على سبيل المثال، يتعامل مكون WordPress الإضافي مع ذلك بالفعل عندما يكون WordPress هو السلطة المسؤولة عن الهوية.
لا، لم أقم بتنفيذ SSO. لقد قمت فقط بالتحقق من بريد المستخدم الإلكتروني بوسائل أخرى وأحتاج إلى تغييره عبر استدعاء واجهة برمجة التطبيقات دون الحاجة إلى تأكيد إضافي.
هل يستحق 5 دولارات، أو 50 دولارًا، أو 500 دولار، أو 5000 دولار؟
ما هي لغة البرمجة التي كُتب بها كودك؟
هل يمكنك التراجع خطوتين للخلف ووصف ما تحاول تحقيقه؟
حسناً، ولكن لماذا لا يتم تطبيق مزوّد هوية/تسجيل دخول موحد؟
بهذه الطريقة، يختفي هذا المشكلة بالكامل.
أبحث عن شيء يتراوح بين 50 و500 
كما ذكرت، فإن واجهتي البرمجية (API) مكتوبة بلغة PHP.
لدي تطبيق، ورابط منتداي مع ملف المستخدم في تطبيقي. يمكن للمستخدمين تغيير بريدهم الإلكتروني داخل تطبيقي، وأريد تغيير بريد مستخدم Discourse تلقائيًا أيضًا.
عذرًا، لا أعرف ما هو مزوّد الهوية (IdP)، أما بالنسبة لتسجيل الدخول الموحد (SSO)، فبما أن لدي قاعدة مستخدمين كبيرة بالفعل، فإن تطبيق SSO لمنتدي Discourse سيؤدي إلى تعطيل حسابات المستخدمين الحاليين، وسيحتاجون إلى التحقق من هويتهم مرة أخرى. لا أحب ذلك. وستُحل مشكلتي بسهولة عبر القدرة على تغيير البريد الإلكتروني دون الحاجة إلى تأكيد، وذلك من خلال استدعاء واجهة برمجة التطبيقات (API).
أنت لا تعرف ما هو، ومع ذلك يمكنك الجزم بما سبق؟ هذا يثير الفضول.
آسف، لا ينبغي أن أكون متأكدًا جدًا لأن معرفتي بالموضوع محدودة، ولكن حسب فهمي، وفقًا للبيان التالي، يحتاج المستخدمون إلى التحقق من هويتهم لدى موفر SSO.
أقصد أنه إذا كان المستخدم مسجلاً في Discourse لكنه لم يسجل لدى موفر SSO، فعند تمكين SSO، سيتعين عليه التسجيل لدى موفر SSO. صحيح؟
ما الذي يمنعك من تصدير قائمة المستخدمين إلى نظام SSO الذي تنشره؟
لم توضح بعد كيفية التحقق حاليًا من عناوين البريد الإلكتروني أو لماذا يعتبر ما ذُكر أعلاه ضروريًا حقًا. قد توجد طريقة أبسط لتحقيق كل هذا إذا أجبت على بعض أسئلة جا.
لماذا لا تترك لـ Discourse التعامل مع عملية التحقق بدلاً من التحقق من البريد الإلكتروني خارجيًا ثم الاعتماد على الكود للتلاعب بقاعدة بيانات Discourse؟
هل يمكننا تصديرهم مع كلمات مرورهم؟ إذا كان الأمر كذلك، فأرجو إعلامي إن وجدت وثائق حول ذلك.
مثل نظام ديسكورش، أُرسل رابطًا عبر البريد الإلكتروني للتحقق من العنوان.
كنت أرغب في فعل ذلك. المشكلة هي أنني بحاجة إلى معرفة تأكيد البريد الإلكتروني فورًا. ومع ذلك، لم يكن لدي ديسكورش رابط ويب (webhook) للمستخدم لتغيير البريد الإلكتروني/اسم المستخدم.
إذن، لماذا لا تترك لـ Discourse التعامل مع SSO نيابةً عنك وتستفيد فقط من الهوية من Discourse؟ بهذه الطريقة لن تضطر أبدًا للقلق بشأن التحقق من البريد الإلكتروني مرة أخرى.
أنت تطلب حلاً مُتخيلًا دون أن تقدم لنا الصورة الكاملة هنا. هناك العديد من الأسباب الجيدة لعدم الرغبة في وجود وسيلة لتجاوز التحقق من البريد الإلكتروني. تشغيل أنظمة منفصلة سيؤدي ببساطة إلى خلق الكثير من العمل غير الضروري لاحقًا.
لأن Discourse لن يسمح لي باستخدام المصادقة عبر الهاتف. أحتاج إلى شيء قادر على التعامل مع التحقق والمصادقة عبر البريد الإلكتروني والهاتف في آن واحد.
حسناً، باختصار وبما أن صاحب الموضوع يعرف تماماً ما يحتاجه، سأتمكن من تقديم إضافة توفر استدعاءً لواجهة برمجة التطبيقات (API) لتغيير عنوان البريد الإلكتروني للمستخدم (دون إرسال بريد إلكتروني أو طلب أي نوع آخر من التنشيط) مقابل 200 دولار.
حسناً، هذا مقبول بالنسبة لي.
المستخدم الأصلي لم يمانع مشاركة الإضافة معكم جميعًا، لذا ها هي:
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.