لدي سؤال آخر حول أمان استخدام واجهة برمجة التطبيقات لأنني أعتقد أنني أفتقد مفهومًا بسيطًا بسبب قلة خبرتي.
لدي تطبيق منفصل لـ Discourse لدمجه في الواجهة الأمامية الخاصة بي وقد قمت بتمكين تسجيل الدخول الأحادي (SSO) للمصادقة على المستخدم بنجاح.
كان فهمي الأولي هو أنني كنت أستخدم SSO للمصادقة كـ “المستخدم النشط” لجلب البيانات الخاصة بالمستخدم النشط من واجهة برمجة التطبيقات. أرى الآن أن هذا ليس صحيحًا تمامًا.
أرى الآن أن البيانات التي يتم إرجاعها تبدو معتمدة على ‘api-username’ الذي يتم تمريره في الرأس. لكنني أستخدم مفتاح API إداري لذا أعتقد أن هذا يعني أنه يمكنني جلب بيانات أي مستخدم أريده عن طريق تمرير اسم المستخدم الصحيح لـ “api-username”.
لذا فإن سؤالي يتركز على أنه يبدو أن واجهة برمجة التطبيقات لا تقدم مفهوم “المستخدم النشط” ويجب علي تعديل المستخدم النشط عن طريق استرداد اسم المستخدم عن طريق external_id ثم استخدامه كـ api-username طوال الجلسة النشطة، هل هذا صحيح؟
إذا كان فهمي صحيحًا، أليس من السهل على المتسلل تعديل api-username في الرأس لاسترداد مناقشات الدردشة لأي مستخدم؟
أي معلومات إضافية ستكون موضع تقدير للمساعدة في فهمي. شكرًا!
لا يجب عليك أبدًا استخدام واجهة برمجة التطبيقات هذه من الواجهة الأمامية لأنه في هذه الحالة يمثل هذا بالفعل خطرًا (في الواقع الخطر أعلى بكثير لأن المتسلل يمكنه فعل أي شيء)
يجب عليك القيام بذلك من الواجهة الخلفية.
إذا لم يكن هذا خيارًا، فيجب عليك استخدام مفاتيح واجهة برمجة تطبيقات المستخدم بدلاً من ذلك.
بصفتي تطبيقًا بدون رأس (headless)، سأقوم بتشغيل هذا من الواجهة الأمامية الخاصة بي. لذا، في هذه الحالة، يبدو أنني بحاجة إلى قضاء بعض الوقت في محاولة فك رموز المناقشة حول هذا الموضوع:
على غرار هذه المناقشات، سأكون مهتمًا بتوليد مفتاح واجهة برمجة التطبيقات (API) الخاص بالمستخدم تلقائيًا باستخدام وصولي إلى واجهة برمجة التطبيقات الإدارية. ومع ذلك، في تدفقي، لن أرغب في إعادة توجيه المستخدم إلى صفحة جديدة لـ “الموافقة” على تطبيقي. إما أن أرغب في فرض الموافقة باستخدام مفتاح واجهة برمجة التطبيقات الإداري الموثوق به الخاص بي أو هل هناك إعداد يمكنني تعطيله بحيث لا يلزم المصادقة الإضافية لمفتاح واجهة برمجة التطبيقات الجديد الذي أقوم بإنشائه؟
