الفن فن والفنون فنون، وفن تحليل Analyzing الصلاحيات مع التطبيقات متعددة المستخدمين يعتبر دليل على إبداعك كمحلل محترف للبرنامج، فطلبات العملاء في السنين الأخيرة كلها تطبيقات متعددة المستخدمين، وتفرض عليك رغبات معقدة في توفير صلاحيات مختلفة الأصول والتوجهات، فعميلنا يريد من المستخدم "س" ان يستطيع ان يضيف هنا ولكن لا يستطيع أن يضيف هناك، كما يريد أن يمكن المستخدم "ص" من قراءة هذه المعلومات ولكن يمنعه من قراءة تلك. في المقال التالي سنرى أفكارا وأساليب مختلفة تشرح لك كيف يمكنك تطبيقات الصلاحيات في برنامجك. (1) دول العالم الثالث (من ضمنها دولنا العربية) حالها كحال سائر دول العالم تحتوي على أنظمة وقوانين إرشادية هدفها تنظيم سياسة السماح والمنع، ولكن تتميز هذه الدول بشعوب أذكى وأرقى كثيرا من إتباع هذه القوانين، حيث تفضل (هذه الشعوب) تنفيذ أفعالها كما يحلو لها دون إعطاء أي احترام او إلقاء أي مبالاة لهذه الأنظمة والتعليمات، وهذا ما نسميه بالضبط "خرق الصلاحيات". فشيء طبيعي جدا ان ترى –مثلا- موقف Parking صلاحياته مخصصة لذوي الاحتياجات الخاصة او أصحاب منزل معين او موظفين شركة معينة تقف فيه سيارات أخرى، ومن الطبيعي ايضا ان ترى بوابة صلاحيتها للخروج فقط مكتظة بأشخاص يحاولون الدخول منها، وليس بغريب أبدا ان تجد مدخنين يتركون أماكن مخصصة للتدخين ليغزوا أماكن أخرى (سواء في مطاعم، مطارات، أو أي أماكن عامة أخرى)، بل من سمات الكثير من المنتزهات والمرافق العامة ان تكون سلة مهملات لإلقاء النفايات، وغيرها الكثير من الأمثلة... تطبيقات وبرامج الحاسب لها أيضا نفس المفهوم الإداري في سياسة السماح والمنع، ولكن –ولله الحمد- تطبيقها إلزامي (على الكل)، ولن يستطيع شخص خرق هذه السياسات (باستثناء حالات الاختراقات الأمنية والتي يعاقب عليها القانون)، وهو ما يعرف في علم هندسة الحاسب بصلاحيات المستخدمين. ولك أن تتخيل أن يصبح عالم البرامج أو العالم الرقمي بشكل عام بلا صلاحيات (مثل الصورة السابقة)؟! فأعتقد أننا سنغرق في مستنقع لفوضى رقمية لا يمكن حتى تخيل أبعادها، ليتمكن كل شخص من إضافة وتعديل وقراءة أي معلومة في أي نظام في الكرة الأرضية. يعتقد الكثير من المحللين Analysts –بكل أسف- ان كلمة الصلاحيات يمكن ترجمتها في برامجهم على أنها أسلوب نحدد فيه الشاشات التي يستطيع المستخدم الدخول عليها أو إضافة سجلات أو حذف سجلات فقط، ولكن في الحقيقة أن الموضوع اعقد وأكبر مما يتصورون. فصلاحيات البرامج تختلف من تطبيق إلى آخر بشكل كبير، مما يعني استحالة إتباع أسلوب ومعيار موحد لتطبيق الصلاحيات في المشاريع المختلفة. لذلك، غرضي من هذا المقال عرض الأساليب المختلفة والتي تشترك فيها أغلب (لاحظ قلت أغلب وليس كل) البرامج والموجهة لمستخدمين متعددين، ولكن قبل ذلك؛ من الضروري التفريق بين كلمتان كبيرتان هما التصديق والتصريح. التصديق والتصريح قبل البدء في تحليلنا أحب ان أعرفك بمصطلحين هامين عليك التفريق بينهما هما التصديق Authentication والتصريح Authorization. لنبدأ بالمصطلح الأول، التصديق Authentication هي عملية معرفة الشخص الذي يستخدم النظام ومن ثم ((المصادقة)) عليه والاعتماد على انه الشخص المطلوب، بمعنى التحقق من هوية الشخص المستخدم للنظام والتي تتم (في الغالبية الساحقة من التطبيقات) عن طريق اسم مستخدم وكلمة مرور Login ID and Password. عندما تنوي تطبيق التصديق في برنامجك، عليك التعهد وقطع عهد أخلاقي على نفسك بعدم تمكن أي شخص في الكرة الأرضية (بما فيهم أنت كمصمم النظام) من التمكن من معرفة كلمات المرور بعد تشفيرها (قد تستخدم التشفير أحادي الاتجاه One way encryption)، فهناك نسبة كبيرة من المستخدمين يستخدمون نفس كلمات المرور في أكثر من نظام، كما أنه تعدي صارخ على خصوصيات المستخدمين User Privacy، وإن كنت تنوي استغلال هذه النقطة، فإعلم انك تضر بنفسك وسمعتك وسمعة برامجك قبل ان تضر بالآخرين، فهذه النوعية من التطبيقات عالية المخاطر وغير مرغوبة بسبب أنها تحمل ثغرة أمنية Security Hack شهيرة جدا. قد تصفعني بسؤال قوي وتقول لي، إن كنت يا تركي تريد منعي من معرفة كلمات المرور بعد تشفيرها، فكيف نستطيع استرجاع كلمات المرور إن تم فقدانها (بناء على طلب العميل)، وإجابتي تكون بأن الأسلوب العالمي الذي تتبعه التطبيقات الحديثة هو توفير ميكانيكية لإعادة إسناد كلمة المرور Reset Password ((وليس)) استرجاعها Restore Password، بمعنى نوفر شاشة لتسجيل كلمة مرور جديدة ((دون)) معرفة القديمة. ولو تلاحظ (في المواقع العالمية الجديدة مثلا) انك حين تطلب كلمة المرور على بريدك الالكتروني سيقوم النظام بإرسال كلمة مرور ((جديدة)) عشوائية وليس القديمة، وأما إن أرسل النظام كلمة المرور القديمة فهنيئا له هذه الثغرة الأمنية الفاضحة! أخيرا، لا تقتصر عملية التصديق على اسم المستخدم وكلمة المرور بل توجد وسائل أخرى، مثل استخدام البطاقات الذكية Smart Cards والتي تحتوي على شريحة ذكية، التحقق عن طريق بصمة الأصابع، المسح الضوئي للعين الجميلة (يعيبها أن البعض يستخدم عدسات لاصقة)، وغيرها من الطرق والتي تهدف من التحقق من هوية الشخص، وإن كنت تنوي إتباع الأسلوب التقليدي للتحقق (أقصد اسم مستخدم وكلمة مرور)، فحاول تطبيق سياسات متشددة في إختيار كلمات المرور مثل ضرورة ان تكون خليط من حروف وأرقام ورموز، تحديثها بشكل دوري، أو عدم استخدام كلمة مرور سابقة. أما التصريح Authorization فهي الخطوة التي تلي التصديق مباشرة، والتي تمثل معرفة ما هي الصلاحيات التي لدى مستخدم البرنامج، ونقصد بالصلاحيات المعلومات التي يمكنه التعامل معها أو الأفعال التي يستطيع ان يقوم بها في البرنامج. وكما قلت قبل بضعة سطور، لا توجد طريقة موحدة او اسلوب موحد لتحليل طريقة تطبيق وتوزيعات الصلاحيات في برنامجك، فكل برنامج تنتجه مصانع المبرمجين حالة خاصة وله وضعه الخاص في طريقة توزيع الصلاحيات على المستخدمين، فالنظام "س" تعتمد صلاحيات مستخدميه على الأقسام التي يعملون بها، والبرنامج "ص" يعتمد على نوعية المستخدم، بينما النظام "ع" تحديد صلاحياته تعتمد على مهمة المستخدم المكلف بها. وما نتحدث عنه في هذا المقال هو عرض لأبرز الأساليب والحالات التي قد تواجه المحللين عند تطوير برنامج جديد. كلمات ليست كالكلمات توجد مجموعة من الكلمات يتم استخدامها في العادة بشكل مترادف في مواضع مختلفة، ولكني أحاول ان أضع النقاط على الحروف وأبين لك انه توجد فروق طفيفة بينها. • المستخدم User: المستخدم النهائي هو الشخص (الكائن الحي الفريد) الذي يستخدم النظام، استخدامي لعبارة "الكائن الحي الفريد" ليس بلاغيا وستفهمه بعد قليل. • الحساب Account: الحساب هي هوية تستخدم النظام، تكون هذه الهوية اسم غير مكرر يعرفها ويميزها عن غيرها. قد تقول ان الحساب هو نفسه المستخدم (وقولك صحيح بشكل مبدئي)، ولكن ان تعمقنا في الموضوع أكثر فهناك فرق كبير، حيث ان المستخدم هو كائن حي واحد فريد، بينما قد تكون للمستخدم (نفس هذا الكائن الحي) اكثر من هوية (حساب) في النظام. والعكس صحيح ايضا، فقد يشترك اكثر من مستخدم (كائنات حية) في نفس الحساب مثل حساب الزائر Guest. المزيد أيضا، يمكن ان يوجد حساب لا يستخدمه مستخدم نهائي وسترى ما فائدته لاحقا! • الفعل Action: فلسفيا، الفعل هي عملية تؤثر في بيانات النظام او تؤدي مهمة معينة. إنشاء سجل جديد، تعديل معلومة، حذف بيانات، تعديل إعدادات النظام ...الخ كل هذه أفعال تقوم بها حسابات المستخدمين. • القاعدة/القانون Rule: القوانين هي شروط معينة ترتبط بالفعل. مثلا العدد الأقصى من السجلات في اليوم، اكبر قيمة مصرحة لتطبيق التخفيض، السماح بإضافة سجلات جديدة ...الخ كل هذه أمثلة لقوانين. • الإذن Permission: الأذون هي قيم تسند إلى القوانين Rules وتبين إمكانية تطبيقها على الشخص او على المحتوى. فلو وضعنا أذون للقوانين السابقة فستكون (على التوالي) 5، 15%، نعم. • المعلومة/البيان Data: المعلومة هي صورة الكترونية لحروف/ارقام/رموز/صور تمثل المحتوى البياني للنظام والتي تحفظ على الاقراص. قد تكون هذه المعلومة سجل في قاعدة بيانات، بيانات XML، ملفات، نصوص Texts، وأي بيانات رقمية أخرى. الشكل التالي يظهر مثال يوضح هذه المصطلحات الفلسفية: عند تطبيق الصلاحيات بشكل عملي في برنامجك، فهناك توجهان تعتمد عليهما عملية تحديد الصلاحيات والتي اما تكون صلاحيات موجهة للحساب Account Oriented Authorization وإما صلاحيات موجه للبيانات Data Oriented Authorization. مع العلم ان ((كلا)) التوجهان يمكن تطبيقهما في ((نفس)) البرنامج ولا يشترط اعتماد أسلوب واحد فقط، لنفصل في النوع الأول: أولا: الصلاحيات الموجهة للحسابات الصلاحيات الموجهة للحسابات Account Oriented Authorization (كما يتضح من عنوانها) تكون سياسة تطبيق القوانين والأذون على الحسابات Accounts، وتقوم بتوفير ميكانيكية لإعداد هذه الصلاحيات لكل مستخدم، مثلا هنا: كما ترى بالشكل السابق، حددنا الصلاحيات بناءا واستنادا على المستخدم المحدد (وهو Ibrahim). وان كانت القوانين كثيرة ومتشعبة، فيمكنك تصنيفها كما فعلت هنا: حسابات خاصة في البرامج الكبيرة، توجد مجموعة من الحسابات المعرفة مسبقا Predefined Accounts او مبنية في النظام Built-in Accounts، وهذه الحسابات لا يمكن حذفها ابدا ابدا ابدا، فقد تم أخذها بعين الاعتبار لحظة بناء البرنامج. مع ذلك، لا يشترط عليك توفير هذه الحسابات دائما في برنامجك (باستثناء الأول فهو مهم): • المسئول الرئيسي حساب المسئول الرئيسي يكون بالعادة Administrator او Admin او SuperAdmin وهو يتم تعريفه لحظة تركيب النظام Installation وتجهيز قاعدة بياناته. يعتبر هذا الحساب الحساب الرئيسي والمشرف الأول والأخير على النظام، والذي يمكن من خلاله البدء في اعداد النظام وتعريف قائمة حسابات جديدة. حساب النظام لديه كـــــــــــــــــــــــــــــــــــــــــــــــــــل الصلاحيات ولا بد أن يستطيع القيام بكل الأفعال (فهو فوق القانون). من المهم التحذير هنا بأن هذا الحساب لا يفترض أن يعطى إلا للمسئول الفني للنظام ((فقط))، ولا يفترض ان يتم استخدامه بكثرة وذلك حماية ورحمة ببيانات النظام من إعدامها عن طريق الخطأ، أي باختصار يستخدم في الحالات القصوى وعند الضرورة فقط، فلا تعطيه حتى لو أصر مديرك في العمل أو عميل لإرضائه. • المجهول بعض الأنظمة (في الغالب تكون مواقع ويب)، لا تشترط ان يكون للمستخدم حساب للدخول للنظام، مع ذلك كل مستخدم ليس له حساب سيقوم النظام بافتراض انه على هوية تعرف بالمجهول. يسمى حساب المجهول بـ Unknown Account او Anonyms Account او Guest Account او Undefined Account. ان كان نظامك يسمح الدخول للجميع، فمن الضروري جدا تعريف هذا النوع من الحسابات حتى تستطيع شاشة توزيع الصلاحيات من تحديد صلاحيات هؤلاء المجهولين (وإلا ستختلط الأنساب وتضيع المحارم). • الحسابات النظامية اما الحسابات النظامية (تسمى في الغالب System Accounts) فهي حسابات مخفية ولا يستطيع أي مستخدم من استخدامها (بشكل مباشر) والدخول بها. تستخدم الحسابات النظامية في حالات كثيرة عندما تود تعريف حساب يقوم بعملية معينة او فعل معين في نظامك (كتشغيل خدمة Service مثلا) وبنفس الوقت لا تود إعطاء صلاحية مباشرة لحساب مستخدم معين حتى لا يتم استغلالها. تذكر ان هذا النوع من الحسابات ممنوع من ان يستخدمه أي شخص، فعند شاشة تسجيل الدخول Login لابد من رفضه. الأمان المبني على المجموعات كلما زاد عدد المستخدمين في برنامج (نتكلم عن حالات تصل إلى المئات، آلاف، او حتى ملايين) تصبح عملية إسناد الأذون والصلاحيات لكل مستخدم عملية مملة ومتعبة كثيرا، بل حتى التفكير في تعديل بسيط لإجراءات العمل قد تقتل المشروع، والحل الذي تتبعه الكثير من البرامج أسلوب برمجي يعرف بالأمان المبني على المجموعات Role-Based Security Model. في هذا الأسلوب يتم تعريف مجموعات Roles وتحدد الصلاحيات لكل مجموعة، ومن ثم يتم انتساب حسابات المستخدمين إلى هذه المجموعات، فمثلا لو كنا نصمم برنامج لإدارة المدرسة قد تعرف مجموعات مثل: بعد تعريف المجموعة، يمكن البدء بتحديد صلاحياتها مباشرة ومن ثم ربط حسابات المستخدمين بالمجموعات المناسبة، الميزة الرائعة في هذه الطريقة تظهر عندما تنوي تعديل الصلاحيات، فيكفي تعديل صلاحيات تلك المجموعة فقط، وجميع المستخدمين الذين ينتمون لها ستطبق عليهم الصلاحيات الجديدة دون مشاكل. ملاحظة: الترجمة الحقيقية لكلمة Role هي "مهمة" او "مسؤولية"، ولكني أفضل استخدام الترجمة "مجموعة" لأنها بالفعل مجموعة حسابات، بل حتى بعض البرامج تستخدم المصطلح Groups بدلا من Roles، لذلك وجب التنويه. المزيد أيضا، الغالبية الساحقة من التطبيقات التجارية والتي تعتمد على اسلوب الأمان المبني على المجموعات Role-Based Security Model تكون علاقة الحسابات بالمجموعات ن إلى ن Many to Many (وليس 1 إلى ن One to Many)، بمعنى ان نفس الحساب قد ينتمي إلى اكثر من مجموعة تحتوي على اكثر من حساب. ففي مثالنا السابق، قد يأتي مدرس مادة الحاسب وهو فني (يدير النظام) وولي امر طالب ايضا، ليكون لدينا شيئا مثل: جميلة فكرة المجموعات، ولكن! قد تبدو فكرة المجموعات مثيرة ولكنها تحتوي على مشكلة حيرت علماء هندسة البرامج تظهر عند حدوث تعارضات بين صلاحيات المستخدم والمجموعة التي ينتمي لها. فمثلا، نفترض ان الحساب Nada لديها صلاحيات بدخول على شاشة بيانات زائرات المشغل النسائي التي تعمل به، ولكنها تنتمي إلى مجموعة (لنقل فنيون) ليس لها صلاحية: فما هو الحل؟ هل يمكن لـ Nada دخول الشاشة ام لا؟ في الحقيقة لا توجد إجابة موحدة فهنا تختلف المذاهب البرمجية، فطائفة المحافظين يتبعون القاعدة الفقهية "درء المفاسد مقدم على جلب المصالح" فما دام يوجد ((منع)) فالمنع يبطل السماح، بينما نجد عند التيارات المتحررة العكس تماما فالسماح يطغى على المنع، وهناك تيارات وسطية تقول: ان كان الإذن تم تحديده وإعادة تعريفه Override لحساب المستخدم فامضي مع المستخدم، وان لم يعاد تعريفه فابقي مع المجموعة، منطلقين من فكرة ان السيئة تعم والحسنة تخص. قد تبدو فكرة التيار الوسطي مقبولة عند الكثير من عملائنا، ولكن التعارضات لا تحدث بين المجموعة والمستخدم فقط، بل يمكن ان يكون المستخدم ينتمي إلى مجموعتين Roles كلاهما تحتويان على صلاحيات متعارضة! فالمجموعة "س" تسمح للفعل بينما المجموعة "ص" تمنعه، ما هو الحل؟ من وجهة نظري الشخصية، لا يوجد حل يرضى جميع الأطراف لذلك يفضل في مثل هذه الحالات تغيير التوجه الفكري (الصلاحيات الموجهة للحسابات) لهذه الحالات وتطبيق النوع الثاني من الصلاحيات وهي الصلاحيات الموجهة للبيانات. ثانيا: الصلاحيات الموجهة للبيانات في الفقرات السابقة تكلمنا عن أسلوب لتحديد الصلاحيات موجه للحسابات، والذي يتم فيه تحديد الصلاحيات بناء على حسابات المستخدمين او المجموعات التي ينتمون اليها، وهنا نتحدث عن توجه فكري جديد وهو الصلاحيات الموجهة للبيانات Data Oriented Authorization. اسلوب الصلاحيات الموجهة للبيانات تكون فيه عملية تحديد الصلاحيات بناء على المعلومة Data وليس المستخدم، بمعنى كل معلومة وكل محتوى من محتويات نظامك تحدد فيه صلاحياته الخاصة (من يستطيع وماذا يمكن عمله على هذا المحتوى). يتميز هذا الاسلوب بإعطائك حرية كبيرة ومرونة عالية في تخصيص الصلاحيات لكل جزء من اجزاء بيانات نظامك، ولكن يعيبه التعقيد الكبير Complexity الذي يصعب التعامل مع برنامجك، اضف إلى ذلك ان عملية تعديل الصلاحيات ستكون كارثية ان زادت البينات، فتخيل ملايين السجلات في نظامك وكل سجل لديه صلاحياته الخاصة! مع ذلك، يمكنك تسهيل (لاحظ تسهيل وليس الغاء) العيب السابق، وذلك عن طريق توفير ميكانيكية في نظامك تمكن من تعديل الصلاحيات لمجموعة من السجلات دفعة واحدة. اقوى مثال اعرضه عليك يطبق هذا الاسلوب هو نظام التشغيل Windows مع ملفاته، فتحديد الصلاحيات يعتمد على الملفات (المعلومات)، أي كل ملف يمكن اعطائه صلاحيات خاصة: تلاحظ في هذا الاسلوب، انني حددت الملف (المعلومة المطلوبة) ومن ثم قمت بتعديل صلاحياتها بشكل خاص لها، في اعلى الشاشة نضيف الحسابات والمجموعات، وبعد ذلك نحدد صلاحية كل شخص ومجموعة على حده بالنسبة لهذه المعلومة. وبالنسبة لقضية التعارضات، فيمكن اتخاذ قرار خاص بهذه المعلومة واي حساب او مجموعة لها أولوية اعلى (أي مين الي كلمتها تمشي). شخصيات خاصة لتسهيل حياتك عند تطبيق أسلوب الصلاحيات الموجهة إلى البيانات، فيفضل تعريف شخصيات خاصة، لاحظ اني قلت شخصيات خاصة ولم اقل حسابات خاصة، فالاسماء التالية ليست حسابات حقيقة وانما وهمية تمثل حسابات اخرى. • EveryOne نقصد بهذه الشخصية الجميع (أي جميع الحسابات)، فلو كان لدينا سجل نريد ان نسمح لجميع الاشخاص من رؤيته، اضف هذه الشخصية واسمح لها بالقراءة بدلا من اضافة جميع المستخدمين واعطائهم هذه الصلاحية. • Creator هذه الشخصية تمثل الحساب الذي (((أنشأ))) السجل او المعلومة، فكثير من البرامج تريد اعطاء صلاحيات خاصة للشخص الذي قام بانشاء المحتوى مثل المنتديات، كاتب الموضوع يستطيع تحريره. • Updater هذه الشخصية (لا تستخدم الا في حالات نادرة) تمثل الحساب الذي قام ((بتحديث)) المعلومة، قد تعطيه صلاحيات خاصة. • Approver بعض السجلات تتبع اسلوب المنشيء والمؤكد Maker and Approver، وهو اسلوب يشترك فيه اكثر من شخص عند اتمام عملية معينة، هذه الشخصية تمثل الشخص الذي اعتمد ((أكد)) السجل. • Owner هذه الشخصية تختلف مسمياتها من نظام إلى أخر ولكن (على الأرجح) انها تمثل الحساب الذي يتمحور السجل حوله، مثلا عندما تدخل على موقع بنك لاجراء عمليات على حسابك البنكي، فأنت مالك الحساب Account Owner (ولست الذي أنشئه Creator، فالذي أنشئه هو موظف خدمة العملاء) ولديك صلاحيات اعلى بكثير على حسابك. • Object يندر استخدام هذه الشخصية ولكن قد تضيفها، ان كانت شخصية المالك Owner تمثل الشخص الذي يتمحور حوله السجل، فشخصية الـ Object هو المفعول به الذي يتمحور حوله السجل، فمثلا قمت باضافة شخص في مجموعة بريدية، وهذا الشخص هو مفعول به Object قد تعطيه صلاحية لالغاء نفسه من هذه المجموعة. أخيرا، تذكر ان هذه الشخصيات لا تظهر الا في شاشة مبنية على بيانات وليس حسابات مثل الشكل السابق. الصلاحيات الشجرية إلى جانب الأساليب التي ذكرناها، يوجد اسلوب يكون افضل اسلوب عند الانظمة التي تحتوي على بيانات شجرية الترتيب مثل برامج المحاسبة، ادارة الموظفين، الأرشفة الالكترونية، الفهرسة ... الخ: توزيع الصلاحيات في مثل هذه الحالات افضل واسهل ما يكون اعتمادا على الموقع من شجرة البيانات، بمعنى ان تقول ان الحساب "س" لديه صلاحيات كل شيء ما دامت تحت قسم C وما تحته، والمستخدم "ص" صلاحياته مع القسم B وما تحته. الصلاحيات المعتمدة على قيم هنا الكارثة! وهو اصعب نوع من انواع التصاريح ويصعب كثيرا توفير اسلوب او ميكانيكية لعملية تعديله لاحقا، حيث يتم بنائه لحظة كتابة البرنامج Hardcoding. هب مثلا ان شاشة اضافة طلب جديد مصرح للجميع ولكن نريد ان نحدد صلاحيات الحساب بناء على نوع المنتج الذي يسوقه (قيمة) او قيمة المبلغ الاجمالي للفاتورة (قيمة) او جهة الشحن (قيمة) او حتى الوقت الحالي الذي يتم فيه كتابة الطلب (قيمة). ليس هذا فقط، بل يمكن ان نعقد السيناريو أكثر، افترض ان سياسات العمل تقول ان المستخدم لديه صلاحية 10% تخفيض في حالة اختيار المنتج "س"، ولديه صلاحية 15% ان كانت اختار المنتج "ص" شريطة ان يكون بيعه في المنطقة A !! في الحقيقة لا يوجد اسلوب موحد او طريقة قابلة لاعادة الاستخدام لعمل مثل هذا، وقد فكرت مرة في تطبيق نموذج تصميم Design Pattern يعتمد على القيم ولكنه معقد جدا جدا واكتشفت ان كتابة هذه الصلاحيات بشكل مباشر في الشيفرة المصدرية Source Code افضل بكثير من اعتماده! بالنهاية اقول انك لن تصل إلى حل يحل جميع المشاكل فهذا شيء مستحيل، ولكن حاول تقديم كل ما تستطيع عمله لاضافة مرونة في تعديل هذا النوع من الحالات في برنامجك، والله يعينك! مين الي عمل كده؟! بعيدا عن التصاريح (في الحقيقة ليست بذلك البعد فلازلت أتحدث عن الحسابات والأفعال)، من المهم جدا ان يقوم برنامجك بحفظ الأفعال التي تحدث على البيانات، تشمل عملية الحفظ الشخص الذي قام بالعملية، نوعها، وقتها، ووصفها مع ذكر المفعول به ان وجد. هذه العملية تعرف في علم البرامج بـ Auditing او Logging، او Event Tracking. وكلما زادت حساسية المعلومات كلما زادت اهميتها، فعند حدوث أي مصيبة ونود معرف الشخص الذي قام بعمل هذه المصيبة، ننتقل إلى شاشة العمليات ونقوم بعملية بحث او فلترة لنعرف الحساب الذي فعل فعلته. صدقني (ومن تجاربي الشخصية اقولها لك)، حفظ الافعال جزء اساسي من مشروعك، والمضحك في الموضوع انه لا يكلفك سوى جدول واحد فقط مثل هذا: فلا تتجاهل عمله حتى وان لم يطلب منك العميل ذلك، ولكن احذر من التدفق الكبير للبيانات حيث ستحتاج إلى مساحات كبيرة جدا وعليك حذف السجلات القديمة او أرشفتها بعد فترة. حيرت قلبي معاك وأنا بداري واخبي ... قل لي أعمل إيه وياك؟ الذنب ليس ذنبي، هذا هو عالم البرامج المعقد وهذه طلبات العملاء المعقدين! حسنا، يبدو ان موضوع الصلاحيات اكبر مما تتصور، تذكر انه لا يوجد اسلوب او معيار موحد لتطبيقه في جميع البرامج والمشاريع، فكل برنامج حياة وقصة وفيلم خاص بحد ذاته وله طريقة تناسبه لتنظيم عملية الصلاحيات، اهم نقطة اود ان اختم بها مقالي تجدها بعد الفاصلة، الصلاحيات من منطلق توجهها واسنادها تكون اما موجهة إلى الحسابات او إلى البيانات، ففرق بينهما جيدا وحاول تحديد ما هي القوانين Rules التي يفضل ان تكون حسابية التوجه Account Oriented او بيانية التوجه Data Oriented. خذ موضوعات الصلاحيات بجدية اكثر في مشروعك القادم، فهو ليس بالبساطة التي كنت تتخيلها. -- تركي ___________________ (1) حقوق رسمة الكاريكاتور محفوظة للرسام الاستاذ ربيع من جريدة الرياض السعودية 2008.