مرحباً، أود أن أسأل عن user_api_keys. حالياً، أعمل على دمج تطبيقنا لاستخدام user_api_keys الخاصة بـ Discourse للمصادقة. سؤالي هو: هل هناك أي طريقة لاسترداد user_api_keys باستخدام واجهة برمجة التطبيقات (API)؟
حالياً، بعد تسجيل الدخول عبر /session.json والتحقق من ملف تعريف المستخدم الحالي باستخدام /users/:username.json، يمكننا معرفة ما إذا كان لدى المستخدم user_api_keys أم لا، ولكنه لا يُرجع القيم الفعلية:
السبب الذي يجعلني أرغب في الحصول على قيمة user_api_keys هو تجنب مطالبة المستخدم بالموافقة على المصادقة مرة أخرى بعد أن قام بالموافقة عليها بالفعل أثناء تسجيل الدخول الأول بالنقر على الزر.
لا، يتم عرضها مرة واحدة فقط ثم يتم تخزين تجزئة (hash) فقط.
يجب تخزين مفتاح واجهة برمجة تطبيقات المستخدم في تطبيقك، ويفضل أن يكون على جهاز المستخدم النهائي. السبب الرئيسي لمفتاح واجهة برمجة تطبيقات المستخدم هو أن لديهم “دليل” على التفويض وهم مسؤولون عن تخزينه.
لا أعتقد أنه من الممكن استرداد قيمة مفتاح واجهة برمجة التطبيقات (API) عبر واجهة برمجة التطبيقات. لا يقوم Discourse بحفظ مفاتيح واجهة برمجة التطبيقات غير المشفرة في قاعدة البيانات. حتى لو تمكنت من استرداد القيمة المشفرة، فلن تكون هناك طريقة لفك تشفيرها في تطبيقك.
هل يمكنك شرح حالة الاستخدام الخاصة بك بشكل أكبر؟ إذا تم بالفعل إنشاء مفتاح واجهة برمجة تطبيقات للمستخدم، فليس من الواضح لي لماذا سيحتاجون إلى الموافقة على التفويض مرة أخرى.
عند إعادة قراءة مشاركتي، أرى أنني لم أشرح كيف تم تعيين المتغير $json للطلب. أسهل طريقة لمعرفة كيفية هيكلة البيانات هي إجراء طلب لإنشاء مفتاح واجهة برمجة تطبيقات مستخدم واحد بالنطاقات التي تريد استخدامها عبر واجهة مستخدم Discourse، ثم النظر إلى قيمة حمولة الطلب التي يتم إرسالها مع الطلب إلى /admin/api/keys:
مرحباً @simon، شكراً على ردك. دعني أشرح حالتنا بمزيد من التفصيل.
نحن نبني تطبيقاً للجوال يعتمد على منطق الواجهة الخلفية من نقاط نهاية Discourse. عندما يقوم المستخدم بتسجيل الدخول عبر التطبيق، يتم إرسال بيانات تسجيل الدخول إلى واجهة برمجة تطبيقات Discourse عبر session.json، والتي تُرجع ملف تعريف ارتباط. يتم بعد ذلك استخدام ملف تعريف الارتباط هذا لإعادة توجيه webview إلى /user-api-key/new، مما يطالب المستخدم بالموافقة على التفويض. بعد الموافقة، يتم فك تشفير الحمولة إلى مفاتيح API.
في هذه الحالة، يمكننا استخدام مفاتيح API كرمز مميز عام داخل تطبيق الجوال للوصول إلى نقاط نهاية Discourse الأخرى. ومع ذلك، عندما يقوم المستخدم بتسجيل الخروج، يجب إزالة الرمز المميز من الحالة العامة حتى لا يتمكن من الوصول إلى نقاط نهاية مثل إنشاء موضوع جديد.
سؤالي هو من هذا الموضوع: كيف يمكننا التحقق مما إذا كان المستخدم يمتلك بالفعل user_api_keys وما إذا كانت لا تزال نشطة؟ إذا كانت المفاتيح موجودة ونشطة، فيجب أن يتمكن المستخدم من استخدامها بعد تسجيل الدخول. إذا لم يكن الأمر كذلك، فسيحتاج المستخدم إلى إنشاء user_api_keys جديدة، والتي ستتطلب موافقة في webview.
لقد أشرت أيضاً إلى المنشور إنشاء مفتاح API للمستخدم بدون موافقة المستخدم - #2 بواسطة simon، والذي نظرت إليه في البداية لتنفيذ مفتاح API. ومع ذلك، تظل المشكلة كما هي: عندما نتحقق من /admin/api/keys، لا يمكننا استرداد قيمة مفاتيح API المحفوظة بالفعل في قاعدة البيانات أو الحصول على مفاتيح API لكل مستخدم. أعتقد أنه لهذا التنفيذ، سنحتاج إلى تخزين مفاتيح API في قاعدة بياناتنا الخاصة.
ربما يمكنك إنشاء رمز جلسة منفصل عن مفتاح API. استخدم هذا الرمز المميز للإشارة إلى حالة تسجيل دخول المستخدم. بهذه الطريقة لن تحتاج إلى حذف مفتاح API عند تسجيل خروج المستخدم.
شكراً لمساهمتك في هذه المشكلة. أتفق على أنه من الأفضل تخزين الرمز المميز في مكانين: أولاً، في الحالة العامة للتحقق من حالة تسجيل دخول المستخدم، وثانياً، في قاعدة البيانات لتخزين user_api_keys.
مرحباً، شكراً لاقتراحك. السبب في عدم استخدامنا لـ Discourse Connect هنا هو أننا لا نقوم بربط Discourse بأي مواقع أخرى أو أماكن أخرى. سيتم التعامل مع جميع وظائف تسجيل الدخول مباشرة من خلال Discourse، وسيتفاعل التطبيق مع Discourse فقط.
تطبيقك هو مكان آخر. أنا متأكد من أنك تريد تكوين تطبيقك ليكون عميل Discourse Connect حتى يتمكن الأشخاص من تسجيل الدخول إلى تطبيقك عن طريق تسجيل الدخول إلى Discourse. ثم يمكن لتطبيقك التفاعل مع Discourse، أعتقد. أو ربما لا أفهم كيف تعمل التطبيقات.
