بالنسبة لتوضيحك أخي kash :
أحب أن أطمئنك بأنه بغض النظر عن البرنامج الذي يستخدمه أي مستخدم للتعامل مع قاعدة بيانات أوراكل ، فإنه لا يستطيع أن يقوم بتنفيذ أي عملية على قاعدة البيانات مالم تكن لديه الصلاحية لذلك.. مهما استعمل أي برنامج .. سوى كان TOAD أو غيره

ولذلك أخــوك (كـDBA) أؤيد نظرية الأخ/الأخت chayah تماماً ..

وإذا استطاع TAOD أو غيره كسر هذه النظرية - أثبت لي ذلك عشان ما أضيع وقتي مع أوراكل

وبالتوفيق أخي ،،،

تم تعديل 3 أكتوبر 200520 سنة بواسطة عروة

أحب أن أطمئنك بأنه بغض النظر عن البرنامج الذي يستخدمه أي مستخدم للتعامل مع قاعدة بيانات أوراكل ، فإنه لا يستطيع أن يقوم بتنفيذ أي عملية على قاعدة البيانات مالم تكن لديه الصلاحية لذلك.. مهما استعمل أي برنامج

اخى عروة انا متأكد من ذلك والا كنت انا كمان ما ضيعت وقتى مع اوراكل
فى المثال الذى ذكرته سابقا ذكرت ان المستخدم user2 له الصلاحيات الكاملة على الجدول وهذا يمكنه من العمل على برامج الفواتير وغيرها بصورة صحيحة. ولكنه اذا اتصل بقاعدة البيانات عن طريق الtoad مثلا سيظل له الصلاحيات التى تمكنه من العبث بمحتويات الجدول.
اعطى مثالا أخر...
بفرض وجود جدول يحتوى على كود الخزنة ورصيدها الحالى
table mony_box
-------------------------
box_code number
sum_in_transactions number
sum_out_transactions number
box_balance number

الوضع الصحيح ان يقوم المستخدم بتحصيل النقدية باستخدام برنامج التحصيل وبهذا يزيد sum_in_transactions ويزيد ايضا رصيد الخزنة وهو box_balance
وان يقوم باستخدام برنامج صرف النقدية بحيث يزيد حقل sum_out_transactions وينقص رصيد الخزنة. فى برنامج الصرف يوجد بعض الاختبارات الهامة جدا وهى عدم امكانية صرف مبلغ اكبر من الموجود فعلا فى الخزنة. وبهذه القاعدة اكون تحكمت فى التعديلات التى تحدث فى البيانات بالرغم من ان المستخدم لايزال يملك صلاحية التعديل.
لكن اذا استطاع المستخدم ان يدخل قاعدة البيانات بواسطة Toad او غيره عن طريق نفس ال account الذى يدخل به على برامج الخزن فسيكمنه تعديل البيانات بأى طريقة لاتخضع للقواعد المعمول بها فى برامج الخزن.

طيب يا عزيزي kash ،، دعني أوضح لك ما فهمته من مثالك ،، وإن فاتني شيء أرجو توضيحة ..
أنت افترضت أن هذا المستخدم له صلاحية الإدخال أو التعديل أو الحذف على جدول محدد (أو صلاحيات متعددة - من نفس النوع - على جداول متتفرقة) .. وكما ذكرتَ أنت تخشى أن يستخدم برنامج آخر - مثل TOAD - لكي يقوم بعمليات على هذه الجداول (بنفس هذه الصلاحيات) لا تخضع لعمليات تحقيق طبقا لبعض القواعد كما هو الحال في برنامج الخزن! تمام؟

إذا كان هذا ما ترمي إليه أخي kash ، أعتقد أنه سبب وجيه ، ومن حقك أن تبحث عن طريقة لمنع هذا المستخدم من استخدام برامج أخرى لكي يتعامل مع قاعدة البيانات.. وأنا لو في مكانك لفعلت نقس الشيء لــــــكن كحل مبدئي !!

لــمـــــــــاذا؟
هل تعلم إنك ممكن تبني عمليات التحقيق هذه (Validations) التي يخضع لها من قبل برنامج الخزن كجزء لا يتجزأ من قاعدة البيانات!! وعليه يمكنك أن تغير (أو بمعنى أدق "تخفف") من أعباء برامج المخزن ، وذلك بأن تتم عمليات التحقيق هذه على مستوى قاعدة البيانات بغض النظر عن البرنامج المستخدم - سوى TOAD أو غيره !

كــــيف؟
بمساعدة الـTriggers + ما يسمى بـVPD والتي تم تطويرها بصورة أفضل في قواعد بيانات أوراكل 10g ( يااااااااااااااااااااااه على الـVPD دي حاجة ماتخلص - رووووووووووعة)

بالمناسبة: إذا حبيت تعرف أكثر عن VPD ممكن تزور المشاركة المشار إليها أدناه، والتي عطرنا بها أستاذنا الجليل الرائع (ربنا ما يحرمنا منه) محمد الشنقيطي (مشرف منتدى إدارة قواعد البيانات هذا)
http://www.araboug.org/ib/index.php?showtopic=7557

وبالتوفيق أخي kash ومشكور جداً على إثارة هذا الموضوع الجميل ,,

تم تعديل 4 أكتوبر 200520 سنة بواسطة عروة

بالمناسبة ،، عندي فكرة كيف تمنع مستخدم محدد (أو أكثر) من استخدام برنامج آخر للتعمال مع قاعدة البيانات ، حتى دون معرفة إسم الرنامج !
وهو باستخدام نفس الـTrigger الموضح أعلاه (مشكور عليه يا أخ/أخت enrique2k)، بس حاول استرجاع إسم المستخدم + إسم البرنامج..
فإذا حاول المستخدم أن يتعامل مع قاعدة البيانات خلال برنامج غير برنامج X
;('RAISE_APPLICATION_ERROR(-20000, 'ERROR! this is not authorized Interface

السلام عليكم
ياريتك أخي ذكرت مشكلتك من الأول
أعتقد أن حل مشكلتك هو كالآتي:
إذا كان مستخدمك هو user2 فغير كلمة السر له ولاتعطها للمستخدم
أنشئ مستخدم آخر user_temp مثلاً
ثم قم بتعديل برنامج الفورم لديك حيث يقوم المستخدم بالدخول إلى برنامج فورم بالمستخدم user_temp
ثم قم من داخل الفورم لديك بعملية login إلى المستخدم user2
طبعاً يجب أن تعطي المستخدم نسخة fmx ولاتعطه نسخة fmb لأنه يمكنه مشاهدة كلمة السر عندها
أيضا في هذا الحل سيلزمك بالنسبة لكلمة سر user2 حالتان:
- إما أن تكون ثابتة في البرنامج ولايمكنك عندئذ تغيير كلمة سر المستخدم user2 ضمن قاعدة البيانات
- لاتكون ثابتة ويتوجب عليك عندئذ أن تخزنها في مكان في أحد جداول user_temp طبعا مع تشفير وتقوم بقراءتها عند الدخول وفك تشفيرها ومن ثم الدخول للمستخدم user2

في كلا الحالتين لن يكون لمستخدم البرنامج لديك إمكانية دخول للمستخدم user2 عبر أي من البرامج: toda أو plsql أو sqlplus أو أي برنامج آخر.

أرجو أن أكون قد أوضحت.

تم تعديل 5 أكتوبر 200520 سنة بواسطة chayah

وعليكم السلام ورحمة الله وبركاته أخي chayah
ربما يكون ما ذكرته حل ، لكن هل تعتقد أنه حل جذري ومستقبلي ؟

* ماذا لو كان عدد المستخدمين كبير ؟!
* كما أن وضع كلمات المرور بصورة ثابتة في البرنامج هذا غير مقبول البته! ،
أما استرجاعها من قاعدة البيانات من جدول تنشئه أنت مخصوص لحفظ كلمات مرور المستخدمين الحقيقيين فإنه لابد من خلق واجهة مخصوص داخل البرنامج (لمدراء النظام) لإدارة هذا الجدول! وذلك بتغيير كلمة مرور المستخدمين على مرحلتين: الأولى على مستوى قاعدة البيانات ، والثانية على مستوى الجدول الذي يحفظ نفس كلمات المرور ولكن بتشفير آخــر !!!!!

هذا غير أن مستوى الجهد سيرتفع في عمليات الصيانة مستقبلاً .

والله أعلـــــــــم ،،

تم تعديل 5 أكتوبر 200520 سنة بواسطة عروة

بعد السلام .
أقترح عليك اقتراحاً وكما فهمت من المشكلة التي تواجهها وهي انك لا تريد وصول اي مستخدم ال قاعدة البايانات وفي نفس الوقت تريده ان يقراء معلومات منها او يعمل عليها access ، هنا اقترح عليك عمل مجموعة من جداول العرض والتي تكون مخفية View table ومن ثم امنح الصلاحيات على هذه الالجداول والتي يتم تكوينها امام المستخدم عند الطلب اي هي بمثابة جداول وهمية .
بهذه الطريقة لن يستطسع المستخدم ان يعرف اين موقع قاعدة البيانات و لا تركيبتها ,
اذا اردت تفاصيل اكثر على هذا الموضوع فأن قمت بهذه التجربة وراسلني عليها.

or you can give the users restricted session privilige and startup the database restricted and enable the restricted session


hope this helps

السلام عليكم ورحمة الله وبركاته ،،،
اخواني أحببت ان اشارك معكم بهذه المعلومات القليلة التي اعرفها عن هذا الموضوع والتي قد ذكر اخواني chayah و عروة بعضها سابقا بشكل مختصر وسأحاول التفصيل فيه قليلا ، بداية نحتاج الى عمل نظام خاص للدخول على تطبيقات الشركة وهذا يحتاج الى شقين :
الشق الأول على مستوى قاعدة البيانات :

--- سيكون لكل مستخدم حسابين الأول في ORACLE DB والثاني في الجداول الخاصة بالنظام والتي سيتم بنائهافي قاعدة البيانات .

--- سيتم بناء جداول في قاعدة البيانات يتم حفظ معلومات مستخدمي البرنامج فيها ومنها على سبيل المثال لا الحصر :

* جدول معلومات المستخدمين الأساسية - رقم المستخدم ,اسم المستخدم ,كلمة المرور ,اسم المستخدم في الأوراكل
* جداول لتخزين معلومات عن شاشات البرنامج كالرقم - الإسم - تابعة لأي تطبيق وغيرها .
* جداول معلومات الصلاحيات الممنوحة للمستخدمين على هذه الشاشات كا
(الدخول - الإستعلام - الإدخال - التعديل والحذف )
* جداول لعمل نظام قوائم بحيث يمكن للمستخدم التنقل بين أجزاء التطبيق المختلفة .

--- بناء views على الجداول لتسهيل الحصول على معلومات بسبب ارتباط الجداول ببعضها البعض.
--- بناء Packages معينة للتعامل مع هذه الجداول .

الشق الثاني على مستوى البرنامج ORACLE FORMS على سبيل المثال :

--- تصميم نظام واجهات خاصة للبرنامج

* واجهة رئيسية للدخول على البرنامج.
* واجهة لإنشاء وإدارة حسابات المستخدمين وسيتم عن طريقها بناء المستخدم الثاني ORACLE DB USER .
* واجهات لإدارة التطبيقات والشاشات التابعة لها .
* واجهات لإدارة الصلاحيات التي ستمنح للمستخدمين على الشاشات .
وغيرها
------------------------------------------
إجراءات دخول المستخدم على النظام
------------------------------------------
سيتمكن المستخدم من الدخول على النظام عن طريق المعلومات التي اعطيت له من قبل مدير النظام والموجودة في الجداول التي تم بنائها وعند دخول المستخدم عن طريق الشاشة الرئيسية للنظام :

- يتم التحقق من وجود معلوماته في الجداول التي تم بنائها سابقا ومقارنتها بمعلوماته في ORACLE DB وفي هذه العملية سنحتاج إلى نظام تشفير وفك التشفير لمقارنة كلمات المرور للحسابين لكي لايتمكن اي مستخدم من محاولة اختراق النظام وعند التأكد من صحة هذه المعلومات يتم الإتصال بالحساب الثاني للمستخدم وهو Oracle user account الذي لايعلم المستخدم بوجوده نهائياً
( وهذا هو ماذكره أخواني chayah و عروة سابقا).

-الخطوة التالية هي فتح الشاشة الرئيسية للتطبيق بحيث لاتظهر إلا القوائم او الشاشات التي لدى المستخدم صلاحيات عليها .
-عند فتح اي شاشة سيتم التأكد من وجود صلاحيات الدخول - الإستعلام - الإدخال - التعديل والحذف .
-تتم إدارة الدخول والتنقل بين أجزاء التطبيق المختلفة عن طريق التأكد من وجود صلاحيات عليها.

بهذه الطريقة نضمن عدم إمكانية المستخدمين من تنفيذ اي عملية الا عن طريق البرنامج الرئيسي ولكن هذه الطريقة تحتاج الى دراسة وتحليل وتصميم ممتاز والى محللين ومصممين ومبرمجين متمكنين
" يعني ناس فاهمة هي بتعمل ايه " ووقت طويل وجهد .

ولكن هل توجد طريقة اخرى اسهل في الإعداد والتطبيق ؟؟؟

آسف على الأطالة
تحياتي وكل عام وانتم بخير

اشكر كل الاخوه الذين ساهموا باخلاص فى حل هذه المشكلة واخص بالذكر الاخ عروة الذى كان معى من البداية والاخ msh على التفصيل الرائع واعتقد ان الحل الذى ذكروه (وهو عمل مستخدم حقيقى على oracle DB ومستخدم صورى فقط لل login ) اعتقد انه الحل الامثل وياريت يكملوا جميلهم ويقولوا كيف يتم التشفير الذى ذكروه.
وشكرا مرة اخرى

وعليكم السلام ورحمة الله وبركاته أستاذي محمد (msh) ، ، ،
الله يعطيك ألف عافية على توضيح الأمـر بتفصيل واضح وجميل كما عودتنا دائماً ..
كما أن ما أشرت إليه في خاتمتك للموضوع كان في رأيي أهم شيئ:

ولكن هذه الطريقة تحتاج الى دراسة وتحليل وتصميم ممتاز والى محللين ومصممين ومبرمجين متمكنين " يعني ناس فاهمة هي بتعمل ايه " ووقت طويل وجهد .

أما بالنسبة لآخر تعليق:

ولكن هل توجد طريقة اخرى اسهل في الإعداد والتطبيق ؟؟؟

بصراحة هذا السؤال يعتبر (ربما) تحدي لخبراء إدارة قواعد البيانات، ولكن على كل حال أعتقد أن مستوى خطورة الدخول أو التعامل مع قاعدة البيانات عن طريق برامج أخرى أصبح متدني مع ظهور تقنيات لحماية قاعدة البيانات بدأت من إصادارات أوراكل 8 و8i وتدنى أكثر مع 10g .. آسف إن كنت قد أشرت لهذا الأمر دون إثبات أو توضيح علمي ! ولكني أعزي ذلك لقلة اتطلاعي حالياً عن قرب لهذه التقنيات ..
لكن إن شاء الله إذا حصل أحدنا على معلومات إضافية بصورة أوضح أكيد ماراح يبخل علينا بها حتى ولو بعد حين - خاصة وأن هذا الموضوع مهم وحساس,,

وإلى الأمام دوما في رعاية الله ، ، ،

السلام عليكم
يوجد حل متبع فى مثل ه>ة الحالات
هو عمل جدوال خاصة يتم حفظ فيها اسماء المستخدمين هما مستخدمين صورين ويتم عمل فورمة دخول على البرنامج له>ة الاسماء يوجد بة محفوظة اسم المستخدم ال>ى يكون علية الاسكيما ويتم عمل packge يتم من خلالة ارسال بارمتر ومدى سامحية المستخدم الصورى
واللة اعلم