يقبل نموذج العميل اسمًا ورقم هاتف، لكن الطلب الذي يصل إلى الخادم قد يحمل حقولًا إضافية لا تظهر على الشاشة. إخفاء حقل الدور في الواجهة لا يمنع إرساله. قبل اعتماد الحفظ في CRM، افصل ثلاثة أسئلة: هل القيمة صحيحة؟ هل الحقل مسموح بالتعبئة؟ وهل المستخدم مخول بتعديل هذا السجل أصلًا؟
ماذا تضبط fillable؟
تشرح وثائق Eloquent في Laravel 12 حماية التعبئة الجماعية وتحديد الحقول عبر fillable أو guarded. عند تمرير مجموعة قيم لعمليات التعبئة، تحدد القائمة ما يمكن تعبئته. وقد تُهمل الحقول غير المسموحة بصمت افتراضيًا؛ وتوفر preventSilentlyDiscardingAttributes وسيلة لكشفها أثناء التطوير المحلي.
إذا اخترت guarded فارغة، فأنت تفتح التعبئة الجماعية وتحتاج بناء المصفوفات المرسلة للنموذج بعناية. لا تجعل هذا الاختيار علاجًا سريعًا لحقل لا يُحفَظ دون فهم سبب استبعاده. راجع إصدار المشروع الفعلي قبل استخدام أمثلة الوثائق.
ثلاث طبقات لا تختصرها في قائمة واحدة
| الطبقة | سؤال المراجعة |
|---|---|
| التحقق من القيم | هل الهاتف والاسم ضمن العقد المقبول؟ |
| قائمة الحقول | هل تسمح هذه العملية أصلًا بتغيير ذلك العمود؟ |
| التفويض | هل يملك هذا المستخدم حق التعديل على العميل المحدد؟ |
اختبر حقلًا زائدًا ببيانات مصطنعة
في بيئة اختبار، جهز عميلًا تجريبيًا وحساب موظف محدودًا. أرسل تعديلًا صحيحًا للاسم والهاتف ومعه حقل role إضافي لا تسمح به العملية. افحص السجل بعد الطلب: يتغير فقط ما تسمح به سياسة العملية، أو يُرفض الطلب وفق العقد المعلن، دون رفع امتيازات أو نقل ملكية خفي.
ثم اختبر طلبًا إلى سجل لا يحق للحساب تعديله، حتى لو كانت جميع حقوله من fillable. مرور قائمة الحقول لا يثبت صحة التفويض. لا تستخدم بيانات عميل فعلي أو حساب مدير واسع الصلاحيات لاختبار حدود موظف عادي.
راجع كل مسار للكتابة
ضمن بناء CRM سجل من أين تأتي كل قيمة حساسة: هل يحسبها الخادم أم يسمح بإدخالها؟ لا تدعِ أن fillable تغطي كل أساليب الكتابة أو تمنع أخطاء SQL المباشر. سلّم في المراجعة التقنية نتائج الحقول المسموحة والمرفوضة وحالات التفويض، مع فحص قاعدة البيانات بعد التنفيذ؛ رسالة نجاح الواجهة وحدها ليست دليلًا على سلامة الحفظ.
