«نحتاج بوابة يدخل إليها العملاء ويتابعون طلباتهم». تبدو العبارة كافية لطلب عرض، لكنها تترك قرارات كبيرة للمطور: هل الحساب لشخص أم لشركة؟ من يرى المستندات؟ وأي حالة تمثل الحقيقة إذا كان الموظف يعمل في برنامج آخر؟ ابدأ بمسار خدمة واحد، ثم حدد من يملك كل خطوة فيه.
بوابة العملاء مساحة عمل مشتركة بحدود، وليست نسخة من لوحة موظفيك مع إخفاء بعض الأزرار. هدف طلب العرض أن يجعل هذه الحدود مفهومة وقابلة للاختبار، وأن يوضح ما ستنفذه الشركة وما سيبقى في إجراءاتك الحالية. تستطيع بذلك مقارنة نطاقين دون الانشغال بعدد الصفحات وحده.
اختَر طلبًا يستطيع الطرفان إكماله
لنفترض شركة افتراضية تؤجر معدات للفعاليات. يراجع العميل عرض التجهيز ويرفع موافقته ويتابع موعد التسليم، بينما يعتمد الموظف التوافر ويسجل المستند النهائي. المثال توضيحي، ولا يمثل مشروعًا منفذًا أو سياسة تجارية عامة. نريد من البوابة تقليل الغموض حول هذه المهمة، لا إدارة كل أعمال الشركة دفعة واحدة.
اكتب نقطة البداية والنهاية وما يحدث بينهما. هل طلب تعديل الموعد يغير الحجز فورًا أم يرسل اقتراحًا ينتظر مراجعة؟ هل يستطيع العميل إلغاء طلب قيد التجهيز؟ من يشرح سبب الرفض؟ الإجابة «حسب الصلاحية» غير كافية قبل تسمية الدور والشرط والنتيجة التي يراها المستخدم.
بطاقة نطاق لمسار واحد
| جزء المسار | قرار تسجله | دليل قبول |
|---|---|---|
| حساب العميل. | مؤسسة وأعضاؤها، ودور من يدعو عضوًا أو يلغيه. | مستخدمان من المؤسسة نفسها يريان الحدود المتفق عليها. |
| طلب تعديل. | الحقول القابلة للتغيير والحالات التي تمنعه. | اقتراح محفوظ لا يصبح موعدًا معتمدًا دون المراجعة المطلوبة. |
| مستند. | مصدر النسخة ومن يقرأها وما يظهر عند استبدالها. | العميل يفتح النسخة المقصودة، دون مستند مؤسسة أخرى. |
| حالة الطلب. | النظام الذي يعتمدها ووقت آخر تحديث معلوم. | تعذر الربط يظهر كتعذر تحديث، لا كحالة تنفيذ جديدة. |
أضف لكل صف المسؤول التشغيلي ومصدر البيانات وما يؤجل للمرحلة التالية. البطاقة ليست مواصفة جاهزة لكل بوابة؛ تستطيع حذف المستندات إن لم يحتجها المسار، أو إضافة موافقة ثانية إذا كان العمل يتطلبها فعلًا. كل إضافة تحتاج شرحًا لأثرها على الطرفين، لا اسم شاشة فحسب.
افصل عضوية المؤسسة عن ملكية السجل
قد يدير مندوب واحد طلبات مؤسستين، وقد ينتقل موظف العميل إلى دور آخر. ناقش كيف تنتهي صلاحية الوصول وما يحدث للطلبات التي أنشأها. لا تعتمد على البريد الإلكتروني وحده لافتراض أن كل من يحمل نطاقًا معينًا مخول لرؤية جميع المستندات. هذه علاقة عمل ينبغي لصاحب الخدمة تعريفها.
تؤكد إرشادات OWASP ضرورة فحص الإذن في كل طلب وتطبيق أقل صلاحية. اجعل العرض يشمل تحقق الخادم من علاقة المستخدم بالطلب والمستند؛ إخفاء الرابط في الواجهة لا يثبت هذه الحماية. ولا تعني الإشارة إلى المرجع أن البوابة حصلت على اعتماد أو اجتازت اختبارًا أمنيًا مستقلًا.
اختبار بعميلين يوضح أكثر من عرض بحساب واحد
جهز مؤسستين تجريبيتين بمستندات غير حقيقية. افتح الطلب المسموح، ثم حاول بالحساب نفسه الوصول إلى طلب المؤسسة الأخرى وملفها عبر رابط مباشر داخل بيئة اختبار مصرح بها. يجب أن تكون النتيجة منع الوصول دون كشف المحتوى. يشرح مرجع IDOR أن صعوبة تخمين المعرف لا تغني عن التحقق من الصلاحية.
أعد التجربة بعد إلغاء عضوية مستخدم، ومع دور يقرأ دون أن يعتمد. سجل النتيجة المتوقعة وما حدث فعليًا والمسؤول عن أي نقص. هذه عينات قبول للمسار، ولا تحل محل مراجعة أمنية أوسع؛ كما لا ينبغي إجراء محاولات على حسابات عملاء حقيقيين لإثبات الفكرة.
لا تجعل الإشعار مصدر الحقيقة
قد تتأخر رسالة الموعد بينما تكون الحالة المعتمدة قد تغيرت. حدد ما يراه العميل عند فتح البوابة، وما إذا كان الإشعار يقوده إلى سجل محدث، وكيف يسأل عن اختلاف. وإذا تعطل النظام الخارجي، اطلب إظهار آخر معلومة مؤكدة وحدود حداثتها بدل تقديم قيمة قديمة كأنها لحظية.
يشرح الفرق بين الموقع وتطبيق الويب قرار نوع المشروع، بينما يخصص هذا الدليل طلب عرض البوابة نفسها. أرسل البطاقة ومسار المؤسسة التجريبية عند مناقشة تطوير تطبيقات الويب مع نكست ويف، واطلب تسعير الحالات والأدوار والربط والتشغيل التي اخترتها بوضوح.
مراجع الصلاحيات وحدود المثال
فُتح مرجعا OWASP عن التحقق من الصلاحيات ومنع الوصول غير المصرح للسجلات في 4 نوفمبر 2026. البطاقة ومثال التأجير إرشاد شراء أصليان. أُعد النص بمساعدة الذكاء الاصطناعي مع مراجعة المعلومات والترجمة، دون ادعاء تجربة عميل أو اعتماد أمني.
