نحوه راه اندازی گوشی های هوشمند و رایانه های شخصی. پرتال اطلاعاتی

محدود کردن دسترسی به داده ها 8. استفاده از RLS

در سیستم 1C Enterprise 8، امروز ما به مطالعه مکانیسم حقوق و کاوش بیشتر در مکانیسم RLS (محدودیت حقوق در سطح رکورد) خواهیم پرداخت.

در زیر به مزایا و معایب این روش خواهیم پرداخت و با استفاده از یک مثال به راه اندازی RLS در 1C Enterprise 8.3 خواهیم پرداخت.

1C RLS (امنیت سطح رکورد) یا محدودیت حقوق در سطح ضبط- اینها حقوق کاربر در سیستم 1C است که به شما امکان می دهد حقوق کاربران را در زمینه تغییر پویا داده ها جدا کنید.

رایج ترین نوع تنظیم 1C RLS محدود کردن دید کاربر در بین سازمان ها یا مشتریان است (کاربر فقط داده های "خود" را می بیند).

مزیت اصلی وجود یک مکانیسم در کل است؛ مکانیسم بسیار پیچیده و جالب است. به شما این امکان را می دهد که حقوق کاربر را کاملاً متمایز کنید - کاربران ممکن است حتی از وجود داده های دیگر در سیستم آگاه نباشند.

معایب 1C 8 RLS

از جمله کاستی ها می توان به افت محسوس عملکرد سیستم اشاره کرد. این به این دلیل است که پلتفرم هنگام ساخت یک پرس و جو در پایگاه داده، هر درخواست توسعه دهنده را با شرایط اضافی پیچیده می کند.

همچنین از جمله معایب، پیچیدگی راه اندازی این قابلیت و دشواری اشکال زدایی است. 1C مطالب بسیار کمی در مورد راه اندازی و عملکرد این قابلیت منتشر کرده است. پیدا کردن متخصصی که مکانیسم را به درستی تنظیم کند بسیار دشوار است.

تنظیم محدودیت های حقوق در سطح رکورد 1C RLS

مجوزهای سطح رکورد (RLS) برای محدود کردن انواع حقوق زیر استفاده می شوند:

  • خواندن
  • اضافه شدن
  • تغییر دادن
  • حذف

267 درس ویدیویی را در 1C به صورت رایگان دریافت کنید:

از نظر خارجی، راه‌اندازی RLS (حقوق در سطح رکورد) شبیه ایجاد یک ساده است. نمونه ای از یک الگو برای محدود کردن دسترسی به رویت اسناد توسط مشتری از سربرگ سند:

##اگر &از محدودیت‌های حقوق دسترسی در سطح رکورد استفاده کنید ##سپس

CurrentTable FROM #CurrentTable به عنوان CurrentTable
LEFT Join (مختلف را انتخاب کنید
Group Composition.Link AS Group User
از جانب
Directory.User Groups.UsersGroups AS ترکیب گروه
جایی که
GroupComposition.User = &CurrentUser) AS UserGroups
نرم افزار (محدودیت های حقوق دسترسی در سطح &UseRecord)
WHERE (&UseRecordLevelPermissionRestrictions = FALSE
یا (نه 1 ولت
(انتخاب TOP 1
1 نحوه انتخاب
از جانب
ثبت اطلاعات هدف انواع اشیاء دسترسی
جایی که
هدف از انواع دسترسی Objects.UserGroup = UserGroups.UserGroup
و انتخاب
WHEN هدف انواع اشیاء دسترسی. نوع شیء دسترسی = VALUE (شمارش. انواع اشیاء دسترسی. طرفین)
و CurrentTable.#Parameter(1) LINK Directory.Counterparties
AND NOT CurrentTable.#Parameter(1) = VALUE(Directory.Accounts.EmptyLink)
سپس انتخاب کنید
وقتی 1 ولت
(انتخاب TOP 1
1
از جانب
Directory.Counterparties AS Contractors عضویت داخلی اطلاعات ثبت نام. تنظیمات حقوق دسترسی کاربر به عنوان تنظیمات حقوق دسترسی کاربر
توسط
UserAccessRightSettings.AccessObject = Counterparties.AccessGroupToCounterparty
و UserAccessRightSettings.AccessObjectType = VALUE(Enumeration.AccessObjectTypes.Counterparties)
AND (تنظیمات حقوق دسترسی کاربر. کاربر = تخصیص انواع اشیاء دسترسی. گروه کاربر
یا UserAccessRightSettings.User = VALUE(Directory.UserGroups.AllUsers))
و UserAccessRightSettings.Record = TRUE
جایی که
Counterparties.Link = CurrentTable.#Parameter(1))
سپس حقیقت
در غیر این صورت نادرست
پایان
در غیر این صورت درست است
پایان = نادرست))
AND NOT UserGroups.UserGroup NULL است)
##EndIf

در اصل، هر بار که جدول "#CurrentTable" پرس و جو می شود، این پرس و جو اضافه می شود. که از آن می توانیم تصور کنیم که مکانیسم محدودیت در سطح رکورد چه بار اضافی را تحمل می کند.

همانطور که می بینید، درخواست دارای پارامترهای خاصی است، به عنوان مثال "&استفاده از محدودیت های حقوق دسترسی در سطح رکورد". این پارامترها در رادار از اشیاء ابرداده - " " انتخاب می شوند. به عنوان یک قاعده، آنها در شروع جلسه کاربر تنظیم می شوند.

سازنده محدودیت دسترسی به داده

برای راحتی توسعه دهنده، 1C 8.3 دارای یک ابزار ویژه برای کمک به پیکربندی رادار است - طراح محدودیت دسترسی به داده. از قسمت "محدودیت دسترسی" فراخوانی می شود. به شرح زیر است:

RLS- این توانایی توسعه دهنده برای تنظیم شرایط روی جداول پایگاه داده برای کاربران خاص (گروه های کاربری) و جلوگیری از دیدن چیزهای غیر ضروری است. شرایط از نوع بولی است. اگر شرط به درستی ارزیابی شود، دسترسی داده می شود، در غیر این صورت رد می شود.

RLS به طور همزمان با تنظیم حقوق دسترسی عادی استفاده می شود. بنابراین، قبل از شروع پیکربندی RLS، باید حقوق منظمی را به اشیاء پیکربندی اختصاص دهید.

RLS برای انواع حقوق دسترسی زیر استفاده می شود:

  • خواندن
  • اضافه شدن
  • تغییر دادن
  • حذف

نحوه پیکربندی RLS

بیایید به یک مثال ساده از نحوه پیکربندی آن نگاه کنیم. اسکرین شات ها در نسخه 1C Enterprise 8.2 (8.2.9.356) گرفته شده است. نحو الگوهای متن محدودیت در مستندات 8.2 در کتاب "راهنمای توسعه دهنده" توضیح داده شده است. بخش 1، بنابراین ما به آن نمی پردازیم.

بنابراین، اولین قدم این است که برای هر نقش موجود، قالب‌های محدودیت تعریف کنیم.

پس از این، بر اساس قالب های مشخص شده، محدودیت هایی بر روی اشیاء لازم اعمال می شود. برای ویرایش متن یک شرط، می‌توانید از طراح محدودیت‌های دسترسی به داده استفاده کنید.

برای ویرایش چند نقش، مدیریت از طریق پنجره "همه نقش ها" راحت است.

می‌توانید از پنجره «محدودیت‌های دسترسی» برای کپی کردن شرایط به نقش‌های دیگر استفاده کنید. الگوها را فقط می توان به صورت دستی در نقش های دیگر کپی کرد.

همین. می توانید نتیجه را بررسی کنید.

معایب استفاده از RLS:

  1. استفاده از مکانیزم محدودیت دسترسی در سطح رکورد منجر به افزایش ضمنی جداول شرکت کننده در پرس و جو می شود که می تواند منجر به خطا در حالت سرویس گیرنده-سرور پایگاه داده شود.
  2. ممکن است اجرای منطق برنامه پیچیده برای کنترل نوشتن دشوار یا غیرممکن باشد. در چنین مواردی بهتر است از شرایط در رویه OnWrite() استفاده شود.
  3. نوشتن یک شرط (پرس و جو) به شرایط خاصی از توسعه دهنده نیاز دارد.
  4. مشکلات اضافی را می توان با عدم توانایی در اشکال زدایی یک شرط (پرس و جو) ایجاد کرد.

در پیکربندی‌های معمولی، حقوق در سطح رکورد را می‌توان به صورت تعاملی برای اشیاء زیر تنظیم کرد: سازمان‌ها، طرف‌های مقابل، اقلام، انبارها، بخش‌ها، افراد، برنامه‌های کاربردی نامزد و دیگران.

باید به خاطر داشت که محدودیت های حقوق دسترسی در سطح رکورد یک مکانیسم نسبتاً فشرده منابع است و هرچه محدودیت های پیچیده تری تعیین کنید، برنامه کندتر کار می کند، به خصوص با یک پایگاه داده بزرگ.

تمام تنظیمات حقوق کاربر که در چارچوب این مقاله انجام خواهیم داد در بخش 1C 8.3 "اداره" - "تنظیمات کاربر و حقوق" قرار دارند. این الگوریتم در اکثر پیکربندی ها در فرم های مدیریت شده مشابه است. برنامه حسابداری 1C به عنوان مثال استفاده خواهد شد، اما تنظیم حقوق در سایر برنامه ها (1C UT 11، 1C ZUP 3، 1C ERP) دقیقاً به همین روش انجام می شود.

بیایید به بخش "کاربران" در پنجره تنظیمات برویم. در اینجا ما دو لینک می بینیم: "کاربران" و "تنظیمات ورود". اولین آنها به شما امکان می دهد مستقیماً به لیست کاربران این پایگاه اطلاعاتی بروید. قبل از ایجاد یک کاربر جدید، اجازه دهید به تنظیمات احتمالی ورود (هیپرلینک در سمت راست) نگاه کنیم.

در این فرم تنظیمات، می توانید پیچیدگی رمز عبور (حداقل 7 کاراکتر، محتوای اجباری انواع کاراکترها و غیره) را پیکربندی کنید. همچنین می توانید طول رمز عبور، مدت اعتبار آن را مشخص کنید و اگر کاربران برای مدت معینی فعال نبودند، از ورود به برنامه منع کنید.

اکنون می توانید مستقیماً به افزودن یک کاربر جدید به 1C ادامه دهید. این را می توان با کلیک بر روی دکمه "ایجاد"، همانطور که در تصویر زیر نشان داده شده است، انجام داد.

اول از همه، ما نام کامل - "دیمیتری پتروویچ آنتونوف" را نشان می دهیم و فردی را از دایرکتوری مربوطه انتخاب می کنیم. در اینجا می توانید بخشی را که کارمند ما در آن کار می کند نیز مشخص کنید.

نام ورود به سیستم "AntonovDP" به طور خودکار به عنوان مخفف نام کامل "Dmitry Petrovich Antonov" جایگزین شد. بیایید یک رمز عبور و احراز هویت 1C Enterprise تنظیم کنیم. در اینجا همچنین می توانید مشخص کنید که آیا این کاربر می تواند رمز عبور خود را به طور مستقل تغییر دهد یا خیر.

فرض کنید می‌خواهیم دیمیتری پتروویچ آنتونوف هنگام راه‌اندازی این پایگاه اطلاعاتی در لیست انتخابی موجود باشد. برای انجام این کار، باید چک باکس را در مورد "نمایش در لیست انتخاب" تنظیم کنید. در نتیجه، پنجره مجوز هنگام شروع برنامه مانند شکل زیر به نظر می رسد.

بیایید به یکی دیگر از تنظیمات مهم در کارت فهرست کاربر توجه کنیم - "ورود به برنامه مجاز است." اگر تاخیر تنظیم نشده باشد، کاربر به سادگی نمی تواند وارد این پایگاه اطلاعاتی شود.

حقوق دسترسی

پس از پر کردن تمام داده های کارت کاربر - دیمیتری پتروویچ آنتونوف، آنها را یادداشت می کنیم و همانطور که در شکل زیر نشان داده شده است به تنظیم حقوق دسترسی می رویم.

لیستی از پروفایل های دسترسی که قبلاً وارد برنامه شده بودند، قبل از ما باز شد. کادرهای مورد نیاز را علامت بزنید.

دسترسی به پروفایل های گروه

پروفایل های گروه دسترسی را می توان از فرم راه اندازی کاربر اصلی و حقوق پیکربندی کرد. به بخش «گروه‌های دسترسی» بروید و روی پیوند «دسترسی به پروفایل‌های گروه» کلیک کنید.

بیایید از فرم لیستی که باز می شود یک گروه جدید ایجاد کنیم. در بخش جدولی در برگه "عملکردهای مجاز (نقش ها)"، کادرهای مربوط به نقش هایی را علامت بزنید که بر حقوق دسترسی کاربران موجود در گروهی که ایجاد می کنیم تأثیر می گذارد. همه این نقش ها در پیکربندی ایجاد و پیکربندی می شوند. آنها را نمی توان تغییر داد یا موارد جدیدی از حالت کاربر ایجاد کرد. شما فقط می توانید از لیست موجود انتخاب کنید.

RLS: محدودیت دسترسی سطح رکورد

به شما امکان می دهد تا دسترسی به داده های برنامه را در مناطق خاصی با انعطاف بیشتری پیکربندی کنید. برای فعال کردن آن، کادری به همین نام را در فرم تنظیمات کاربر و حقوق علامت بزنید.

لطفاً توجه داشته باشید که فعال کردن این تنظیم ممکن است بر عملکرد سیستم تأثیر منفی بگذارد. نکته این است که مکانیسم RLS همه درخواست ها را بسته به محدودیت های تعیین شده تغییر می دهد.

بیایید به نمایه گروه دسترسی «گروه آزمایش» که قبلاً ایجاد کردیم برویم. شکل زیر نشان می دهد که پس از فعال کردن محدودیت های دسترسی در سطح رکورد، یک برگه اضافی "محدودیت های دسترسی" ظاهر شد.

فرض کنید می‌خواهیم کاربرانی که به یک گروه آزمایشی اختصاص داده شده‌اند، به داده‌های همه سازمان‌های موجود در این پایگاه اطلاعاتی دسترسی داشته باشند، به جز مواردی که در نمایه مشخص شده‌اند.

در قسمت جدول بالا، محدودیت های دسترسی را بر اساس سازمان تعیین می کنیم. در قسمت پایین، توضیح خواهیم داد که دسترسی به داده ها (اسناد، دایرکتوری ها و غیره) برای سازمان Roga LLC فراهم نخواهد شد.

نسخه هشتم پلت فرم 1C: Enterprise (امروز 8.3) تغییرات زیادی را در رابطه با "هفت" انجام داد که در میان آنها مکانیسم محدود کردن حقوق دسترسی در سطح رکورد به ویژه قابل توجه بود. با وجود این واقعیت که از نظر تئوری انجام بدون آن امکان پذیر است، تنها با استفاده از نقش ها، RLS به شما امکان می دهد تنظیمات دسترسی دقیق تری را به دست آورید. اما برای عملکرد صحیح این مکانیسم، باید ماهیت آن را به وضوح درک کنید و تجربه کافی در توسعه در 1C داشته باشید.

RLS چیست؟

ماهیت این عملکرد، توانایی توسعه دهنده برای جلوگیری از دسترسی کاربر یا گروه خاصی از کاربران به جداول یا فیلدهای جداول پایگاه داده است. به طور معمول، از محدودیت‌ها برای جلوگیری از مشاهده و ویرایش اطلاعات محرمانه و محرمانه توسط کاربران 1C استفاده می‌شود، به عنوان مثال، محدود کردن کارمندان یک شرکت شامل یک گروه به مشاهده اسناد فقط برای سازمان خود. همچنین، مکانیسم محدود کردن حقوق دسترسی در سطح رکورد می تواند برای حذف اطلاعات غیر ضروری از رابط استفاده شود.

برای اینکه بتوانید پرس و جوهایی برای محدودیت های RLS بنویسید، باید یک نقش ایجاد کنید یا یک نقش موجود را انتخاب کنید. راه اندازی RLS در 1C 8.3 می تواند برای اقدامات کاربر زیر استفاده شود:

  • اضافه
  • خواندن؛
  • حذف؛
  • تغییر دادن.

علاوه بر گسترده ترین امکانات برای شخصی سازی دسترسی، RLS دارای معایبی نیز می باشد:

  1. الزامات برای صلاحیت های توسعه دهنده، زیرا درخواست باید به زبان داخلی نوشته شود، با در نظر گرفتن قوانین نحو.
  2. عدم توانایی برای اشکال زدایی سریع شرایط؛
  3. امکانات محدود برای توصیف منطق: شرایط بسیار پیچیده همچنان باید در ماژول های اسناد و کتاب های مرجع نوشته شود.
  4. در نسخه سرویس گیرنده-سرور پایگاه داده، رشد ضمنی جداول موجود در پرس و جو امکان پذیر است. علاوه بر این، پیگیری این فرآیند بسیار دشوار است.
  5. منابع مورد نیاز محدودیت های RLS انرژی زیادی را در ماشین و سرور مشتری مصرف می کند.
  6. اسناد کمی به رایگان در دسترس است.

مشکل دیگری که ممکن است پس از راه اندازی 1C RLS ایجاد شود می تواند گزارش باشد. واقعیت این است که توسعه‌دهندگان محدودیت‌های احتمالی RLS را ارائه می‌کنند و گزارش‌ها را طوری می‌سازند که فقط داده‌های مجاز را نشان دهند. اگر کاربران محدودیت‌های RLS متفاوتی را پیکربندی کرده باشند، ممکن است داده‌های گزارش برای پارامترهای یکسان متفاوت باشد. این می تواند سوالاتی را ایجاد کند، بنابراین باید این موقعیت ها را هنگام طراحی گزارش یا نوشتن پرس و جو در RLS در نظر بگیرید.

یک محدودیت RLS ایجاد کنید

برای اضافه کردن یک محدودیت RLS، باید نقش مورد نظر را پیدا کرده و با دوبار کلیک آن را باز کنید.

پنجره ای که باز می شود شامل 2 تب است: "حقوق" و "الگوهای محدودیت". برای اعمال محدودیت‌های خاص بر روی یک عمل خاص، باید آن را انتخاب کرده و روی علامت سبز رنگ در قسمت پایین سمت راست کلیک کنید. خطی ظاهر می شود که در آن می توانیم محدودیت های 1C RLS را در زبان تعبیه شده در 1C تنظیم کنیم.


اگر سینتکس 1C را می دانید (مانند پشت دست خود)، می توانید مستقیماً در قسمت "محدودیت دسترسی" بنویسید. توسعه دهندگان 1C امکان باز کردن سازنده پرس و جو را فراهم کرده اند که به شما کمک می کند و پیشنهاد می کند که چه محدودیت هایی می تواند ایجاد شود. برای باز کردن آن، باید روی دکمه سه نقطه (انتخاب) یا F4 کلیک کنید و پنجره ای با دکمه Query Builder… ظاهر می شود.


در پنجره ای که ظاهر می شود، می توانید محدودیت ها را نه تنها برای این فهرست، بلکه برای سایر اشیاء سیستم نیز پیکربندی کنید. برای انجام این کار، باید آنها را در تب "جدول و فیلدها" اضافه کنید. ما محدودیت هایی را در زمینه های فهرست "نامگذاری" ثبت می کنیم و روی "OK" کلیک می کنیم. مراقب نام متغیرها باشید: پارامترهای RLS در ابتدای جلسه کاربر تنظیم می‌شوند و باید در شی ابرداده قرار گیرند.


در برگه "Constraint Templates"، پرس و جوهایی را مشخص می کنید که هنگام کپی کردن همان تنظیمات RLS در 1C 8.3 ضروری هستند. پس از اینکه الگوی خود را اضافه کردید، می توانید از نام آن در تنظیمات حقوق دسترسی استفاده کنید.

همچنین می توان به طور همزمان محدودیت هایی را به چند نقش اضافه کرد. برای انجام این کار، در درخت پیکربندی باید روی بخش "نقش ها" راست کلیک کرده و "همه نقش ها" را انتخاب کنید.


به عنوان یک نتیجه، می خواهم توجه داشته باشم که این مقاله برای مشاوران توسعه دهنده 1C طراحی شده است و می تواند در درجه اول به کسانی کمک کند که قبلاً در توسعه 1C: Enterprise تجربه دارند. علیرغم سادگی ظاهری آن، دانش معناشناسی و درک ساختار فرآیندهای تجاری شرکت خود یا سازمان مشتری برای توزیع صحیح حقوق نیاز به سطح معینی از دانش و تجربه دارد.

پلت فرم 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 صحبت خواهیم کرد.

بهترین مقالات در این زمینه