عندما يعيد تطبيق Spring استجابة 403 أو 401 قبل الوصول إلى نقطة توقف داخل وحدة تحكم أو خدمة، قد لا تكون المشكلة في المنطق الذي يريد المطور فحصه، بل في طبقة التفويض التي سبقت تنفيذ الطلب. تقدم IntelliJ IDEA طريقة لفحص قواعد الحماية الفعلية في التطبيق الجاري، ثم منح الطلب هوية وصلاحيات مؤقتة خلال جلسة التصحيح، من دون تعديل SecurityConfig أو إعادة تشغيل التطبيق.
الميزة جزء من Spring Debugger plugin في IntelliJ IDEA Ultimate، وهي متاحة منذ إصدار 2026.2. وتظهر Security inlays افتراضياً أثناء تشغيل المصحح، سواء كان التطبيق محلياً أو يعمل على JVM بعيدة.
ابدأ بمعرفة ما يطلبه المسار فعلياً
تعرض الواجهة داخل المحرر أو ملف HTTP المتطلبات القائمة على الأدوار والصلاحيات لنقطة النهاية، بما في ذلك القواعد المبنية على hasRole وhasAuthority. ولا تعتمد IntelliJ IDEA هنا على قراءة ملفات الإعدادات فقط، بل تفحص SecurityFilterChain الفعلية داخل JVM بعد تهيئة سياق Spring. وهذا مهم عندما تؤثر عدة SecurityFilterChain أو ترتيب المطابقات أو الملفات التعريفية النشطة أو التسجيل الشرطي للإعدادات في النتيجة النهائية.
إذا تعذر تحويل قاعدة معينة إلى قائمة أدوار، كما يحدث مع بعض تطبيقات AuthorizationManager المخصصة، تظهر القاعدة كحالة غير معروفة، مع رابط إلى كود إعداد الحماية ذي الصلة. في هذه الحالة لا يتاح الفتح التلقائي المعتمد على قائمة الأدوار، ويظل الرجوع إلى SecurityConfig ضرورياً.
فتح مؤقت للمسار أثناء جلسة التصحيح
يوفر إجراء Unlock خيارين. الأول يمرر الطلب باعتباره مصادقاً عليه بمجموعة الأدوار المطلوبة للمسار، وهو مناسب عندما يريد المطور اختبار منطق وحدة التحكم أو الخدمة خلف مسار محمي. أما الثاني فيتيح تحديد اسم مستخدم وقائمة صلاحيات مخصصة، مثل admin مع ROLE_ADMIN وROLE_MANAGER، لاختبار سلوك التطبيق تحت مجموعة صلاحيات بعينها.
عند تنفيذ الإجراء، ينشئ المصحح كائن TestingAuthenticationToken داخل SecurityContext للتطبيق الجاري. وترى فحوصات hasRole وhasAuthority، وكذلك SecurityContextHolder.getContext().getAuthentication() ومعاملات Principal أو Authentication، الهوية والصلاحيات التي حددها المطور. لا يغير الإجراء كود التطبيق أو ملفات الإعدادات، وتختفي عمليات الفتح عند إعادة تشغيل التطبيق، بما في ذلك إعادة التشغيل داخل العملية عبر Spring Boot DevTools، أو عند قفل المسار يدوياً.
لا يقتصر الأثر على الطلب المرسل من IntelliJ IDEA. ففتح GET لمسار محدد يؤثر في أي عميل يصل إلى URI وطريقة HTTP نفسيهما، مثل curl أو Postman أو المتصفح. وإذا فُتح نمط مسار في تعريف وحدة التحكم، فقد يشمل ذلك جميع القيم المطابقة للنمط. لذلك ينبغي إعادة قفل المسار أو إنهاء جلسة التصحيح بمجرد الانتهاء، خصوصاً إذا كان التطبيق متاحاً عبر الشبكة.
ما الذي لا يتجاوزه Unlock؟
لا يعطل الإجراء Spring Security بالكامل ولا يتجاوز حماية CSRF. فإذا كان الطلب من نوع POST أو PUT أو DELETE يحتاج إلى رمز CSRF صالح، فسيظل CsrfFilter قادراً على رفضه. كما أن نطاقه يقتصر على تفويض نقاط النهاية عبر AuthorizationFilter ضمن مكدس Servlet؛ ولا يدعم Spring WebFlux الذي يستخدم AuthorizationWebFilter.
ولا توجد واجهة مباشرة لعرض أو فتح متطلبات الحماية على مستوى الأساليب مثل @PreAuthorize و@PostAuthorize و@Secured. مع ذلك، فإن الصلاحيات المحقونة في SecurityContext يمكن أن تُقرأ لاحقاً من اعتراض حماية الأساليب، ولذلك قد يمر استدعاء خدمة محمي بـ @PreAuthorize إذا كانت الصلاحيات الممنوحة تفي بشرطه. هذا لا يعني أن IntelliJ IDEA فتح حماية الأسلوب نفسها، بل إن الفحص قرأ نفس سياق المصادقة الاصطناعي.
قيود الهوية والتكامل مع أدوات الاختبار
الهوية التي ينشئها المصحح هي اسم مستخدم نصي داخل TestingAuthenticationToken، وليست UserDetails الخاصة بالتطبيق أو نوعاً مخصصاً من كائنات المستخدم. لذلك قد يعيد معامل يحمل @AuthenticationPrincipal قيمة null، وهي مشكلة معروفة برقم IDEA-389767 وكانت تؤثر في إصدار 2026.2 وقت نشر المادة.
يمكن استخدام Principal أو Authentication كنوع للمعامل، لكن الاعتماد على نوع ملموس مثل JwtAuthenticationToken قد يؤدي إلى IllegalStateException لأن الكائن المحقون لا ينتمي إلى ذلك النوع. كما قد تختلف النتائج أو تفشل الأجزاء التي تعتمد على claims أو credentials أو هوية مرتبطة بجلسة أو بنوع محدد من رموز المصادقة.
يعمل الفتح مع الطلبات القادمة من ملف .http المدمج أو من curl وPostman وأطر الاختبار، شرط أن يكون التطبيق الجاري هو نفسه الذي فتح فيه المسار. أما في مسارات العمل الآلية أو المعتمدة على وكلاء الذكاء الاصطناعي، فلا يوجد حالياً مفتاح برمجي لتنفيذ العملية. تخطط JetBrains لإضافة أداة MCP ومهارة مرتبطة بها في الإصدار 2026.3، لكن الإصدار الحالي يتطلب نقرة يدوية أولى من داخل IDE.
لماذا تهم هذه الممارسة؟
القيمة العملية هنا ليست تعطيل الحماية، بل عزل طبقة التفويض عن المنطق الذي يريد المطور اختباره من دون ترك تعديلات مؤقتة في ملفات الإعدادات قد تُنسى وتصل إلى بيئة أخرى. في المقابل، فإن الفتح تغيير أمني مؤقت في العملية الجارية، وليس محاكاة محلية محصورة بطلب IDE. لذلك ينبغي اعتباره أداة تصحيح مضبوطة النطاق، لا بديلاً عن اختبار المصادقة الحقيقي، مع التحقق من المسار والطريقة والعملاء المتأثرين قبل استخدامه.
كما يجب الانتباه إلى أن الميزة لا تسجل رسالة في السجلات ولا توفر مؤشراً عبر Actuator عند فتح مسار في تطبيق بعيد. ووفق المادة، لا يمكن التحقق من الحالة إلا عبر الواجهة داخل IDE المتصل بالتطبيق. ويمكن تعطيل Security inlays من إعداد spring.debugger.security.enabled في Registry الخاص بـ IntelliJ IDEA عند عدم الحاجة إليها.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.