#كلام_مبرمجين
رحلة الـ Request بشيء من التبسيط
لنستوعب الية عمل auth و multi auth لابد من فهم كيف يتم ارسال البيانات و الوصول لها .
فالمستخدم يتعامل مع التطبيق عن طريق ال Request للقيام بعمليات مثل (عرض - اضافة - تعديل - حذف) .
الـ Request اشبه ما يكون بسائق شاحنة.
أول وجهة يقصدها ال request هي (routes)
• الـ routing يتم تحميلها مباشرة عند بدء عمل النظام ، ويتم فيها تسجيل كل ال routes التي تحدد كيف سيتم الاستجابة للـ HTTP وشكل الطلب الذي سنتعامل معه.
في هذه المرحلة اذا لم يستوفى الطلب المواصفات المسجلة سيتم الإبلاغ عنه و تحويله الى Exception من نوع 404 ، اما اذا تمت المطابقة سيتم تحويلة بحسب الـ routes الى الوجهة المحددة بعد أن يستكمل الوثائق والشروط المطلوبة.
من الشروط الواجب توفرها في عمليات من نوع ( POST, PUT, or DELETE ) انه لابد من توفر شهادة CSRF سارية المفعول وموثقة لدى (VerifyCsrfToken Middleware) مالم سيتم احتجاز الطلب وتحويله الى Exception وتوجيه له تهمة من نوع TokenMismatchException .
الإجراءات التي تمت إلى حد الآن هي اجراءات روتينية يتم اتخاذها بحق جميع الطلبات ، لكن هناك حالات يتوجب أن يتم التعامل مع الـ request بصرامة أكثر و عليه أن يقوم بإكمال تصديق الوثائق الإضافية، حيث يفترض مراجعة auth middleware او المكتب المحدد من قبل لroute او دالة ال construct في ال controller او عند اللزوم ، في هذه الحالة يقوم الـ auth بالتحقيق ليقرر هل بالإمكان مواصلة الرحلة مالم سيقوم بدوره بتحويلك الى مكتب login .
اذا توفرت هذه الإجراءات في النظام لدينا سنكون بهذا الشكل وفرنا المتطلبات الاساسية لكن رحلة request لا زال يكتنفها بعض الغموض ، فما يزال يتوجب علينا سن بعض القوانين ومنح الصلاحيات لطلبات المستخدمين للقيام ببعض الاجراءات أو عبور بعض البوابات (gates ) و فحص انواع البيانات التي يتم نقلها و مدى مطابقتها للمواصفات والمعايير .
بإذن الله في منشورات قادمة سنحاول القاء الضوء بمزيد من التفصيل على هذه الرحلة والهيكلية المتبعة والادوات المستخدمة.
استندنا في حديثنا على نظام ببنية MVC ووصف العمليات كما تحدث في laravel framework .
