برای اطمینان از اینکه فقط کاربرانی که به یک آیتم دسترسی دارند میتوانند آن آیتم را در نتیجه جستجو ببینند، باید آیتمها را با لیستهای کنترل دسترسی (ACL) آنها از مخزن سازمانی فهرستبندی کنید. شما باید ACL های مخزن خود را مدلسازی کنید و هنگام فهرستبندی آیتمها در مخزن، آن ACL ها را لحاظ کنید. کیت توسعه نرمافزار رابط محتوا (Content Connector SDK) مجموعهای غنی از روشهای ACL را ارائه میدهد که به اندازه کافی قدرتمند هستند تا ACL های اکثر مخازن را مدلسازی کنند.
ایجاد یک ACL
ایجاد ACL یک فرآیند دو مرحلهای است:
- با استفاده از متدهای استاتیک در کلاس ACL، یک
Principalایجاد کنید. - از کلاس
Acl.Builderبرای ساخت ACL با استفاده از principal استفاده کنید.
ادامهی این سند، برخی مفاهیمی را که برای مدلسازی و ایجاد ACLها باید بدانید، مانند وراثت و مهار، پوشش میدهد.
ایجاد یک مدیر با استفاده از یک شناسه خارجی
جستجوی ابری گوگل از کاربران و گروهها میخواهد که به آدرس ایمیل گوگل دسترسی داشته باشند. هنگام ایندکس کردن آیتمهای مخزن، رابطهای محتوا ممکن است این آدرسهای ایمیل را نداشته باشند. با این حال، SDK رابط محتوا به شما امکان میدهد از هر شناسه خارجی (شناسهای که به کاربر یا گروه اجازه دسترسی به آیتمهای مخزن را میدهد) به جای آدرس ایمیل، برای ایندکس کردن یک آیتم استفاده کنید. از متد getUserPrincipal() یا متد getGroupPrincpal() برای ایجاد مؤلفههای اصلی حاوی شناسههای خارجی استفاده کنید. چندین متد استاتیک دیگر در کلاس ACL وجود دارد که برای ساخت اشیاء Principal استفاده میشوند.
وراثت ACL
وراثت ACL به مجوزدهی برای یک آیتم خاص و یک کاربر خاص، بر اساس نتیجه ترکیبی از ACLهای آن آیتم و ACLهای زنجیره وراثت آن اشاره دارد. قوانینی که برای تصمیمگیری در مورد مجوزدهی استفاده میشوند، به مخزن و ویژگیهای آیتم بستگی دارند.
تنظیم وراثت
هر آیتم میتواند دارای principalهای با دسترسی مستقیم (direct allowed) و principalهای با دسترسی مستقیم (direct denied) باشد که با استفاده از متدهای setReaders() و setDeniedReaders() مشخص میشوند. principal با دسترسی مستقیم، کاربری است که در یک ACL شناسایی شده و به او دسترسی مستقیم به یک آیتم خاص را میدهد. principal با دسترسی مستقیم، کاربری است که در یک ACL شناسایی شده و به او دسترسی به یک آیتم خاص را نمیدهد.
یک آیتم همچنین میتواند با استفاده از متد setInheritFrom() از principalهای غیرمستقیم مجاز و از principalهای غیرمستقیم غیرمجاز ارث ببرد. یک principal غیرمستقیم مجاز، کاربری است که از طریق ارثبری ACL، دسترسی غیرمستقیم به یک آیتم خاص دارد. یک principal غیرمستقیم غیرمجاز، کاربری است که از طریق ارثبری ACL، دسترسی به یک آیتم خاص را ندارد.
شکل 1 نحوه استفاده از متد setInheritFrom() برای ارثبری از توابع اصلی غیرمستقیم مجاز و غیرمستقیم غیرمجاز را نشان میدهد.
setInheritFrom()این کنترلهای دسترسی در شکل ۱ نشان داده شدهاند:
- کاربر ۱، یک مدیر مجاز مستقیم برای مورد A است.
- کاربر ۲ یک مدیر مجاز مستقیم برای مورد B است.
- مورد B، ACL مورد A را به ارث میبرد.
بر اساس کنترلهای دسترسی، قوانین دسترسی عبارتند از:
- برای اینکه کاربر ۱ یک مدیر با دسترسی غیرمستقیم برای آیتم B باشد، نیازی نیست که صریحاً به عنوان مدیر اصلی آیتم B مشخص شود؛ این دسترسی به ارث برده میشود زیرا کاربر ۱ به عنوان مدیر اصلی با دسترسی مستقیم برای آیتم A فهرست شده است و آیتم B ACL خود را از آیتم A به ارث میبرد.
- کاربر ۲ یک مدیر غیرمستقیم مجاز به مورد A نیست.
نوع وراثت را تنظیم کنید
اگر با استفاده از متد setInheritFrom() ارثبری را تنظیم میکنید، باید نوع ارثبری را با استفاده از متد setInheritanceType() تنظیم کنید. نوع ارثبری نحوه ترکیب ACL فرزند با ACL والدش را تعیین میکند. Acl.InheritanceType سه نوع ارثبری را پیادهسازی میکند:
BOTH_PERMIT- نوع وراثت را رویBOTH_PERMITتنظیم کنید تا به یک کاربر فقط زمانی دسترسی به آیتم داده شود که هم ACL آیتم فرزند و هم ACL آیتم ارثبریشده والد به آن کاربر اجازه دسترسی به آن آیتم را بدهند.CHILD_OVERRIDE- نوع ارثبری را رویCHILD_OVERRIDEتنظیم کنید تا ACL آیتم فرزند در صورت تداخل، بر ACL آیتم والد ارثبریشده اولویت داشته باشد. بنابراین، اگر ACL آیتم والد دسترسی کاربر را به عنوان یک خوانندهی غیرمجاز رد کند، کاربر همچنان در صورت دسترسی به آیتم فرزند به عنوان یک خواننده، دسترسی دارد. برعکس، حتی اگر ACL آیتم والد به کاربر دسترسی بدهد، اگر کاربر خوانندهی فرزند باشد، دسترسی نخواهد داشت.PARENT_OVERRIDE- نوع وراثت را رویPARENT_OVERRIDEتنظیم کنید تا ACL آیتم والد در صورت تداخل، بر ACL آیتم فرزند اولویت داشته باشد. بنابراین، اگر ACL آیتم فرزند دسترسی کاربر را به عنوان یک خوانندهی غیرمجاز رد کند، کاربر همچنان در صورتی که به عنوان یک خواننده به آیتم والد دسترسی داشته باشد، دسترسی خواهد داشت. برعکس، حتی اگر ACL آیتم فرزند به کاربر دسترسی بدهد، اگر کاربر خوانندهی آیتم والد باشد، دسترسی نخواهد داشت.
هنگام ارزیابی یک زنجیره ارثبری ACL، ترتیب ارزیابی میتواند نتیجه تصمیم مجوز را تغییر دهد. Cloud Search ترتیب ارزیابی را از برگ به ریشه برای زنجیرههای ارثبری ACL ارائه میدهد. به طور خاص، تصمیم ACL برای یک زنجیره با ارزیابی یک فرزند به همراه والدینش شروع میشود و میتواند تا والد ریشه ادامه یابد.
برای مثال، اگر فرزند از نوع وراثت CHILD_OVERRIDE باشد و کاربر به فرزند دسترسی داشته باشد، درایو نیازی به ارزیابی والد ندارد. با این حال، اگر فرزند از نوع PARENT_OVERRIDE یا BOTH_PERMIT باشد، درایو به ارزیابی وراثت در سطوح بالاتر زنجیره ادامه میدهد.
مهار و حذف آیتم
هنگام اندیسگذاری یک آیتم، میتوانید با استفاده از متد setContainer() از کلاس IndexingItemBuilder ، آن آیتم را به عنوان یک ظرف (container) برچسبگذاری کنید. رابطهی container/containee سلسله مراتب فیزیکی آیتمها را تعیین میکند و تضمین میکند که آیتمها به درستی حذف شوند. هنگامی که یک ظرف حذف میشود، آیتمهای موجود در آن نیز حذف میشوند.
روابط مربوط به محدودیتها (Containment Relations) کاملاً مستقل از قوانین وراثت ACL هستند. برای مثال، یک فایل در یک سیستم فایل میتواند توسط یک پوشه به منظور حذف در بر گرفته شود، اما ACL را از یک پوشه دیگر به ارث ببرد. حذف یک پوشه، مواردی را که ACL آن را به ارث میبرند، حذف نمیکند، مگر اینکه آن موارد نیز در سلسله مراتب محدودیت پوشه باشند.
این کنترلهای دسترسی در شکل ۲ نشان داده شدهاند:
- کاربر ۱، یک مدیر مجاز مستقیم برای مورد A است.
- کاربر ۲ یک مدیر مجاز مستقیم برای مورد B است.
- کاربر ۳ یک مدیر مجاز مستقیم برای مورد C است.
- مورد C، ACL مورد A را به ارث میبرد.
- کالای ب، کالای الف را به عنوان ظرف خود نامگذاری میکند.
- کالای C، کالای B را به عنوان ظرف خود نامگذاری میکند.
بر اساس کنترلهای دسترسی، قوانین دسترسی عبارتند از:
- دسترسی غیرمستقیم از متد
setInheritFrom()میآید. بنابراین، کاربر ۱ میتواند به آیتم C دسترسی داشته باشد زیرا آیتم C از آیتم A، ACL را به ارث برده است. - دسترسی غیرمستقیم از محصور بودن مورد C توسط مورد B حاصل نمیشود. بنابراین، کاربر ۲ نمیتواند به مورد C دسترسی داشته باشد.
setInheritFrom() در حال استفاده.جداسازی وراثت ACL از سلسله مراتب مهار به شما امکان میدهد ساختارهای موجود مختلفی را مدلسازی کنید.
وقتی یک مورد با موفقیت حذف شد:
- هر موردی که حاوی یک مورد حذف شده باشد، غیرقابل جستجو میشود و برای حذف از منبع داده گوگل برنامهریزی میشود.
- هر آیتمی که با استفاده از متد
setInheritFrom()آیتم حذف شده را مشخص کرده باشد، غیرقابل جستجو میشود.
اگر منبعی با استفاده از متد setInheritFrom() یک آیتم حذف شده داشته باشد، اما با استفاده از setContainer() مجموعه کانتینری نداشته باشد، یا سلسله مراتب نگهداری آن شامل هیچ آیتم حذف شدهای نباشد، آن آیتم و دادههای آن در منبع داده گوگل باقی میمانند. شما مسئول حذف آیتم هستید.
شکل ۳ مثالی از نحوهی عملکرد حذف برای یک سلسله مراتب آیتم را نشان میدهد.
این کنترلهای دسترسی در شکل ۳ نشان داده شدهاند:
- کاربر ۱، یک مدیر مجاز مستقیم برای مورد A است.
- کاربر ۲ یک مدیر مجاز مستقیم برای مورد D است.
- آیتم D و آیتم E هر دو ACL آیتم A را به ارث میبرند.
- کالای D، کالای A را به عنوان ظرف خود نامگذاری میکند.
- اقلام A و E اقلام سطح ریشه هستند زیرا فاقد اقلام نگهدارنده هستند.
به صورت آبشاری از طریق ارجاعات کانتینر حذف میکند. وقتی مورد A حذف میشود:
- تمام فرزندان مرجع
setInheritFrom()دسترسی برای همه کاربران را از دست میدهند. - هیچ کاربری نمیتواند به مورد A دسترسی داشته باشد.
- مورد D به طور ضمنی حذف شده است. هیچ کاربری نمیتواند به مورد D دسترسی داشته باشد.
- مورد E حذف نمیشود، زیرا حذف فقط از طریق ارجاعات به کانتینر انجام میشود.
- مورد E غیرقابل دسترس میشود و هیچ کاربری قادر به جستجوی مورد E نیست.