تأمين واجهات API باستخدام Spring Security

حتى الآن، يقبل biblio-api الجميع. يستطيع أي شخص إنشاء كتاب، أو حذف كتاب آخر، أو قراءة الفهرس بأكمله. هذا مريح على جهاز التطوير، لكنه عند أول نشر يصبح باباً مفتوحاً.

يطرح تأمين واجهة API سؤالين مختلفين، والخلط بينهما هو أول مصدر للأخطاء. من أنت؟ سؤال يتعلق بالمصادقة (authentication)، واستجابة الفشل فيه هي 401 Unauthorized. هل يحق لك فعل هذا؟ سؤال يتعلق بالتفويض (authorization)، واستجابة الفشل فيه هي 403 Forbidden. فالمستخدم الذي صودق عليه بشكل صحيح ثم حاول حذف كتاب دون امتلاك الدور المطلوب يجب أن يتلقى 403 لا 401؛ لأن الاستجابة الثانية توهمه بأن بيانات اعتماده غير صالحة، فيعيد تسجيل الدخول مراراً دون جدوى.

وتنتظر من يبحث عن مساعدة على الإنترنت في هذا الموضوع صعوبة خاصة. فقد حذف Spring Security 6، المضمَّن في Spring Boot 3، الصنف WebSecurityConfigurerAdapter. هذا الصنف ليس مهجوراً (deprecated)، بل لم يعد موجوداً أصلاً. ومع ذلك فإن معظم المقالات والإجابات والأمثلة المفهرسة منذ عشر سنوات تعتمد عليه، والقارئ الذي ينسخها يحصل على خطأ في الترجمة لا تشرحه أي من تلك المقالات. أصبحت الإعدادات تُصرَّح الآن عبر الـ beans، وبخاصة bean من نوع SecurityFilterChain.