من از sql2000 استفاده می کنم یک فرم برای ورود اطلاعات به جدول بانک اطلاعات درست کردم
حالا می خواهم که وقتی کاربر این فرم را باز می کند قبل از هر کاری تشخیص بدم که آیا این کاربر دسترسی به این جدول را دارد یا خیر
من از sql2000 استفاده می کنم یک فرم برای ورود اطلاعات به جدول بانک اطلاعات درست کردم
حالا می خواهم که وقتی کاربر این فرم را باز می کند قبل از هر کاری تشخیص بدم که آیا این کاربر دسترسی به این جدول را دارد یا خیر
این سطح دسترسی رو توی برنامه نویسی تولید کنید نه در بانکی که استفاده می کنید . یا فیلدهایی جهت تعیین دسترسی بسازید . وقتی کاربر رمز و نام کاربری را زد مقدارهای ذخیره شده در فیلدها درون یکسری متغیر public قرار گیرد و در حین اجرای هر فرم چک شود که آیا کاربر اجازه دسترسی دارد یا نه . دسترسیها هم موقع ساخت یک کاربر جدید پرسیده شود
سلام
دستور Sql زیر را اجرا کنید
sp_helprotect 'TableName','UserName'
کاری که خود sqlserver 2000 انجام می دهد را چرا دوباره خودمان باید انجام دهیم؟؟نوشته شده توسط ali_kolahdoozan
شما می تونید در sqlserver کاربر تعریف کنید سطح دسترسی به جدولها حتی به feild ها هم
را هم کنترل کنید.
لینوکس جان فرض کن برنامت روی شبکه اجرا میشه، بعد تو مثلا 100 تا کاربر با سطح های دسترسی مختلف داری.همچنین امکان اضافه کردن کاربر جدید به برنامه یا حذف کاربر یا تغییر سطوح دسترسی رو تو برنامت داری. بهترین کار اینه که بیای توی دیتابیس یه جدول برای سطوح دسترسی بزاری تا از اون سطح اعتبار کاربر رو تعیین کنی. خیلی راحت میشه اینکار رو کرد.
یه مثال خیلی ساده مثلاَ یه جدول با 4 تا فیلد UID,DelI,AddI,ChgI داشته باش. این جدول رو لینک کن به جدول اصلی که اطلاعات کاربرا توش ذخیره شده، بعد مثلاَ وقتی یه کاربر خواست یه مقدار رو پاک کنه، بیاد چک کنه مثلا اگر فیلد AddI یک بود اینکار رو انجام بده در غیر اینصورت نه.
آخرین ویرایش به وسیله HO457 : پنج شنبه 11 اسفند 1384 در 15:24 عصر
سلام
ببین عزیز جان بستگی به کارت داره. ولی من سطح دسترسی در برنامه رو ترجیح میدم.
یک پروژه حقوق و دستمزد داشتم که باید سطح دسترسی هر کاربری که به برنامه LOGIN میکرد رو هم تعیین میکردیم. مثلا فرم1 مثلا به اطلاعات جدول2 و جدول3 نیاز داشت. و فرم2 به اطلاعات جدول1 و جدول2 و جدول4 . حالا کاربری فقط اجازه دیدن فرم 2 رو داره. با این تفاصیل باید Permissionها چگونه باشه؟ تکلیف جدول2 این وسط چیه؟
هر فرم که به یک جدول ارتباط نداره که دسترسی رو در SQL Server بدیم. ممکنه این وسط کلی جدول و فیلد مشترک باشه.
خوشحال میشم بقیه دوستان و مخصوصا جناب زواری در این زمینه اظهار نظر کنند.
در پناه حق موفق باشید و پرتوان
حامد حان، تو اکثر برنامه هایی که دیدم و برنامه هایی که نوشتم سطح دسترسی کاربر به این صورت تعیین میشه که مثلا کاربر امکان گزارش گیری، امکان اضافه کردن سند جدید، امکان حذف اطلاعات، تغییر اطلاعات و ... که برای هر بخش به صورت جدا قابل تعریف هستش. نه که بیاد بر اساس جدول سطح دسترسی رو تعیین کنه.
مثلاَ یه برنامه بود که کاربر فقط میتونست امکان تعریف سند رو داشته باشه. حالا فرض کن من بیام امکان دسترسی کاربر به جدول حسابهای معین رو ببندم، صد در صد کاربر برای اینکه بیاد سند ایجاد کنه باید به اون جدول هم دسترسی داشته باشه.
سلام
جناب HO457، من منظورم این نبود که بیایم بر اساس جدول سطح دسترسی رو بدیم. چون اگه بخواهیم در SQL Server سطح دسترسی رو بدیم فقط میتوانیم روی جداول و فیلدها این کارو کنیم، من همچین مثالی زدم تا جناب لینوکس متوجه بشند که سطح دسترسی در جداول و فیلدها امکان پذیر نیست.
من هم دقیقا منظورم حرف جنابعالی است.
بقیه دوستان نظری ندارند؟
در پناه حق موفق باشید و پرتوان
اگر برای End User شما میخواهید تعیین سطح دسترسی کنید بالطبع باید همین کار رو انجام بدید که دوستان گفتن ؛ یعنی داخل برنامه تعیین کنید .
بحث مفصلی داره اینکه در چه مواردی از داخل برنامه باشه و در چه مواردی هم از داخل برنامه و هم از داخل دیتا بیس .
و عموما چون ما به کاربرامون اجازه نمیدهیم که به بانک دسترسی داشته باشن پس تعیین سطح دسترسی از داخل برنامه هست .
یک کاربر کرمی هم پیدا میشه یه اکسس پروجکت می سازه اگر شما اینجا سطح دسترسی برای کاربر تعیین نکرده باشید این کاربر یک بلایی سر دیتا بیس می یاره که همه زحمت های یک تیم 10 نفره را بر باد میده.
من فکر می کنم میشه با استفاده از تعریف رل ها و کاربرها در دیتابیس سطح دسترسی را مشخص کرد.
مثلا برای مثال شما خوب باید بگم در هر برنامه تعداد رل ها مشخص هست میشه اینطور تصور کرد که یک رل داریم به نام رل1 که کارش ورود دیتا هست یک رل دیگه داریم به نام رل2 که کارش گزارش گیری هست حالا دسترسی ها را برای رل ها تعریف می کنیم رل یک به همه جداول دسترسی خواندن و نوشتن داره و رل2 به بعضی از جداول دسترسی خواندن و به بعضی دسترسی نداره حالا موقع اجرای برنامه بر اساس نام کاربر رل را مشخص کرده و تصمیم می گیرم که این رل حق دسترسی به فرم را دارد یا نه.
من سر این پرسجوها (این کلمه پرسجو پرسیدن و جوستجو کردن به نظرم معادل خوبی هست) مشکل دارم.
آخرین ویرایش به وسیله linux : پنج شنبه 11 اسفند 1384 در 20:53 عصر
سلام
وقتی که سطح دسترسی رو بصورت اس کیو ال سروری تعریف کنیم و توی اون هم یک کاربر اون هم sa داشته باشیم(برنامه با این Permission به دیتابیس وصل بشه)، کاربر چطوری میتونه با اکسس پروجکت دیتابیس رو بر باد بده؟
در پناه حق موفق باشید و پرتوان
سلام مجدد
اینجوری اگه فردا خواستی تغییری در برنامه بدی، علاوه بر تغییر در کد، باید بری Roleهارو هم تغییر بدی.
در پناه حق موفق باشید و پرتوان
زیاد سخت نیست شدنی هست.
این مثال شما مثل این هست که بگیم اگر قرار باشد یک فیلد به یک جدول اضافه شود باید برنامه هم تغیر کند. اگر برنامه تغیر کنه شما فقط لازم هست که یک رل اضافه یا کم کنید یا یک کاربر اضافه و یا کم کنید وقتی شما رل تعریف می کنید سطح دسترسی به جداول را برای رل مشخص می کنید و با مشخص کردن یک رل برای کاربر همه ی دسترسی ها به کاربر هم اعطا می شود. شما فقط باید رل ها را کنترل کنید که زیاد نباید کار سختی باشه.
می خواهم ببینم قبلا کسی این کار را کرده است یا نه؟
خود شما وقتی یک جدول درست می کنید برای دسترسی به فرم ها تقریبا دارید کار هم رل ها را انجام میدهید.اگر کسی مثلا در این مورد دارد ممنون میشم
خود microsoft هم سطح دسترسی از فرم ها رو پیشنهاد میده.(البته به صورت استاندارد)
سلام
من یه جوابی دادم ولی کسی در موردش نظر نداد
به نظر من سطح دسترسی در SqlServer مطمئن تره (هم عقیده با Linux)
و کاملا هم قابل کنترل
ضمنا هیچ کد فوق العاده ای نیاز نیست نوشته بشه
ما برنامه رو خیلی عادی می نویسیم طوری که بدون در نظر گرفتن Permission ها
اطلاعات رو ذخیره کنه در نهایت هنگام ,Update از یک بلوک try Catch استفاده می کنیم
حال اگر Error ای داد چک می کنیم می تونه یکی از این Error ها مربوط به Permission باشه
اونوقت بهش پیغام میدیم که شما مجوز ندارید ...
ما هم نمی گیم Sql Server مطمئن نیست. گفته شده که باتوجه به شرایط و محیط این انتخاب رو انجام بدید. حالا شما با SQL Server راحتی. یه عده با Windows برخی هم مثل خودم ترکیب این دو.
سلام به همه دوستان عزیز،
به طور کلی، دو نوع ساختار در پیاده سازی امنیت روی بانک اطلاعاتی وجود داره. روش اول این هست که تماما از امکانات Security خود SQL Server مثل Permissionها استفاده کنیم. در این حالت مثلا شما با استفاده از یک View میتونین متوجه بشین کاربر فعلی به چه جداولی دسترسی داره:
SELECT * FROM Information_Schema.Tables
و یا اینکه از SP_Helprotect که دوستان اشاره کردند استفاده کنیم.
اما در یک نرم افزار، مثلا ثبت یک سند، شاید به مفهوم دسترسی به چندین جدول باشه. لذا ممکنه ترجیح بدین به جای کنترل دسترسی کاربر به تک تک جدول، موضوع دسترسی اون به بخشهای مختلف نرم افزار رو بررسی کنیم. این روش به Hand-Roled Security معروفه و کاملا رایجه. یکی از راهها اینه که جدولی داشته باشیم و به تعداد بخشها (یا عملیات ممکن) که قصد داریم Permission تعریف کنیم، فیلد اضافه کنیم. حالا هر کاربر، یک رکورد در این جدول برای خودش داره. اگر اختیاری رو قراره بهش بدیم، فیلد مربوطه رو 1 و در غیر اینصورت 0 میکنیم. در این حالت وقتی کاربر Login میکنه، با select کردن یک رکورد (مربوط به کاربر)، میتونیم تمام اختیاراتش رو بدست بیاریم و به تناسبش، بعضی Menuها رو فعال یا غیر فعال کنیم.
سلام آقای ثباتی
من همیشه از روش Hand-Roled Security استفاده میکنم اما اقای لینوکس گفتند که ممکنه یک کاربر با Access Project بیاد تمام اطلاعاتو بر باد بده. میشه در این مورد هم توضیح بدید.
در پناه حق موفق باشید و پرتوان
همه چیز وقتی از طرف خود برنامه نویس تعیین بشه خیلی بهتره، چون چیزی که در میاد کاملاَ دلخواه آدم هست. مثلاَ شما میتونی برای ایجاد کانکشن به بانکت از ویزارد دات نت استفاده کنی یا بیای تمام موارد مورد نیاز رو با کد تعریف کنی. خود مایکروسافت روش دوم رو توصیه میکنه، برای تعیین سطح دسترسی هم همینه، اگه بخوای بیای تو خود SQL دسترسی کاربرها رو محدود کنی صد در صد روش HRS خیلی بهتر جواب میده. یه موضوع دیگه که هست اینه که شما حتی با بانک اکسس هم میتونی یه بانک اطلاعاتی برای برنامت ایجاد کنی که امنیت بسیار بالای داشته باشه (از طریق کد). پس معلوم میشه که امنیت فقط و فقط به برنامه نویس و کسی که مدیر پروژه هست بستگی داره. یه مقاله در این باره داشتم. اگه پیداش کنم میزارم اینجا که همه دوستان بتونن دانلود کنن.
آخرین ویرایش به وسیله HO457 : شنبه 13 اسفند 1384 در 02:37 صبح
سلام به همگی دوستان
به نظر شخصی من این بحث دو قسمت داره : 1 - میزان کارایی و راحتی 2- جنبه تجاری
دوستان چیزی که من همیشه شاهدش بودم و توی بحث ها نیومده بود ، جنبه تجاری موضوع هست .
ببینید وقتی یه مدیر پروژه سیاست برنامه رو مشخص میکنه حتما باید نکات مدیریتی و مالی قضیه رو در نظر بگیره .
فرض کنید شما در سطح Sql Server سطوح دسترسی را تعریف کنیم . با این کار اولا استفاده کننده یه جورایی نیازمند به یک ادمین برای بانک اطلاعاتش میشه . در ثانی میباید جنبه تجاری قضیه و پشتیبانی نرم افزار رو هم در نظر گرفت .
وقتی سطح دسترسی در Sql Server تعریف شده باشه . ادمین کاربری به راحتی می تونه سطوح دسترسی را تغییر بده و مدیریت کنه . این مورد از نظر ساختار برنامه بسیار قویه ولی از نظر تجاری جالب به نظر نمیرسه . چون باید نبض نرم افزار دست تولید کنندش باشه نه استفاده کننده . اگر سطوح دسترسی در برنامه باشه برای هر تغییر یا تکمیلی شما میتوانید درآمد بیشتری نصیب خود یا شرکتتون کنید .
سلام،
به هر حال Access Project هم باید به نحوی به SQL Server لاگین کنه. اگر این لاگین در اختیار کاربر نباشه پس Access Project هم برای کاربر سودی نداره.
از طرفی شما میتونین از کاربر، Username و Password دریافت کنین ولی اینها رو خودتون در جدولی نگه داری کنید و جدای از لاگین های SQL Server باشه. پس کاربر با این Username و Password نمیتونه اصلا به SQL Server وارد بشه.
از طرفی میتونین از امکانات لاگین SQL Server استفاده کنین و بعد از اینکه کاربر Connection رو باز کرد و از Authentication مطمئن شدین، حالا اون رو ببندین و مثلا با sa (دور از چشم کاربر، در برنامه کامپایل شده) مجددا Connection باز کنین. ولی نباید به اون لاگین اولیه در SQL Server هیچ گونه Permission داده باشید. فقط در حد ورود یا اصطلاحا Authentication. در غیر اینصورت همون مشکل Access Project پیش میاد
سلام
ایده جالبیه. ممنون.
در پناه حق موفق باشید و پرتوان
اینجا رو یه نیگاه بندازید:
http://www.barnamenevis.org/sh...434#post198434
قوانین ایجاد تاپیک در تالار
پاسخ با نقل قول