پلت فرم 1C:Enterprise 8 دارای مکانیزم داخلی برای محدود کردن دسترسی به داده ها در سطح رکورد است. شما می توانید اطلاعات کلی در مورد آن را در اینجا بخوانید. به طور خلاصه، RLS به شما این امکان را می دهد که دسترسی به داده ها را بر اساس شرایط خاصی در مقادیر فیلد محدود کنید. برای مثال، می‌توانید دسترسی کاربر به اسناد را بسته به مقدار ویژگی «سازمان» محدود کنید. برخی از کاربران با اسناد سازمان «مدیریت» و برخی دیگر با سازمان «کارخانه لبنیات» کار خواهند کرد. به عنوان مثال.
آماده سازی
ما مثال را در پیکربندی دمو SCP 1.3 پیاده سازی خواهیم کرد. بیایید یک کاربر "Storekeeper" ایجاد کنیم و نقش "Storekeeper" را به او اضافه کنیم.
حالا بیایید مستقیماً به تنظیم حقوق دسترسی در سطح رکورد ادامه دهیم. بیایید به رابط "User Administration" سوئیچ کنیم. در منوی اصلی، "Record-level Access -> Options" را انتخاب کنید. در اینجا، کادر کنار «محدود کردن دسترسی در سطح رکورد بر اساس نوع شی» را علامت بزنید و «سازمان‌ها» را در لیست اشیاء انتخاب کنید.
بنابراین، ما استفاده از RLS را فعال کردیم. حالا باید آن را پیکربندی کنید.
کنترل دسترسی سطح رکورد به طور جداگانه برای هر کاربر یا نمایه مجوز پیکربندی نشده است. RLS برای گروه های کاربر پیکربندی شده است. بیایید یک گروه کاربری جدید اضافه کنیم، آن را "Storekeepers" بنامیم
ترکیب گروه در سمت راست فرم لیستی از کاربران متعلق به این گروه را نشان می دهد. بیایید کاربری را که قبلا ایجاد کردیم به لیست اضافه کنیم. در سمت چپ جدول محدودیت های دسترسی است. در راه اندازی RLS، ما انتخاب کردیم که دسترسی فقط توسط سازمان محدود شود، بنابراین ما فقط یک نوع شی دسترسی را می بینیم. روی دکمه "Access Settings" کلیک کنید. پردازش تنظیم حقوق دسترسی برای گروه فعلی باز خواهد شد.
بیایید سازمان "IPE "Entrepreneur" را به لیست اشیاء دسترسی گروه اضافه کنیم. نوع وراثت حقوق بدون تغییر باقی خواهد ماند. ما حق شئ دسترسی را برای خواندن و نوشتن تنظیم می کنیم. روی "OK" کلیک کنید، تنظیمات آماده است. ما به تازگی RLS را در سطح سازمان پیکربندی کرده ایم.
آنچه کاربر می بیند
بیایید برنامه را تحت کاربر ایجاد شده قبلی راه اندازی کنیم و دایرکتوری "سازمان ها" را باز کنیم. این لیست برای کاربر ما و برای کاربر با حقوق کامل به این صورت خواهد بود:
همانطور که می بینیم، کاربر storekeeper تنها یک سازمان را می بیند که ما به آن دسترسی خواندن داده ایم. همین امر در مورد اسناد، به عنوان مثال، دریافت کالا و خدمات نیز صدق می کند.
بنابراین، کاربر نه تنها سازمان هایی را که دسترسی برای آنها تنظیم نشده است نمی بیند، بلکه نمی تواند اسناد و سایر اشیاء را در پایگاه اطلاعاتی که حقوق آنها در نقش "سازمان" تنظیم شده است بخواند / بنویسد. صفت.
ما به ساده ترین مثال از راه اندازی RLS نگاه کردیم. در مقاله بعدی در مورد پیاده سازی مکانیزم RLS در پیکربندی "Manufacturing Enterprise Management" نسخه 1.3 صحبت خواهیم کرد.
شی پیکربندی "نقش" مجموعه ای از حقوق را برای عملیات (عملیات) روی اشیاء پیکربندی می دهد.
نقش "حقوق کامل".
این فقط یک نقش (از پیش تعریف نشده) است که در آن همه انواع حقوق برای همه اشیاء پیکربندی بررسی می شوند.
چیزی که آن را از سایر نقش‌ها متمایز می‌کند، حضور راست «اداره» است.
اگر حداقل یک کاربر ایجاد شود، سیستم شروع به بررسی وجود حق "اداره" می کند - حداقل یک کاربر باید آن را داشته باشد.
محدودیت های دسترسی در سطح رکورد
امنیت سطح ردیف (RLS) - محدودیت در سطح رکورد.
مکانیسم محدودیت دسترسی به داده به شما امکان می دهد حقوق دسترسی را نه تنها در سطح اشیاء ابرداده، بلکه در سطح اشیاء پایگاه داده نیز مدیریت کنید. برای محدود کردن دسترسی به داده ها می توان از اشیاء زیر استفاده کرد:
- نقش ها،
- پارامترهای جلسه،
- گزینه های کاربردی،
- ماژول های مشترک ممتاز،
- کلمه کلیدی ALLOWED در زبان پرس و جو.
این مکانیسم برای محدود کردن دسترسی به رکوردهای جدول شیء فراداده بر اساس شرایط دلخواه اعمال شده بر مقادیر فیلدهای ردیف این جداول طراحی شده است. به عنوان مثال، برای مشاهده سوابق فقط برای طرفین، سازمان ها و غیره "شما".
اجرای فنی محدودیت های دسترسی در 1C
1C یک درخواست به DBMS ایجاد می کند. خوشه سرور بخشی WHERE را به درخواست اضافه می کند که حاوی متن شرط برای محدود کردن دسترسی از طریق RLS است، سپس این درخواست به DBMS ارسال می شود، داده های استخراج شده به مشتری 1C بازگردانده می شود.
این مکانیسم برای هر درخواستی از مشتری کار می کند:
- در گزارش ها،
- در لیست های پویا و در فرم های لیست معمولی
- در پرس و جوهای سفارشی
چنین پیاده سازی مکانیزم به شدت بر عملکرد تأثیر می گذارد.
راه هایی برای دور زدن محدودیت های دسترسی
در عملیات‌های بزرگ با منابع فشرده (مثلاً پردازش ارسال مجدد سند)، بخشی از کد را می‌توان به ماژول‌های ممتاز منتقل کرد.
آ) ماژول ممتاز یک ماژول رایج با پرچم "ممتاز" در ویژگی ها است.
ویژگی آن این است که کد موجود در آن بدون هیچ گونه کنترل حقوق دسترسی از جمله RLS اجرا می شود.
ب) همچنین ممتازحالت را می توان روشن کرد برای ماژول های شی سند. این کار در ویژگی های سند، پرچم انجام می شود
- درمان ممتاز هنگام انجام
- حالت ممتاز هنگام لغو تراکنش
ب) روش SetPrivilegedMode()
دستور System به شما امکان می دهد بخشی از کد هر ماژول را دارای امتیاز کنید.
از خط بعدی کد، حالت اجرای ممتاز عمل خواهد کرد.
تا خط غیرفعال کردن این حالت یا تا پایان رویه / عملکرد کار می کند
(درست است، واقعی)؛
// هر کدی در اینجا بدون کنترل حقوق و RLS اجرا خواهد شد
SetPrivilegedMode(دروغ )؛ // یا پایان رویه / تابع
تعداد دفعاتی که حالت ممتاز فعال می شود باید با تعداد دفعات غیرفعال شدن آن مطابقت داشته باشد. با این حال، اگر در یک رویه یا عملکرد، حالت ممتاز (یک یا چند بار) روشن شده باشد، اما خاموش نشده باشد، سیستم به تعداد دفعات روشن شدن ناقص در رویه یا عملکرد باقی مانده، به طور خودکار خاموش می شود.
اگر در یک رویه یا تابع یک متد را فراخوانی کند SetPrivilegedMode(نادرست) بیش از فراخوانی روش انجام شده است SetPrivilegedMode(درست است)، سپس یک استثنا پرتاب می شود
تابع PrivilegedMode() اگر حالت ممتاز همچنان فعال باشد، True و اگر کاملاً غیرفعال باشد، False را برمی‌گرداند. این تعداد تنظیمات حالت ممتاز را در یک عملکرد خاص تجزیه و تحلیل نمی کند.
همه رویه ها و توابع فراخوانی شده نیز در حالت ممتاز اجرا خواهند شد.
همچنین امکان شروع یک جلسه ممتاز نیز وجود دارد. این جلسه ای است که در آن حالت ممتاز از همان ابتدای کار سیستم برقرار می شود. علاوه بر این، در طول عملیات روش PrivilegedMode() همیشه True را برمی گرداند و توانایی غیرفعال کردن حالت ممتاز پشتیبانی نمی شود. فقط کاربری که دارای حقوق اداری است (حق مدیریت) می تواند یک جلسه ممتاز را شروع کند. جلسه را می توان با استفاده از سوئیچ خط فرمان راه اندازی برنامه مشتری UsePrivilegedMode یا پارامتر رشته اتصال پایگاه اطلاعاتی prmod آغاز کرد.
این سوال به طور طبیعی مطرح می‌شود: پس چرا اصلاً محدودیت‌های دسترسی را تعیین می‌کنیم، اگر به راحتی بتوان از آن عبور کرد؟
حالت امن.
بله، می‌توانید پردازش خارجی را با حالت اجرای ممتاز بنویسید و داده‌ها را تخلیه/فاسد کنید. برای جلوگیری از این امر، سیستم دارای یک روش زمینه جهانی است
SetSafeMode().
حالت ایمن، در میان چیزهای دیگر، حالت ممتاز را نادیده می گیرد.
باید قبل از فراخوانی برنامه‌نویسی پردازنده‌های خارجی یا صادرات رویه‌ها و توابع از ماژول‌های آنها نصب شود.
هنگام انجام عملیات ممنوعه، یک استثنا در زمان اجرا ایجاد می شود.
علاوه بر این، در سطح تنظیمات نقش، می‌توانید توانایی کاربران برای راه‌اندازی تعاملی گزارش‌ها و پردازش‌های خارجی را غیرفعال کنید.
تنظیم محدودیت های دسترسی
RLS را فقط می توان برای حقوق پیکربندی کرد:
- خواندن (انتخاب)
- افزودن (درج)
- تغییر (به روز رسانی)
- حذف
برای عملیات خواندنو حذف، یک شی ساکن در پایگاه داده باید با محدودیت های دسترسی به داده ها مطابقت داشته باشد.
برای عملیات افزودنمحدودیت دسترسی به داده ها باید با شیئی که برای نوشتن در پایگاه داده برنامه ریزی شده است مطابقت داشته باشد.
برای عملیات تغییرمحدودیت دسترسی به داده باید هم قبل از تغییر (به طوری که شی خوانده شود) و هم بعد از تغییر (به طوری که شی نوشته شود) با شی مطابقت داشته باشد.
برای همه حقوق دیگر چنین گزینه ای وجود ندارد.
اجازه دهید یک محدودیت جدید برای سمت راست "خواندن" فهرست "نامگذاری" اضافه کنیم. لیستی از فیلدهایی که می توانید محدودیت اضافه شده را برای آنها پیکربندی کنید باز می شود.
این بدان معنی است که اگر سعی کنید به فیلدهای علامت زده دسترسی داشته باشید، محدودیت ایجاد می شود، اما اگر سعی کنید به فیلدهای علامت نخورده دسترسی داشته باشید، محدودیت کار نخواهد کرد.
اگر پرچم را انتخاب کنید " سایر زمینه ها"، محدودیت برای تمام فیلدهای جدول پیکربندی می شود، به جز فیلدهایی که محدودیت ها به صراحت برای آنها تنظیم شده است.
*ویژگی: برای حقوق افزودن، تغییر، حذف:
- محدودیت فقط برای همه فیلدها قابل پیکربندی است.
- فقط یک محدودیت می تواند وجود داشته باشد.
برای سمت راست "Read"، می توانید چندین شرط را پیکربندی کنید؛ آنها با عملگر منطقی "AND" ترکیب می شوند.
همه فیلدهای شی داده محدودیت اصلی ممکن است در محدودیت‌هایی بر روی انواع زیر از اشیاء پایگاه داده استفاده نشود:
- در رجیسترهای تجمع، محدودیت‌های دسترسی فقط می‌توانند شامل اندازه‌گیری‌های هدف اصلی محدودیت باشند.
- در ثبت‌های حسابداری، محدودیت‌ها فقط می‌توانند از اندازه‌گیری ترازنامه هدف اصلی محدودیت استفاده کنند
اگر در شرایط دسترسی محدود به داده‌های رجیستر انباشت در گردش، از اندازه‌گیری‌هایی استفاده شود که در مجموع‌ها لحاظ نشده‌اند، هنگام دسترسی به جدول مجازی چرخش‌ها، از مجموع‌های ذخیره‌شده استفاده نمی‌شود و درخواست کاملاً مطابق با آن انجام می‌شود. جدول حرکت
مکانیزم برای اعمال محدودیت های دسترسی.
هر عملیاتی بر روی داده های ذخیره شده در پایگاه داده در 1C:Enterprise در نهایت منجر به تماس با پایگاه داده با برخی درخواست برای خواندن یا تغییر داده ها می شود. در فرآیند اجرای کوئری ها در پایگاه داده، مکانیسم های داخلی 1C:Enterprise محدودیت های دسترسی را اعمال می کند. که در آن:
- لیستی از حقوق ایجاد می شود(خواندن، افزودن، اصلاح، حذف)، فهرستی از جداول پایگاه داده، و فهرستی از فیلدهای استفاده شده توسط این پرس و جو.
- از همه نقش های کاربر فعلی محدودیت های دسترسی انتخاب شده استبه داده ها برای همه حقوق، جداول و فیلدهای مربوط به درخواست. علاوه بر این، اگر نقشی محدودیتی در دسترسی به داده های یک جدول یا فیلد نداشته باشد، به این معنی است که مقادیر فیلدهای مورد نیاز از هر رکوردی در این جدول موجود است. به عبارت دیگر، عدم وجود محدودیت دسترسی به داده به معنای وجود محدودیت WHERE IS Truth است.
- مقادیر فعلی تمام پارامترهای جلسه و گزینه های عملکردی را بازیابی می کندشرکت در محدودیت های انتخاب شده
برای به دست آوردن مقدار پارامتر جلسه یا گزینه ویژگی، کاربر فعلی نیازی به مجوز برای بدست آوردن آن مقدار ندارد. با این حال، اگر مقدار برخی از پارامترهای جلسه تنظیم نشده باشد، خطایی رخ می دهد و کوئری پایگاه داده اجرا نمی شود.
محدودیت های حاصل از یک نقش با استفاده از عملیات AND ترکیب می شوند.
محدودیت های ناشی از نقش های مختلف با استفاده از عملیات OR ترکیب می شوند.
شرایط ساخته شده به پرس و جوهای SQL اضافه می شوند که با آن 1C: Enterprise به DBMS دسترسی دارد. هنگام دسترسی به داده ها از شرایط محدودیت دسترسی، بررسی حقوق انجام نمی شود (نه برای اشیاء ابرداده و نه برای اشیاء پایگاه داده). علاوه بر این، مکانیسم اضافه کردن شرایط بستگی به روش انتخابی عملکرد محدودیت‌های "همه" یا "مجاز" دارد.
*ویژگی: اگر کاربر به چندین نقش با محدودیت های پیکربندی شده در سطح رکورد برای یک شی دسترسی داشته باشد، در این حالت شرایط محدودیت ها با استفاده از عملیات منطقی "OR" اضافه می شود. به عبارت دیگر، قدرت های کاربر تجمعی است.
این منجر به نتیجه زیر می شود: اجازه ندهید شرایط محدود کردن دسترسی به یک شی در نقش های مختلف قطع شود، زیرا در این صورت متن درخواست بسیار پیچیده می شود و این بر عملکرد تأثیر می گذارد.
روش "همه چیز".
هنگام اعمال محدودیت ها با استفاده از روش "همه"، شرایط و فیلدهایی به پرس و جوهای SQL اضافه می شود تا 1C:Enterprise بتواند اطلاعاتی در مورد اینکه آیا در هنگام اجرای پرس و جو پایگاه داده، داده هایی که برای یک کاربر خاص ممنوع بوده است استفاده شده است یا خیر، به دست آورد. اگر از داده های ممنوعه استفاده شده باشد، درخواست به دلیل نقض دسترسی خراب می شود.
اعمال محدودیت های دسترسی با استفاده از روش "همه" به صورت شماتیک در شکل ارائه شده است:
روش "مجاز".
هنگام اعمال محدودیت ها با استفاده از روش "مجاز"، شرایطی به پرس و جوهای SQL اضافه می شود تا رکوردهایی که برای کاربر فعلی ممنوع هستند، بر نتیجه پرس و جو تأثیر نگذارند. به عبارت دیگر، زمانی که محدودیت‌ها در حالت مجاز اعمال می‌شوند، رکوردهای ممنوعه برای یک کاربر مفقود شده در نظر گرفته می‌شوند و بر نتیجه عملیات تأثیری نمی‌گذارند، که به صورت شماتیک در شکل ارائه شده است:
در زمانی که 1C:Enterprise به پایگاه داده دسترسی پیدا می کند، محدودیت های دسترسی به داده ها بر روی اشیاء پایگاه داده اعمال می شود.
در نسخه سرویس گیرنده-سرور 1C:Enterprise، محدودیت هایی بر روی سرور 1C:Enterprise اعمال می شود.
با این حال، اگر در یک پرس و جو به جدولی اشاره کنیم که محدودیت های دسترسی برای آن پیکربندی نشده است، اما حاوی ارجاعاتی به ردیف های جدول با محدودیت های پیکربندی شده باشد، این گزینه (ALLOWED) کار نخواهد کرد. در این حالت، نتیجه پرس و جو نمایش داده می شود:<Объект не найден>......" به جای مقدار فیلد مرجع.
اگر در حال توسعه گزارش یا پردازش با استفاده از پرس و جوهای پیکربندی استاندارد یا سفارشی هستید، همیشه پرچم "مجاز" را بررسی کنیدتا گزارش کار کند تحت هر کاربریبا هر مجموعه ای از حقوق
در مورد خواندن شی از داده ها از پایگاه داده، امکان تنظیم پرچم "مجاز" وجود ندارد. بنابراین لازم است با در نظر گرفتن محدودیت های احتمالی حقوق دسترسی، انتخاب ها را برای خواندن شی پیکربندی کنیدبرای کاربر هیچ وسیله ای برای به دست آوردن تنها داده های مجاز در فناوری شی وجود ندارد.
مهم است که اگر یک پرس و جو کلمه کلیدی ALLOWED را مشخص نمی کند، تمام انتخاب های مشخص شده در آن پرس و جو نباید با هیچ یک از محدودیت های خواندن در مورد اشیاء پایگاه داده استفاده شده در پرس و جو تضاد داشته باشد. علاوه بر این، اگر پرس و جو از جداول مجازی استفاده می کند، باید انتخاب های مربوط به خود جداول مجازی اعمال شود.
تمرین 1. Query builder در تنظیمات RLS.
بیایید متن بخش "WHERE" را در پرس و جو به دایرکتوری بنویسیم. می توانید از سازنده پرس و جو استفاده کنید.
طراح ظاهری برهنه دارد.
برگه "جدول".
جدول اصلی، جدول شی ای خواهد بود که محدودیت برای آن پیکربندی می شود.
همچنین می‌توانید جداول دیگری را انتخاب کنید و اتصالات مختلفی را بین آنها در برگه «روابط» تنظیم کنید.
برگه "شرایط"
در اینجا می توانید شرایط محدودیت دسترسی واقعی را پیکربندی کنید
بیایید شرایطی را به ویژگی "Price" فهرست نامگذاری برای حق "خواندن" به تمام فیلدهای جدول اضافه کنیم.
"نامگذاری WHERE نامگذاری. قیمت > 500"
بیایید ببینیم این قانون ساده چگونه کار می کند. جدول دایرکتوری شامل عناصر زیر است:
پس از تنظیم یک محدودیت دسترسی، جدول فقط عناصری را نشان می دهد که شرایط را برآورده می کنند:
گروه ها نیز ناپدید شدند. بیایید متن محدودیت را تغییر دهیم
نامگذاری WHERE نامگذاری. قیمت > 500
OR Nomenclature.This یک گروه است"
خوب، حالا این چیزی است که شما نیاز دارید.
اگر نمایش فیلد "کد" را در تنظیمات لیست حذف کنید، تمام عناصر دایرکتوری نمایش داده می شوند، به عنوان مثال. محدودیت کار نکرد اگر فیلد «کد» را برای نمایش تنظیم کنید، محدودیت کار خواهد کرد.
در این حالت، علیرغم اینکه عنصر دایرکتوری در فیلد لیست قابل مشاهده است، فرم آن را نمی توان باز کرد زیرا محدودیتی در ویژگی پیکربندی شده است. در یک درخواست دلخواه هم همین اتفاق می افتد: وقتی سعی می کنید یک ویژگی "محدود" را دریافت کنید، یک خطای دسترسی رخ می دهد.
اگر سعی کنید اعتبارنامه "محدود" را به صورت برنامه ریزی شده دریافت کنید، یک خطای دسترسی نیز ایجاد می شود.
علاوه بر این، دسترسی به هیچ فیلد یک شی از طریق پیوند امکان پذیر نخواهد بود، زیرا هنگام دریافت پیوند، سیستم کل شی را می خواند و اگر حاوی جزئیات "محدود" باشد، شی خوانده نمی شود.
بنابراین، هنگام کار به صورت برنامه‌نویسی با آبجکت‌های پایگاه داده، باید محدودیت‌های احتمالی در سطح رکورد را در نظر داشته باشید و تمام داده‌های شی لازم را با درخواست به دست آورید و سپس آنها را در یک ساختار قرار دهید یا بخشی از کد را در یک ماژول ممتاز اجرا کنید.
پس از تنظیم محدودیت دسترسی، نمایش خط در لیست حقوق تغییر کرد - خاکستری شد و یک نماد ظاهر شد.
محدودیت در هنگام تنظیم دسترسی (RLS).
- هیچ بخش خلاصه وجود ندارد.
- جداول ثبت مجازی قابل دسترسی نیست.
- شما نمی توانید به صراحت از پارامترها استفاده کنید.
- می تواند در پرس و جوهای تودرتو استفاده شود any>/span> ابزارهای زبان پرس و جو به جز:
- عملگر در سلسله مراتب;
- پیشنهادات نتایج؛
- نتایج پرس و جو تو در تو نباید شامل قطعات جدول باشد>/span>;
- جداول مجازی، به ویژه مانده ها و گردش مالی
تمرین 2. نامگذاری با قیمت فعلی.
اگر نیاز دارید مواردی را با قیمت فعلی بیشتر از یک مقدار مشخص، مثلاً 100 نمایش دهید، محدودیت دسترسی ایجاد کنید.
راه حل:
ما در حال اضافه کردن یک قانون محدودیت دسترسی جدید برای فهرست "نامگذاری" با سمت راست "خواندن" هستیم.
"فیلدهای دیگر" را انتخاب کنید.
در سازنده یک پرس و جوی تودرتو اضافه می کنیم. در آن، جدول ثبت اطلاعات "قیمت کالا" را انتخاب کنید.
برگه "سفارش" وجود ندارد - این یکی از ویژگی های طراح پرس و جو برای ایجاد یک درخواست محدودیت دسترسی است.
در برگه "پیشرفته"، "اول 999999999" را تنظیم کنید، تب "سفارش" ظاهر می شود.
ما ترتیب را بر اساس قسمت "پریود" به ترتیب نزولی تنظیم کردیم.
سپس یک ارتباط بین جدول اصلی و زیرپرسوجو با مرجع برقرار می کنیم.
الگوهای محدودیت دسترسی.
تمرین 3. محدودیت در "طرف مقابل" بر اساس مقدار در یک ثابت.
بیایید یک محدودیت دسترسی برای دایرکتوری Counterparties بر اساس مقدار ذخیره شده در Constant تنظیم کنیم.
علاوه بر این، باید برای همه اشیایی که از فهرست "Counterparties" در جزئیات استفاده می کنند، محدودیتی ایجاد کنید.
راه حل
برای دایرکتوری "Counterparties"، با افزودن یک جستجوی تودرتو به ثابت در بخش "شرایط"، محدودیتی برای سمت راست "خواندن" ایجاد می کنیم. فراموش نکنید این یک گروه است.
ما مشکلی را می بینیم، دایرکتوری Counterparties به درستی فیلتر شده است، و تمام اسناد با ویژگی "Counterparty" نمایش داده می شوند، برخی از آنها دارای پیوندهای "شکسته" در ویژگی "Counterparty" هستند.
اکنون باید محدودیت‌های دسترسی را برای همه اشیایی که از پیوند «حساب‌ها» استفاده می‌کنند، پیکربندی کنید. بیایید آنها را با استفاده از سرویس "جستجوی پیوندهای یک شی" پیدا کنیم.
بیایید متن شرط RLS را از فهرست "Counterparties" کپی کرده و کمی تغییر دهیم. این کار باید به تعداد دفعات یافتن اشیاء انجام شود.
یا از الگوی محدودیت دسترسی برای جلوگیری از مشکلات تکراری کد استفاده کنید.
الگوهای محدودیت دسترسی در سطح نقش پیکربندی می‌شوند و می‌توانند برای هر شیئی در نقش ویرایش شده استفاده شوند.
شما می توانید هر قطعه از متن محدودیت دسترسی را به الگو اضافه کنید. الگو با استفاده از نماد "#" فراخوانی می شود. برای مثال #TemplateCounterparty.
از طریق # در 1C دستورالعمل ها برای پیش پردازنده نوشته می شود. در زمینه اجرای تنظیمات محدودیت دسترسی، پلتفرم متن تماس الگو را با متن الگو جایگزین می‌کند.
بیایید متن را بعد از کلمه WHERE به الگوی "Contractor Template" اضافه کنیم، به جز متن مربوط به EtoGroup.
پارامترها در قالب های محدودیت دسترسی
بیایید به حل مشکل 2 ادامه دهیم.
مشکل اکنون این است که جدول اصلی در فهرست "طرف مقابل"، در سند "فاکتور رسید" نامیده می شود. فیلدی که در دایرکتوری بررسی می شود "پیوند" نامیده می شود و در سند "Counterparty" نامیده می شود.
بیایید نام جدول اصلی در متن الگو را به "#CurrentTable" تغییر دهیم.
"#CurrentTable" یک پارامتر از پیش تعریف شده است.
و از طریق یک نقطه، تعداد پارامتر ورودی را نشان می دهیم - “.#Parameter(1)
"#Parameter" نیز یک مقدار از پیش تعریف شده است. می تواند شامل تعداد دلخواه پارامترهای ورودی باشد. آنها با شماره سریال خطاب می شوند.
در متن محدودیت های دسترسی برای دایرکتوری موارد زیر را مشخص می کنیم:
برای سند زیر:
“فروش کالا WHERE #TemplateCounterparty (“Counterparty”)”
هنگام فراخوانی یک الگوی محدودیت دسترسی، پارامترها باید فقط به عنوان یک رشته، یعنی در نقل قول به آن ارسال شوند.
جدول اصلی - نامگذاری
متن قالب این است:
#CurrentTable WHERE #CurrentTable.#Parameter(1) = #Parameter(2)
متن الگو شامل بخشی از متن در زبان محدودیت دسترسی به داده است و ممکن است حاوی پارامترهایی باشد که با استفاده از نماد "#" برجسته می شوند.
نماد "#" ممکن است به دنبال آن باشد:
- یکی از کلمات کلیدی:
- پارامتری که به دنبال آن تعداد پارامتر در قالب داخل پرانتز قرار دارد.
- CurrentTable - نشان دهنده درج نام کامل جدولی است که محدودیت برای آن ساخته شده است.
- CurrentTableName- نشان دهنده درج در متن نام کامل جدول (به عنوان یک مقدار رشته، در نقل قول) است که دستورالعمل به آن اعمال می شود، در نسخه فعلی زبان داخلی؛
- NameCurrentAccessRight- حاوی نام حقی است که محدودیت فعلی برای آن اجرا شده است: READ, ADD, INSERT, CHANGE, UPDATE, DELETE.
- نام پارامتر الگو - به معنای درج محدودیت پارامتر الگوی مربوطه در متن است.
- نماد "#" - نشان دهنده درج یک کاراکتر "#" در متن است.
یک عبارت محدودیت دسترسی ممکن است شامل موارد زیر باشد:
- قالب محدودیت دسترسی که در قالب مشخص شده است #TemplateName("مقدار پارامتر الگو 1"، "مقدار پارامتر الگو 2"،...). هر پارامتر الگو در دو گیومه محصور شده است. اگر نیاز به تعیین یک کاراکتر نقل قول دوگانه در متن پارامتر دارید، باید از دو نقل قول استفاده کنید.
- تابع StrContains (WhereWeLook، WhatWeLook). این تابع برای جستجوی رخداد رشته WhatWeLook در رشته WhereWeLook طراحی شده است. اگر رخداد پیدا شود True و در غیر این صورت False را برمی‌گرداند.
- عملگر + برای الحاق رشته است.
برای سهولت در ویرایش متن الگو، در تب Restriction templates در فرم نقش، روی دکمه Set template text کلیک کنید. در گفتگوی باز شده، متن الگو را وارد کرده و روی OK کلیک کنید.
آنها را نمی توان با استفاده از نصب کرد SetParameter()یا چیزی مشابه
پارامترها در این مورد عبارتند از:
- گزینه های جلسه
- گزینه های کاربردی
خواندن پارامترهای جلسه در یک درخواست محدودیت دسترسی در حالت ممتاز رخ می دهد، یعنی بدون کنترل حقوق کار با آنها.
تمرین 4. دسترسی به طرف مقابل "شما".
لازم است محدودیت دسترسی کاربر فعلی به طرف مقابل "خود" را پیکربندی کنید.
دایرکتوری «کاربران»، دایرکتوری «طرفداران»، اسنادی با جزئیات «طرف مقابل» وجود دارد.
کاربر فعلی باید داده‌ها را فقط برای طرف‌هایی ببیند که برای آنها ارتباط برقرار شده است.
ارتباطات نیز باید پیکربندی شود.
گزینه های ممکن:
ایجاد ارتباط بین کاربر و طرف مقابل
- جزئیات در دایرکتوری طرف مقابل
- ثبت اطلاعات
راه حل های ممکن برای مشکل:
- ذخیره یک کاربر در یک ثابت گزینه بدی است؛ ثابت برای همه کاربران در دسترس است.
- ذخیره یک آرایه ثابت از طرف مقابل کاربر فعلی در پارامترهای جلسه گزینه خیلی خوبی نیست؛ طرف مقابل می تواند زیاد باشد.
- ذخیره در پارامترهای جلسه کاربر فعلی و سپس درخواست لیست طرف مقابل "او" گزینه قابل قبولی است.
- گزینه های دیگر
راه حل.
بیایید یک پارامتر جلسه جدید "CurrentUser" ایجاد کنیم و آن را در ماژول جلسه پر کنیم.
بیایید یک ثبت نام از اطلاعات "تطابق مدیران و پیمانکاران" ایجاد کنیم
بیایید یک نقش جدید و در آن یک محدودیت دسترسی جدید برای سند "فاکتور" ایجاد کنیم.
در متن درخواست، جدول اصلی را با ثبت اطلاعات Account = Account و Manager = &CurrentUser متصل می کنیم. نوع اتصال داخلی
در صورت امکان، بهتر است از پرس و جوهای تودرتو در متون محدودیت دسترسی اجتناب کنید، زیرا هر بار که داده ها از این شی از پایگاه داده خوانده می شوند، اجرا می شود.
بررسی - محدودیت ها کار می کنند
*ویژگی: اگر لیست طرف مقابل کاربر را در ثبت تغییر دهید، محدودیت های دسترسی بلافاصله بدون راه اندازی مجدد جلسه کاربر اعمال می شود.
تمرین 5. تاریخ ممنوعیت تغییرات.
لازم است محدودیتی در ویرایش داده ها قبل از تاریخ تعیین شده برای ممنوعیت تغییرات اعمال شود.
شما باید آن را برای کاربران محدود کنید.
بیایید یک ثبت اطلاعات "تاریخ ممنوعیت تغییرات" با بعد کاربر، منبع تاریخ ممنوعیت ایجاد کنیم.
بیایید منطق راه حل را به این صورت بسازیم:
- اگر کاربری مشخص نشده باشد، ممنوعیت برای همه کاربران اعمال می شود
- اگر محدودیتی برای همه کاربران و محدودیتی برای یک کاربر خاص وجود داشته باشد، محدودیت برای یک کاربر خاص و برای دیگران طبق اصل کلی اعمال می شود.
بدیهی است که چنین محدودیتی را می توان برای اشیاء پایگاه داده ای که موقعیت خاصی در محور زمان دارند، پیکربندی کرد. میتونه باشه
- مستندات
- ثبت اطلاعات دوره ای
بیایید یک نقش جدید "محدودیت ها بر اساس تاریخ ممنوعیت تغییرات" ایجاد کنیم.
در آن، برای سند "فاکتور" برای "تغییر" مناسب، یک محدودیت دسترسی جدید اضافه می کنیم.
تنظیمات را برای همه فیلدها مشخص می کنیم.
متن محدودیت به شرح زیر است:
ReceiptInvoice FROM Document.ReceiptInvoice AS ReceiptInvoice
تاریخ ممنوعیت را تغییر دهید تاریخ ممنوعیت به عنوان تاریخ ممنوعیت
از جانب
پیوستن داخلی (انتخاب کنید
MAX (تغییر تاریخ های ممنوعه. کاربر) به عنوان کاربر
از جانب
ثبت اطلاعات تاریخ های ممنوعیت تغییرات به عنوان تاریخ های ممنوعیت تغییرات
جایی که
(تغییر تاریخ های ممنوعه. کاربر = &CurrentUser
یا تاریخ‌های ممنوعه Changes.User = VALUE(Directory.users.EmptyLink))) AS VZ_User
بر اساس تاریخ ممنوعیت تغییرات. کاربر = VZ_User.User) AS NestedQuery
فاکتور دریافت نرم افزار. تاریخ > استعلام تودرتو. تاریخ ممنوعیت
بیایید بررسی کنیم - محدودیت کار می کند.
استفاده از دستورالعمل های پیش پردازنده
#اگر شرط 1 #پس
درخواست قطعه 1
#ElseIf Condition2 #سپس
درخواست قطعه 2
#در غیر این صورت
درخواست قطعه 3
#پایان اگر
در شرایط، می توانید از عملیات منطقی (و، یا، نه، و غیره) و دسترسی به پارامترهای جلسه استفاده کنید.
این رویکرد در زمینه ایجاد محدودیت های دسترسی از این جهت راحت است که بسته به شرایط، متن درخواست کوتاه تری کامپایل می شود. یک پرس و جو ساده تر سیستم را کمتر بارگذاری می کند.
نکته منفی این است که سازنده پرس و جو با چنین متنی کار نمی کند.
*خصوصیات عجیب و غریب :
برخلاف دستورالعمل های پیش پردازنده زبان داخلی در متون محدودیت دسترسی، قبل از اپراتور باید یک هش قرار دهید - #Then
تمرین 6. «استفاده از RLS» را تغییر دهید
بیایید سیستم محدودیت‌های خود را با سوئیچی تکمیل کنیم که استفاده از محدودیت‌ها را در سطح رکورد روشن/خاموش می‌کند.
برای انجام این کار، یک پارامتر ثابت و یک جلسه با نام “UseRLS” اضافه می کنیم.
بیایید در Session Module بنویسیم تا مقدار پارامتر session را از مقدار ثابت تنظیم کنیم.
بیایید کد زیر را به تمام متون محدودیت دسترسی اضافه کنیم:
"#If &UseRLS #Then….. #EndIf"
ما بررسی می کنیم - همه چیز کار می کند.
با این حال، اکنون پس از روشن کردن پرچم "استفاده از رادار"، تغییرات بلافاصله اعمال نمی شوند. چرا؟
زیرا پارامتر session هنگام شروع جلسه تنظیم می شود.
زمانی که یک مقدار ثابت جدید نوشته می‌شود، می‌توان مقدار پارامتر جلسه را تنظیم کرد که بازنشانی شود، اما این فقط برای جلسه کاربر فعلی کار می‌کند. باید از سایر کاربران خواسته شود که سیستم را مجددا راه اندازی کنند.
پایان قسمت اول.
مکانیسم RLS در 1C (محدودیت‌های دسترسی سطح رکورد) به توسعه‌دهنده اجازه می‌دهد تا انتخاب‌ها و شرایط خود را مستقیماً روی جداول پایگاه داده تنظیم کند. چنین محدودیت هایی ممکن است برای خواندن، افزودن، اصلاح و حذف اعمال شود.
عیب اصلی روش کاهش عملکرد سیستم به عنوان یک کل است. نکته این است که انتخاب های اضافی به پرس و جوهای اصلی اضافه می شوند که به صورت پویا داده ها را بازیابی می کنند. هر بار که کاربر به هر داده ای در پایگاه اطلاعاتی که دارای محدودیت است دسترسی پیدا می کند، برنامه با اجرای یک پرس و جو، بررسی را انجام می دهد.
با وجود این اشکال قابل توجه، مکانیسم RLS کاملا راحت و انعطاف پذیر است. با کمک آن می توانید سیستم را به گونه ای پیکربندی کنید که یک کاربر هیچ چیز "غیر ضروری" را نبیند. محدود کردن دسترسی کارمندان خود، به خصوص اگر تعداد آنها زیاد باشد، بسیار سازنده است. نکته بی اعتمادی زیاد نیست، بلکه محافظت در برابر خطاهای تصادفی و عامل انسانی است. هرچه داده های کمتری در دسترس باشد، کار با آن آسان تر است و گیج نمی شود.
در یکی از مقالات خود، ما قبلاً تا حدی به موضوع محدود کردن دسترسی در سطح رکورد پرداختیم. در این مورد، پیکربندی عمیق تری از سوی توسعه دهنده در نظر گرفته می شود.
پیکربندی محدودیت‌های دسترسی سطح ورودی
پیکربندی و توسعه رادار در پیکربندی 1C انجام می شود. برای این کار ابتدا یک نقش در شاخه ابرداده ایجاد کنید.
در برگه «قالب‌های محدودیت»، می‌توانید یک یا چند الگو ایجاد کنید. از نظر ظاهری، آنها عملاً هیچ تفاوتی با درخواست های معمول ندارند.
در مرحله بعد، به برگه "حقوق" نقشی که می خواهید برای آن محدودیت تعیین کنید بروید. برای راحتی، می توانید از طراح پرس و جو استفاده کنید که تنها دارای دو تب "جدول و فیلدها" و "شرایط" است.
همانطور که در تصویر زیر می بینید، ما فقط یک محدودیت با متن اضافه کرده ایم:
WHEREProductGroup = &ProductGroup
در نتیجه، زمانی که کاربر به دایرکتوری "Nomenclature" دسترسی پیدا می کند، برنامه یک خط با این شرایط را به همه درخواست ها اضافه می کند.
تمام تنظیمات حقوق کاربر که در چارچوب این مقاله انجام خواهیم داد در بخش 1C 8.3 "اداره" - "تنظیمات کاربر و حقوق" قرار دارند. این الگوریتم در اکثر پیکربندی ها در فرم های مدیریت شده مشابه است. برنامه حسابداری 1C به عنوان مثال استفاده خواهد شد، اما تنظیم حقوق در سایر برنامه ها (1C UT 11، 1C ZUP 3، 1C ERP) دقیقاً به همین روش انجام می شود.
بیایید به بخش "کاربران" در پنجره تنظیمات برویم. در اینجا ما دو لینک می بینیم: "کاربران" و "تنظیمات ورود". اولین آنها به شما امکان می دهد مستقیماً به لیست کاربران این پایگاه اطلاعاتی بروید. قبل از ایجاد یک کاربر جدید، اجازه دهید به تنظیمات احتمالی ورود (هیپرلینک در سمت راست) نگاه کنیم.
در این فرم تنظیمات، می توانید پیچیدگی رمز عبور (حداقل 7 کاراکتر، محتوای اجباری انواع کاراکترها و غیره) را پیکربندی کنید. همچنین می توانید طول رمز عبور، مدت اعتبار آن را مشخص کنید و اگر کاربران برای مدت معینی فعال نبودند، از ورود به برنامه منع کنید.
اکنون می توانید مستقیماً به افزودن یک کاربر جدید به 1C ادامه دهید. این را می توان با کلیک بر روی دکمه "ایجاد"، همانطور که در تصویر زیر نشان داده شده است، انجام داد.
اول از همه، ما نام کامل - "دیمیتری پتروویچ آنتونوف" را نشان می دهیم و فردی را از دایرکتوری مربوطه انتخاب می کنیم. در اینجا می توانید بخشی را که کارمند ما در آن کار می کند نیز مشخص کنید.
نام ورود به سیستم "AntonovDP" به طور خودکار به عنوان مخفف نام کامل "Dmitry Petrovich Antonov" جایگزین شد. بیایید یک رمز عبور و احراز هویت 1C Enterprise تنظیم کنیم. در اینجا همچنین می توانید مشخص کنید که آیا این کاربر می تواند رمز عبور خود را به طور مستقل تغییر دهد یا خیر.
فرض کنید می‌خواهیم دیمیتری پتروویچ آنتونوف هنگام راه‌اندازی این پایگاه اطلاعاتی در لیست انتخابی موجود باشد. برای انجام این کار، باید چک باکس را در مورد "نمایش در لیست انتخاب" تنظیم کنید. در نتیجه، پنجره مجوز هنگام شروع برنامه مانند شکل زیر به نظر می رسد.
بیایید به یکی دیگر از تنظیمات مهم در کارت فهرست کاربر توجه کنیم - "ورود به برنامه مجاز است." اگر تاخیر تنظیم نشده باشد، کاربر به سادگی نمی تواند وارد این پایگاه اطلاعاتی شود.
حقوق دسترسی
پس از پر کردن تمام داده های کارت کاربر - دیمیتری پتروویچ آنتونوف، آنها را یادداشت می کنیم و همانطور که در شکل زیر نشان داده شده است به تنظیم حقوق دسترسی می رویم.
لیستی از پروفایل های دسترسی که قبلاً وارد برنامه شده بودند، قبل از ما باز شد. کادرهای مورد نیاز را علامت بزنید.
دسترسی به پروفایل های گروه
پروفایل های گروه دسترسی را می توان از فرم راه اندازی کاربر اصلی و حقوق پیکربندی کرد. به بخش «گروه‌های دسترسی» بروید و روی پیوند «دسترسی به پروفایل‌های گروه» کلیک کنید.
بیایید از فرم لیستی که باز می شود یک گروه جدید ایجاد کنیم. در بخش جدولی در برگه "عملکردهای مجاز (نقش ها)"، کادرهای مربوط به نقش هایی را علامت بزنید که بر حقوق دسترسی کاربران موجود در گروهی که ایجاد می کنیم تأثیر می گذارد. همه این نقش ها در پیکربندی ایجاد و پیکربندی می شوند. آنها را نمی توان تغییر داد یا موارد جدیدی از حالت کاربر ایجاد کرد. شما فقط می توانید از لیست موجود انتخاب کنید.
RLS: محدودیت دسترسی سطح رکورد
به شما امکان می دهد تا دسترسی به داده های برنامه را در مناطق خاصی با انعطاف بیشتری پیکربندی کنید. برای فعال کردن آن، کادری به همین نام را در فرم تنظیمات کاربر و حقوق علامت بزنید.
لطفاً توجه داشته باشید که فعال کردن این تنظیم ممکن است بر عملکرد سیستم تأثیر منفی بگذارد. نکته این است که مکانیسم RLS همه درخواست ها را بسته به محدودیت های تعیین شده تغییر می دهد.
بیایید به نمایه گروه دسترسی «گروه آزمایش» که قبلاً ایجاد کردیم برویم. شکل زیر نشان می دهد که پس از فعال کردن محدودیت های دسترسی در سطح رکورد، یک برگه اضافی "محدودیت های دسترسی" ظاهر شد.
فرض کنید می‌خواهیم کاربرانی که به یک گروه آزمایشی اختصاص داده شده‌اند، به داده‌های همه سازمان‌های موجود در این پایگاه اطلاعاتی دسترسی داشته باشند، به جز مواردی که در نمایه مشخص شده‌اند.
در قسمت جدول بالا، محدودیت های دسترسی را بر اساس سازمان تعیین می کنیم. در قسمت پایین، توضیح خواهیم داد که دسترسی به داده ها (اسناد، دایرکتوری ها و غیره) برای سازمان Roga LLC فراهم نخواهد شد.
RLS- این توانایی توسعه دهنده برای تنظیم شرایط روی جداول پایگاه داده برای کاربران خاص (گروه های کاربری) و جلوگیری از دیدن چیزهای غیر ضروری است. شرایط از نوع بولی است. اگر شرط به درستی ارزیابی شود، دسترسی داده می شود، در غیر این صورت رد می شود.
RLS به طور همزمان با تنظیم حقوق دسترسی عادی استفاده می شود. بنابراین، قبل از شروع پیکربندی RLS، باید حقوق منظمی را به اشیاء پیکربندی اختصاص دهید.
RLS برای انواع حقوق دسترسی زیر استفاده می شود:
- خواندن
- اضافه
- تغییر دادن
- حذف
نحوه پیکربندی RLS
بیایید به یک مثال ساده از نحوه پیکربندی آن نگاه کنیم. اسکرین شات ها در نسخه 1C Enterprise 8.2 (8.2.9.356) گرفته شده است. نحو الگوهای متن محدودیت در مستندات 8.2 در کتاب "راهنمای توسعه دهنده" توضیح داده شده است. بخش 1، بنابراین ما به آن نمی پردازیم.
بنابراین، اولین قدم این است که برای هر نقش موجود، قالب‌های محدودیت تعریف کنیم.
پس از این، بر اساس قالب های مشخص شده، محدودیت هایی بر روی اشیاء لازم اعمال می شود. برای ویرایش متن یک شرط، می‌توانید از طراح محدودیت‌های دسترسی به داده استفاده کنید.
برای ویرایش چند نقش، مدیریت از طریق پنجره "همه نقش ها" راحت است.
می‌توانید از پنجره «محدودیت‌های دسترسی» برای کپی کردن شرایط به نقش‌های دیگر استفاده کنید. الگوها را فقط می توان به صورت دستی در نقش های دیگر کپی کرد.
همین. می توانید نتیجه را بررسی کنید.
معایب استفاده از RLS:
- استفاده از مکانیزم محدودیت دسترسی در سطح رکورد منجر به افزایش ضمنی جداول شرکت کننده در پرس و جو می شود که می تواند منجر به خطا در حالت سرویس گیرنده-سرور پایگاه داده شود.
- ممکن است اجرای منطق برنامه پیچیده برای کنترل نوشتن دشوار یا غیرممکن باشد. در چنین مواردی بهتر است از شرایط در رویه OnWrite() استفاده شود.
- نوشتن یک شرط (پرس و جو) به شرایط خاصی از توسعه دهنده نیاز دارد.
- مشکلات اضافی را می توان با عدم توانایی در اشکال زدایی یک شرط (پرس و جو) ایجاد کرد.
در پیکربندی‌های معمولی، حقوق در سطح رکورد را می‌توان به صورت تعاملی برای اشیاء زیر تنظیم کرد: سازمان‌ها، طرف‌های مقابل، اقلام، انبارها، بخش‌ها، افراد، برنامه‌های کاربردی نامزد و دیگران.
باید به خاطر داشت که محدودیت های حقوق دسترسی در سطح رکورد یک مکانیسم نسبتاً فشرده منابع است و هرچه محدودیت های پیچیده تری تعیین کنید، برنامه کندتر کار می کند، به خصوص با یک پایگاه داده بزرگ.
