Lorawan-stack: تقديم تطبيق حساب جديد (لاستبدال تطبيق oauth)

المراجع https://github.com/TheThingsIndustries/lorawan-stack/issues/1659

فيما يتعلق بمشكلة ارتباك تسجيل الدخول / تسجيل الخروج بالكامل بين وحدة التحكم وموفر oauth ، فإليك خطتي:

• نستخدم شعار Account منفصل لتطبيق الحساب (بدلاً من شعار TTS) ونستخدم نفس مكون الرأس الذي نستخدمه أيضًا لوحدة التحكم (ccpierreph)
• بدلاً من وجود شاشتين منفصلتين لتسجيل الدخول لوحدة التحكم وتطبيق الحساب ، يجب أن نربط التجربة ببعضها البعض ، بمعنى
  
  
  
  • سنقوم بإزالة شاشة تسجيل الدخول إلى وحدة التحكم /console/login
  
  
  • ستتم إعادة توجيه وحدة التحكم تلقائيًا إلى صفحة تسجيل الدخول إلى تطبيق الحساب /account/login ، عندما لا يكون لديها رمز وصول (صالح)
  
  
  • كما نفعل بالفعل مع زر تسجيل الدخول إلى وحدة التحكم ، سنستخدم معلمة استعلام إعادة التوجيه لإرسال المستخدم مرة أخرى إلى وحدة التحكم بعد تسجيل الدخول بنجاح
  
  
  • سيؤدي تسجيل الخروج من واجهة مستخدم وحدة التحكم إلى إزالة رمز الوصول المخزن ، وكذلك تسجيل الخروج من تطبيق الحساب. بهذه الطريقة ، سيتعين على المستخدمين دائمًا إعادة إدخال بيانات الاعتماد الخاصة بهم من أجل تسجيل الدخول مرة أخرى إلى وحدة التحكم.
    
    
    
    
    
    • لكي نتمكن من القيام بذلك ، نحتاج إلى طريقة لتشغيل عمليات تسجيل الخروج من الطلبات متعددة الأصول (نظرًا لعدم ضمان وجود وحدة التحكم وتطبيق الحساب على نفس الأصل)
    
    
    
    • في الإصدار 2 ، نستخدم مسارًا بسيطًا /users/logout والذي سيؤدي إلى تسجيل الخروج والذي يمكن الرجوع إليه من أي مكان
    
    
    
    • سيكون من الجيد البحث عن طرق لتحقيق نفس الشيء مع الحفاظ على أمان CSRF
    
    
    
  
  
  • سوف يشبه التدفق الجديد إلى حد كبير تدفق وحدة التحكم v2 ؛ سنضحي بشكل أساسي بفصل عميل وحدة التحكم وخادم التفويض لتحسين UX ، وهو أمر جيد لأن وحدة التحكم هي نوع من عميل حالة خاصة
  
  
  • قد نحتاج إلى مراجعة هذا التدفق إذا سمحنا بإجراءات تسجيل دخول مختلفة في المستقبل
  
  

إذا لم أسمع أي شكاوى حول هذه الخطة ، سأبدأ في تنفيذ ذلك.

تبدو وكأنها خطة رائعة. أوافق على أننا لسنا بحاجة إلى تسجيل خروج صريح من وحدة التحكم والاستمرار في تسجيل الدخول عبر OAuth في UX ، على الرغم من أنها ستعمل بهذه الطريقة أدناه.

ما الذي تحتاجه لتسجيل الخروج عبر الأصل؟ ألن يكون نهجًا بسيطًا من خطوتين ؛ "صفحة" تسجيل الخروج لإزالة رمز الوصول المخزن على وحدة التحكم ، ثم إعادة التوجيه إلى صفحة تسجيل الخروج العامة حيث يتم تسجيل خروج تطبيق الحساب؟ أو هل تريد هذا بدون إعادة توجيه ولكن النشر إلى نقطة نهاية تسجيل الخروج؟

لتسجيل الخروج ، يمكننا الحصول على بعض الإلهام من تسجيل الخروج OpenID Connect. يمكن العثور على ملخص لطيف هنا: https://medium.com/@robert.broeckelmann/openid -connect-logout-eccc73df758f

تبدو وكأنها خطة رائعة. أوافق على أننا لسنا بحاجة إلى تسجيل خروج صريح من وحدة التحكم والاستمرار في تسجيل الدخول عبر OAuth في UX ، على الرغم من أنها ستعمل بهذه الطريقة أدناه.

ما الذي تحتاجه لتسجيل الخروج عبر الأصل؟ ألن يكون نهجًا بسيطًا من خطوتين ؛ "صفحة" تسجيل الخروج لإزالة رمز الوصول المخزن على وحدة التحكم ، ثم إعادة التوجيه إلى صفحة تسجيل الخروج العامة حيث يتم تسجيل خروج تطبيق الحساب؟ أو هل تريد هذا بدون إعادة توجيه ولكن النشر إلى نقطة نهاية تسجيل الخروج؟

نهج من خطوتين على ما يرام. كان قلقي هو أن تسجيل الخروج من تطبيق الحساب يحتاج إلى تعطيل CSRF ، مما يعني أن أي شخص لديه رابط تسجيل الخروج يمكنه إغراء شخص ما بتسجيل الخروج من حسابه. هذا ممكن أيضًا حاليًا مع مكدس v2 ( سيؤدي النقر هنا إلى تسجيل خروجك ).
أعتقد أن هذا مقبول الآن ولكنه ليس أفضل الممارسات بالضبط.

لقد قمت ببعض العمل الآن لتطبيق الحساب الجديد:

• المكونات والحاويات المعاد تشكيلها التي يمكن استخدامها بواسطة وحدة التحكم وتطبيق الحساب
• تم تنفيذ تصميمات جديدة (بما في ذلك الاستجابة)
• تم تنفيذ إعدادات الملف الشخصي ، بما في ذلك صورة الملف الشخصي
• إدارة التراخيص المنفذة (العرض والإلغاء)
• تم تنفيذ إدارة الجلسات (العرض والإلغاء)
• حل مشكلة نتج عنها عرض فارغ عند استخدام تبعيات وحدة css النمطية المشتركة

لقد فعلت ذلك عن طريق ترميز رمز وصول ثابتًا ، حتى أتمكن من استخدام واجهة برمجة تطبيقات المكدس. لا يمكنني حاليًا التقدم في التنفيذ المناسب ، لأنني لا أعرف أفضل طريقة للحصول على رمز وصول لتطبيق الحساب.
في الوقت الحالي ، يعد "تطبيق oauth" مجرد منتجع صحي يتصل بنقاط نهاية المصادقة لخادم oauth (تسجيل الدخول والخروج ونقطة النهاية الأخرى ذات الصلة بالحساب والتي لا تحتاج إلى رمز وصول).
ذكرت htdvisser لي أن فكرتنا الأولية كانت أن يكون تطبيق الحساب كعميل oauth منفصل ، باستخدام نوع منح كلمة المرور. أعتقد أننا يجب أن نفتح مناقشة حول هذا ، حيث:

• اعتمادًا على المصدر ، لا يُنصح بنوع منح كلمة المرور ، حتى للعملاء "الرسميين" والموثوقين
• سيتطلب شاشة تسجيل دخول أخرى (بجانب شاشة تسجيل الدخول لمزود oauth)
• أتساءل عما إذا كانت هناك طريقة للحصول على رمز وصول من مزود oauth مباشرةً ، دون الحاجة إلى استخدام عميل منفصل آخر ، نظرًا لأننا نقوم بالفعل بالمصادقة داخل تطبيق oauth
• إذا استخدمنا منح كلمة المرور لتطبيق الحساب ، فيجب علينا استخدامها لوحدة التحكم أيضًا

لقد قلت بالفعل لـ htdvisser أن جانب المصادقة / التفويض بالكامل لهذا الأمر لأكون مسؤولاً عن مثل هذه المسألة الأمنية الحساسة.

ما يجب أن نهدف إليه هو التدفق الذي يجعل تدفق المصادقة لعملائنا الرسميين يبدو وكأنه مصادقة أصلية (انظر أيضًا تعليقي الآخر ) ، مما يعني أن عمليات تسجيل الدخول وتسجيلات الخروج عالمية ويجب ألا يكون هناك تمييز بين حالة المصادقة للعملاء و مزود التفويض.

لذلك ، سأحتاج إلى بعض المساعدة والمدخلات لمواصلة استخدام تطبيق الحساب. كيف يمكننا تنسيق هذا؟

اعتمادًا على المصدر ، لا يُنصح بنوع منح كلمة المرور ، حتى للعملاء "الرسميين" والموثوقين

نعم ، يجب عدم استخدام منحة كلمة المرور ، راجع المواصفات والاستدلال هنا: https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section -3.4

ممنوع حاليًا بواسطة # 2148

لذا بعد التورط في هذا لفترة من الوقت الآن ، أعتقد أنني بحاجة إلى بعض المدخلات.

كانت الفكرة الأصلية لتطبيق الحساب هي استبدال تطبيق oauth الحالي وتوسيع الوظائف نحو إدارة الملف الشخصي والجلسة (انظر OP). تكمن المشكلة في هذا في أنه من أجل تنفيذ هذه الوظيفة ، سيحتاج التطبيق إلى رمز وصول ، مما يعني بشكل أساسي أن تطبيق الحساب سيكون مزود OAuth والعميل.

كانت فكرتي هي تقديم عميل OAuth جديد ( account ) وواجهة أمامية ، لدمج الوظائف مع تطبيق OAuth الحالي. بالنسبة للمستخدم ، قد يبدو الأمر كما لو أن موفر OAuth (تسجيل الدخول ، التسجيل ، التحقق من صحة الحساب ، إلخ) وعميل تطبيق الحساب (إعدادات الملف الشخصي ، إدارة الجلسة ، إدارة التفويض) هما نفس التطبيق ، بينما في الخلفية ، هناك هو فصل تقني بين موفر OAuth والعميل. في الخلفية ، سيصبح عميل الحساب جزءًا من حزمة oauth . من ناحية الواجهة ، يمكننا أيضًا التعامل مع كلا الأمرين على أنهما نفس التطبيق ، باستخدام نفس نقطة الدخول ( account.js ).
وبالمثل ، فإن التوجيه سيعكس هذا المزج ، على سبيل المثال:

• /account/login لتسجيل الدخول إلى oauth [طبقة موفر OAuth]
• /account/register لتسجيل المستخدم [طبقة موفر OAuth]
• /account/forgot-password لتسجيل المستخدم [طبقة موفر OAuth]
• /account/client/login/ttn-stack لتسجيل دخول العميل (التفويض) [طبقة عميل OAuth]
• /account/client/oauth/callback لتبادل رمز المصادقة [طبقة عميل OAuth]
• /account صفحة نظرة عامة على عميل oauth [طبقة عميل OAuth]

بدلاً من ذلك ، يمكننا فصل كلتا الشاغلين ، وترك موفر OAuth ( /oauth عبر pkg/oauth ) كما هو ومعالجة تطبيق الحساب ( /account عبر pkg/account ) كشيء منفصل تمامًا ، كما نفعل مع وحدة التحكم. عندئذٍ سيكون موفر OAuth مسؤولاً فقط عن مسائل المصادقة ، بما في ذلك التفويض وتسجيل حساب المستخدم ، ولكن لن يكون لديه عرض مصدق خاص به كما هو الحال حاليًا. بدلاً من ذلك ، بعد تسجيل الدخول ، سيعيد التوجيه إلى تطبيق الحساب افتراضيًا ، والذي سيقوم بعد ذلك باسترداد رمز مميز تلقائيًا.

أشعر أن الحل الأول قد يتجنب بعض الالتباس الذي يدور حاليًا حول المصادقة وإدارة الحساب ، لكن لا يمكنني توقع ما إذا كان قد يؤدي إلى تعقيدات أخرى. يبدو الحل الثاني أنظف ، ولكن السؤال هو كيفية التواصل / العلامة التجارية للفصل. على سبيل المثال ، هل يجب إرسال كليهما على أنهما "تطبيق الحساب"؟ أم يجب أن تكون The Things Stack Single Sign On و The Things Stack Account Application ؟

أعلموني بآرائكم من فضلكم.

حسنًا ، بعد خطوة إلى الوراء ، ما الغرض من جعل تطبيق الحساب عميل OAuth؟ ما هي الوظائف عبر OAuth التي نريدها هناك؟

• إعدادات الملف الشخصي (الاسم والبريد الإلكتروني وصورة الملف الشخصي)
• إدارة الجلسة (مراجعة ، إبطال)
• إدارة التفويض (مراجعة ، إبطال)
• (من المحتمل أن تكون إعدادات التعريف الأخرى ذات الصلة بـ TTES في المستقبل)

كل هؤلاء يحتاجون إلى رمز وصول لأن هذه هي الطريقة الوحيدة لتفويض RPCs ذات الصلة.

نحتاج إلى فصل موفر OAuth - والذي يمكن أن يكون خارجيًا ، على سبيل المثال "The Things Network Community" - وإدارة المستخدم - والتي تتعلق بإدارة حقول كيان المستخدم المخزن في The Things Stack ، بما في ذلك النقاط kschiffer كتب في التعليق أعلاه.

لا تقبل نقاط النهاية /api/v3/* مصادقة ملفات تعريف الارتباط ، لأنها ممكّنة لـ CORS. إنهم يعملون فقط مع مفاتيح API ورموز الوصول.

• إعدادات الملف الشخصي (الاسم والبريد الإلكتروني وصورة الملف الشخصي)
• إدارة الجلسة (مراجعة ، إبطال)
• إدارة التفويض (مراجعة ، إبطال)
• (من المحتمل أن تكون إعدادات التعريف الأخرى ذات الصلة بـ TTES في المستقبل)

كل هؤلاء يحتاجون إلى رمز وصول لأن هذه هي الطريقة الوحيدة لتفويض RPCs ذات الصلة.

يمكننا أيضًا إنشاء هذا الجزء من وحدة التحكم ، لكن هذا يعني أن وحدة التحكم ستخلط المخاوف إلى حد ما. يمكنني رؤية المواقف التي يكون فيها من الأفضل أداء إدارة الحساب دون تحمل جميع وظائف وحدة التحكم الأخرى ، ولكن ربما يكون هذا أنا المبالغة في الهندسة 🤷‍♂️.

بشكل عام ، سيكون السؤال هو ما إذا كنا نريد رؤية وحدة التحكم فقط كأداة لإدارة الأمور المتعلقة بالشبكة. يمكننا إما فتحه ليكون نظامًا أساسيًا لإدارة الأغراض العامة لجميع الأمور المتعلقة بـ TTS أو يمكننا أن نكون أكثر ذرية ونلتزم بالفصل ونستخدم تطبيقات / عملاء مختلفين لمخاوف مختلفة. إنه سؤال استراتيجي. أرى حالات لكليهما.

لا أعتقد أن وحدة التحكم (جميع وحدات التحكم ، نظرًا لوجود وحدة تحكم في كل مجموعة) يجب أن تتمتع بحقوق كاملة للمستخدم. لا ينبغي استخدام وحدات التحكم لإدارة عملاء OAuth المصرح لهم ، والجلسات ، وعنوان البريد الإلكتروني الأساسي ، ومعلومات الاتصال. يعد امتلاك تطبيق مخصص لإدارة المستخدم (تطبيق الحساب) أفضل بكثير.

في الواقع ، نقطة جيدة. ثم يعود إلى السؤال الأول .

ما رأيي هو:

النهج المخلوط:

• من POV أقل إرباكًا للمستخدم (موقع واحد لجميع المسائل المتعلقة بالحساب)
• العلامة التجارية / التواصل أسهل
• يتوافق مع الخطة الأصلية لتطبيق الحساب
• من الناحية الأمامية ، لا نحتاج إلى نقطة دخول جديدة ومن ثم نمطي منفصل
• يصبح التنفيذ أكثر تعقيدًا / مربكًا (تطبيق الحساب هو مزود oauth والعميل)

نهج منفصل:

• تنفيذ أكثر نظافة وتقليدية
• التكوين أكثر مرونة وأوضح
• يقدم تطبيقًا جديدًا بجوار تطبيق oauth ، والذي يحتاج إلى علامة تجارية وتواصل معقول
• تعد عمليات الإنشاء (قد تكون هامشية ، ولم يتم اختبارها) والمزيد من الأصول

أميل نحو النهج الممزوج.

• إعدادات الملف الشخصي (الاسم والبريد الإلكتروني وصورة الملف الشخصي)
• إدارة الجلسة (مراجعة ، إبطال)
• إدارة التفويض (مراجعة ، إبطال)
• (من المحتمل أن تكون إعدادات التعريف الأخرى ذات الصلة بـ TTES في المستقبل)

هذا تطبيق حساب ، صحيح؟ ليس OAuth؟

• يقدم تطبيقًا جديدًا بجوار تطبيق oauth ، والذي يحتاج إلى علامة تجارية وتواصل معقول

ما هو تطبيق OAuth حتى الآن؟

هل يمكنك سرد ميزات المستخدم لما يضيفه عميل OAuth إلى تطبيق الحساب ، والتي لا يمكننا إنشاؤها في تطبيق الحساب ، ربما عبر نقاط نهاية جديدة؟

هذا تطبيق حساب ، صحيح؟ ليس OAuth؟

نعم ، هذا تطبيق حساب. لكن الخطة كانت أن ما لدينا حاليًا كتطبيق OAuth يصبح جزءًا من تطبيق الحساب.

ما هو تطبيق OAuth حتى الآن؟

للمصادقة (كجزء من تدفق OAuth) ، تسجيل المستخدم ، تفويض العميل ، إعادة تعيين كلمة المرور. في الأساس كل ما يتعلق بمصادقة المستخدمين وتفويض العملاء.

هل يمكنك سرد ميزات المستخدم لما يضيفه عميل OAuth إلى تطبيق الحساب ، والتي لا يمكننا إنشاؤها في تطبيق الحساب ، ربما عبر نقاط نهاية جديدة؟

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

هل تطبيق OAuth قائم بذاته؟ هل يتم تنفيذ عمليات إعادة التوجيه لعملاء OAuth؟ أم أنه عميل OAuth نفسه؟

التأكيد لي:

كانت فكرتي هي تقديم عميل OAuth جديد ( account ) وواجهة أمامية ، لدمج الوظائف مع تطبيق OAuth الحالي . بالنسبة للمستخدم ، قد يبدو الأمر كما لو أن موفر OAuth (تسجيل الدخول ، التسجيل ، التحقق من صحة الحساب ، إلخ) وعميل تطبيق الحساب (إعدادات الملف الشخصي ، إدارة الجلسة ، إدارة التفويض) هما نفس التطبيق ، بينما في الخلفية ، هناك هو فصل تقني بين موفر OAuth والعميل . في الخلفية ، سيصبح عميل الحساب جزءًا من حزمة oauth .

أنا أرى هنا.

• عميل OAuth
• تطبيق OAuth الحالي
• مزود OAuth
• عميل تطبيق الحساب
• موفر OAuth
• الزبون
• الخلفية
• عميل الحساب
• الحزمة oauth

أحاول فهم الاقتراح ، لكنني لا أفهم تمامًا ما الذي لا يزال.

إذن ما هي الميزات التي نريدها؟

1. إنشاء حساب
2. نسيت كلمة المرور
3. تسجيل الدخول
4. تغيير كلمة المرور
5. عرض وتحرير الملف الشخصي
6. إدارة الجلسات
7. عناصر OAuth
   
   
   
   1. شاشة الموافقة (تدفق رمز مصادقة OAuth)
   
   
   2. إدارة تراخيص OAuth
   
   

أعتقد أنه يمكن تنفيذ 1-6 دون لمس OAuth على الإطلاق ، إذا استخدمنا مصادقة الجلسة. هذا ممكن ، صحيح؟

نعم انا اسف. لدينا هنا عددًا من المصطلحات غير المثبتة التي تجعل من الصعب جدًا شرح الأشياء. على الأقل يعطي فكرة جيدة عن مدى تعقيد المشكلة.

لذلك دعونا نأخذ الوضع الراهن:

مزود OAuth
الكيان الذي يوفر التفويض (وفي حالتنا أيضًا المصادقة) وفقًا لمواصفات OAuth 2.0. في حالتنا هذه هي الحزمة pkg/oauth ، والتي بدورها تستخدم تطبيق OAuth (انظر أدناه) لتنفيذ واجهة المستخدم الضرورية للحصول على معلومات المستخدم (تقديم تسجيل الدخول ، التسجيل ، طرق عرض التفويض ، إلخ).

تطبيق OAuth
هذا هو تطبيق الويب التفاعلي الموجود على الواجهة الأمامية. يتكون كود الواجهة الأمامية الخاص بنا من تطبيق مختلف (بنقاط دخول مختلفة oauth.js / console.js ) والتي تشترك في أجزاء مشتركة مثل مكونات التفاعل والأدوات المساعدة

عميل OAuth
عميل مسجل يستخدم OAuth للمصادقة والتفويض ، مثل وحدة التحكم أو CLI.

حزمة oauth
حزمة Go المسؤولة عن تنفيذ موفر OAuth. هذا pkg/oauth .

لذلك كما ترى ، هناك ثلاث أو أربع طبقات مختلفة تعمل هنا. تكمن المشكلة في أننا إذا حافظنا على طريقة تفويضنا في الوقت الحالي ، فسنحتاج إلى شيء يلعب جميع الأدوار الموضحة أعلاه في نفس الوقت.

أعتقد أنه يمكن تنفيذ 1-6 دون لمس OAuth على الإطلاق ، إذا استخدمنا مصادقة الجلسة. هذا ممكن ، صحيح؟

نعم. 1-4 ممكن بالفعل بدون رمز oauth / الوصول. يحتاج 5 و 6 حاليًا إلى رمز وصول. 7. لم يتم تنفيذ ثانيا بعد. إذا كان من الممكن استخدام 5 و 6 بدون رمز الوصول ، فلن نحتاج بالفعل إلى عميل oauth آخر للقيام بذلك. ما زلنا بحاجة إلى اعتبار أن كل وظيفة قد نرغب في إضافتها إلى تطبيق الحساب في المستقبل يجب ألا تستخدم رمز الوصول كوسيلة تفويض وحيدة.

إذا كان من الممكن استخدام 5 و 6 بدون رمز الوصول ، فلن نحتاج بالفعل إلى عميل oauth آخر للقيام بذلك. ما زلنا بحاجة إلى اعتبار أن كل وظيفة قد نرغب في إضافتها إلى تطبيق الحساب في المستقبل يجب ألا تستخدم رمز الوصول كوسيلة تفويض وحيدة.

حق. هذا منطقي جدا بالنسبه لي. يعد هذا أيضًا أساسًا أفضل لـ "وضع sudo" ، حيث يمكن للمستخدمين القيام بأشياء _ فقط_ في تطبيق الحساب ، بعد إعادة إدخال كلمة المرور الخاصة بك على سبيل المثال. لذا ، نعم ، قد يكون هناك بعض التداخل بين ما يمكن أن يفعله عملاء OAuth وتطبيق الحساب ، لكن هذا التداخل لا يبدو كبيرًا بالنسبة لي. أرى قيمة في الاحتفاظ بالأشياء مخصصة لتطبيق الحساب.

حسنا يبدو جيدا.
htdvisser هل لديك أي اعتراضات؟ وإذا لم يكن الأمر كذلك ، فهل يمكنك توجيهي إلى الملفات / الحزم ذات الصلة للحصول على إذن ، لأنني أفترض أنه لن يكون لديك وقت للعمل على هذا في أي وقت قريبًا (؟).

كما علقت من قبل ، لا تقبل نقاط النهاية /api/v3/* مصادقة ملفات تعريف الارتباط ، لأنها ممكّنة لـ CORS. إذا كنت تريد البدء في قبول مصادقة ملفات تعريف الارتباط ، فستحتاج إلى إلقاء نظرة فاحصة على رؤوس CORS الخاصة بنا ، لأننا لا نريد حقًا أن يقوم المهاجم بتقديم طلبات عبر الأصل مصدقة من ملفات تعريف الارتباط لنقاط النهاية هذه.

واجهة برمجة التطبيقات الخاصة بنا عبارة عن gRPC ، ويتم المصادقة باستخدام رأس Authorization ، والذي يتم نشره إلى gRPC كبيانات وصفية للطلب. قد يبدو تنفيذ مصادقة الجلسة على النحو التالي:

• أضف نوع SessionToken إلى pkg/auth/auth.go
• أضف جزءًا سريًا إلى نموذج Session ، على غرار ما نفعله مع مفاتيح API ورموز الوصول.
• أضف برمجية وسيطة تستخرج معرّف الجلسة وسر الجلسة من ملف تعريف الارتباط ثم تعيد توجيهها إلى العنوان Authorization كـ SessionToken
• أضف SessionToken كـ case إلى switch tokenType { في pkg/identityserver/entity_access.go

شيء واحد يجب مراعاته هنا هو أن هذا يعني أيضًا أن تطبيق الحساب و v3 API يجب أن يتم تقديمهما من نفس الأصل. خلاف ذلك ، لن تعمل مصادقة ملفات تعريف الارتباط لأن سياق المصادقة يشتمل على أصول مختلفة.
لست متأكدا من مدى قبول ذلك. على الأقل من الناحية العملية ، يبدو أننا نستخدم نفس الأصول في عمليات النشر لدينا.

نعم ، سيكونون من نفس الأصل.

kschiffer يرجى إخبارنا كيف يمكننا إلغاء حظر التقدم هنا.

لقد كتبت ملخصًا هنا: https://github.com/TheThingsNetwork/lorawan-stack/pull/2850#issuecomment -657497193

حسنًا ، دعنا نواصل تلك المحادثة هنا.

kschiffer بعد العمل على هذا قليلاً:

• يتكون الجزء الأمامي من تطبيق oauth بشكل أساسي من شاشة التفويض فقط

نعم

• أعتقد أنه أمر مزعج للغاية الاحتفاظ بتكوينات is.oauth.ui.* الغرض فقط
  [...]
• أنا أيضًا غير متأكد قليلاً من القيود الدقيقة لكيفية تغيير تكوين المكدس دون كسر CC
• أنا محظوظ قليلاً لإيجاد حل قابل للتطبيق هنا وأحتاج حقًا إلى بعض المدخلات

لا يمكننا كسر التكوين في V3 ، ولكن يمكننا تقديم تكوين جديد ، وإيقاف التكوين القديم ، واستخدام التكوين القديم كبديل احتياطي ، وتقديم مشكلة TODO المسمى bump/major لإزالة التكوين القديم.

لذا فإن اقتراحي هو تقديم تكوين جديد من شأنه أن يكون بديلاً كاملاً ويمكّن تطبيق الحساب الجديد. للتوافق مع الإصدارات السابقة ، يجب أن يعمل دون أن يحدد المستخدم هذا التكوين الجديد ، أي الاعتماد على القيم الافتراضية المعقولة والتكوين القديم عبر is.oauth.ui.* .

kschiffer ما هو الوضع هنا؟

أعيد حاليًا تأسيس عملي على السقالة الجديدة ، والتي لا تزال جارية هنا: # 3453

التالي هو إعادة تأسيس ، وإصلاح ، والعلاقات العامة لطرق العرض المصدق عليها وتعديل التصميمات الحالية للعلامة التجارية الجديدة.

kschiffer ما هو الوضع هنا؟

تم تقديم تطبيق الحساب في 3.11. حاليا لا تزال مفقودة هي:

• تبديل الحساب # 488
• إدارة الجلسة
• إدارة التفويضات (يتضمن هذا أيضًا إضافة نقاط نهاية API)

موافق. يبدو أن https://github.com/TheThingsNetwork/lorawan-stack/issues/488 مغلق بالفعل.

لقد كانت هذه قضية كبيرة. هل يمكنك تقديم مشكلة أو مشكلتين جديدتين لما ورد أعلاه لتحل محل هذه المشكلة ، بحيث يمكن إغلاقها؟