মানচিত্র ACLs

সার্চ রেজাল্টে কোনো আইটেম যেন শুধুমাত্র সেটিতে অ্যাক্সেস থাকা ব্যবহারকারীরাই দেখতে পায়, তা নিশ্চিত করতে এন্টারপ্রাইজ রিপোজিটরি থেকে আইটেমগুলোকে তাদের অ্যাক্সেস কন্ট্রোল লিস্ট (ACL) সহ ইনডেক্স করুন। আপনাকে অবশ্যই রিপোজিটরির ACL-গুলো মডেল করতে হবে এবং আইটেম ইনডেক্স করার সময় সেগুলো অন্তর্ভুক্ত করতে হবে। কন্টেন্ট কানেক্টর SDK বেশিরভাগ রিপোজিটরির ACL-গুলো মডেল করার জন্য মেথড সরবরাহ করে।

দ্রষ্টব্য: কন্টেন্ট কানেক্টর এসডিকে একক-ডোমেইন এসিএল সমর্থন করে, কিন্তু ক্রস-ডোমেইন এসিএল সমর্থন করে না। আপনি আপনার প্রতিষ্ঠানের বাইরের ব্যবহারকারী এবং গ্রুপকে অ্যাক্সেস দিতে পারবেন না। আপনার প্রতিষ্ঠানের বাইরের ব্যবহারকারী বা গ্রুপকে নির্দেশকারী এসিএলগুলোর কোনো কার্যকারিতা থাকবে না।

একটি ACL তৈরি করুন

ACL তৈরি করা একটি দুই-ধাপের প্রক্রিয়া:

1. ACL ক্লাসের স্ট্যাটিক মেথড ব্যবহার করে একটি Principal তৈরি করুন।
2. প্রিন্সিপাল ব্যবহার করে ACL তৈরি করতে Acl.Builder ক্লাসটি ব্যবহার করুন।

এই ডকুমেন্টে ACL মডেল করা ও তৈরি করার বিভিন্ন ধারণা, যেমন ইনহেরিটেন্স এবং কন্টেইনমেন্ট, আলোচনা করা হয়েছে।

এক্সটার্নাল আইডি ব্যবহার করে একটি প্রিন্সিপাল তৈরি করুন

গুগল ক্লাউড সার্চের জন্য ব্যবহারকারী এবং গ্রুপগুলোকে গুগল ইমেল অ্যাড্রেসে রিজলভ করতে হয়। রিপোজিটরি আইটেম ইন্ডেক্স করার সময়, কন্টেন্ট কানেক্টরগুলোর কাছে এই ইমেল অ্যাড্রেসগুলো নাও থাকতে পারে। তবে, কন্টেন্ট কানেক্টর SDK আপনাকে একটি আইটেম ইন্ডেক্স করার জন্য ইমেল অ্যাড্রেসের পরিবর্তে একটি এক্সটার্নাল আইডি (এমন একটি আইডি যা কোনো ব্যবহারকারী বা গ্রুপকে রিপোজিটরি আইটেমগুলোতে অ্যাক্সেস দেয়) ব্যবহার করার সুযোগ দেয়। এক্সটার্নাল আইডি ধারণকারী প্রিন্সিপাল তৈরি করতে getUserPrincipal মেথড অথবা getGroupPrincipal মেথড ব্যবহার করুন। Principal অবজেক্ট তৈরি করার জন্য ACL ক্লাসে আরও বেশ কিছু স্ট্যাটিক মেথড রয়েছে।

দ্রষ্টব্য: ব্যবহারকারীরা তাদের এক্সটার্নাল আইডি গুগল অ্যাকাউন্টের সাথে সিঙ্ক না হওয়া পর্যন্ত সার্চ রেজাল্টে আইটেম দেখতে পান না। আপনি এক্সটার্নাল ইউজার বা গ্রুপ আইডিগুলোকে একটি গুগল ইমেল অ্যাড্রেসের সাথে সিঙ্ক করতে একটি আইডেন্টিটি কানেক্টর ব্যবহার করতে পারেন। আরও তথ্যের জন্য, ‘একটি আইডেন্টিটি কানেক্টর তৈরি করুন ’ দেখুন।

কোনো আইটেমের আইডেন্টিটি রিম্যাপ করার পর, নতুন আইডেন্টিটি কার্যকর করার জন্য আপনাকে অবশ্যই আইটেমগুলো রিইনডেক্স করতে হবে। আরও তথ্যের জন্য, ‘আইডেন্টিটি রিম্যাপিং’ দেখুন।

ACL উত্তরাধিকার

ACL ইনহেরিটেন্স বলতে কোনো আইটেম এবং তার ইনহেরিটেন্স চেইনের সম্মিলিত ACL-এর উপর ভিত্তি করে একটি নির্দিষ্ট আইটেম ও ব্যবহারকারীর অনুমোদনকে বোঝায়। অনুমোদনের সিদ্ধান্তের নিয়মগুলো রিপোজিটরি এবং আইটেমের বৈশিষ্ট্যের উপর নির্ভর করে।

সেট উত্তরাধিকার

প্রতিটি আইটেমের সরাসরি অনুমোদিত প্রিন্সিপাল এবং সরাসরি অস্বীকৃত প্রিন্সিপাল থাকতে পারে, যা setReaders এবং setDeniedReaders মেথড ব্যবহার করে নির্দিষ্ট করা হয়। সরাসরি অনুমোদিত প্রিন্সিপাল হলো এমন একজন ব্যবহারকারী যাকে একটি ACL-এ কোনো আইটেমে সরাসরি অ্যাক্সেসের জন্য চিহ্নিত করা হয়। সরাসরি অস্বীকৃত প্রিন্সিপাল হলো এমন একজন ব্যবহারকারী যাকে একটি ACL-এ কোনো আইটেমে অ্যাক্সেস নেই বলে চিহ্নিত করা হয়।

একটি আইটেম setInheritFrom মেথড ব্যবহার করে ইনডিরেক্ট অ্যালাউড প্রিন্সিপাল এবং ইনডিরেক্ট ডিনাইড প্রিন্সিপালও উত্তরাধিকার সূত্রে পেতে পারে। একটি ইনডিরেক্ট অ্যালাউড প্রিন্সিপাল ACL ইনহেরিটেন্সের মাধ্যমে কোনো আইটেমে পরোক্ষ অ্যাক্সেস পায়। একটি ইনডিরেক্ট ডিনাইড প্রিন্সিপালকে ইনহেরিটেন্সের মাধ্যমে অ্যাক্সেস থেকে বঞ্চিত করা হয়।

দ্রষ্টব্য: যদি আপনি setInheritFrom মেথড ব্যবহার করে ইনহেরিটেন্স সেট করেন, তাহলে আপনাকে অবশ্যই setInheritanceType মেথড ব্যবহার করে ইনহেরিটেন্স টাইপও সেট করতে হবে। ইনহেরিটেন্স টাইপ সম্পর্কে তথ্যের জন্য, “ইনহেরিটেন্স টাইপ সেট করুন” অংশটি দেখুন।

চিত্র ১-এ দেখানো হয়েছে কীভাবে ` setInheritFrom মেথড ব্যবহার করে `principal` ইনহেরিট করতে হয়।

চিত্র ১. setInheritFrom মেথড।

চিত্র ১-এ এই প্রবেশাধিকার নিয়ন্ত্রণগুলো দেখানো হয়েছে:

• ব্যবহারকারী ১ হলেন দফা ‘ক’-এর একজন সরাসরি অনুমোদিত মূল ব্যক্তি।
• ব্যবহারকারী ২ হলেন দফা B-এর একজন সরাসরি অনুমোদিত অধ্যক্ষ।
• আইটেম B, আইটেম A-এর ACL উত্তরাধিকারসূত্রে পায়।

এই নিয়ন্ত্রণগুলোর উপর ভিত্তি করে, প্রবেশাধিকারের নিয়মগুলো হলো:

• ব্যবহারকারী ১, সুস্পষ্টভাবে নির্দিষ্ট না করা সত্ত্বেও, আইটেম B-এর একজন পরোক্ষ অনুমোদিত প্রধান; এই অ্যাক্সেসটি আইটেম A থেকে উত্তরাধিকারসূত্রে প্রাপ্ত।
• ব্যবহারকারী ২, দফা ‘ক’-এর একজন পরোক্ষ অনুমোদিত মূল ব্যক্তি নন।

উত্তরাধিকারের ধরণ সেট করুন

যদি আপনি setInheritFrom মেথড ব্যবহার করে ইনহেরিটেন্স সেট করেন, তাহলে আপনাকে অবশ্যই setInheritanceType মেথড ব্যবহার করে ইনহেরিটেন্স টাইপ সেট করতে হবে। ইনহেরিটেন্স টাইপ নির্ধারণ করে যে একটি চাইল্ড ACL কীভাবে একটি প্যারেন্ট ACL-এর সাথে যুক্ত হবে। Acl.InheritanceType তিনটি টাইপ ইমপ্লিমেন্ট করে:

• BOTH_PERMIT - শুধুমাত্র তখনই অ্যাক্সেস দিন যখন চাইল্ড এবং প্যারেন্ট উভয় ACL-ই অনুমতি দেয়।
• CHILD_OVERRIDE - বিরোধের ক্ষেত্রে চাইল্ড ACL, প্যারেন্ট ACL-এর উপর অগ্রাধিকার পায়। প্যারেন্ট অ্যাক্সেস অস্বীকার করলেও একজন ব্যবহারকারী চাইল্ড অ্যাক্সেস করতে পারে, অথবা প্যারেন্ট অনুমতি দিলেও চাইল্ড অ্যাক্সেস থেকে বঞ্চিত হতে পারে।
• PARENT_OVERRIDE - বিরোধের ক্ষেত্রে প্যারেন্ট ACL, চাইল্ড ACL-এর উপর অগ্রাধিকার পায়।

ক্লাউড সার্চ লিফ থেকে রুট পর্যন্ত ACL ইনহেরিটেন্স চেইন মূল্যায়ন করে। এই মূল্যায়ন চাইল্ড এবং তার প্যারেন্টদের দিয়ে শুরু হয় এবং রুট প্যারেন্ট পর্যন্ত অগ্রসর হতে পারে।

উদাহরণস্বরূপ, যদি চাইল্ড সিস্টেমটি CHILD_OVERRIDE ব্যবহার করে এবং ব্যবহারকারীর অ্যাক্সেস থাকে, তাহলে ক্লাউড সার্চের প্যারেন্ট সিস্টেম মূল্যায়ন করার প্রয়োজন হয় না। তবে, যদি চাইল্ড সিস্টেমটি PARENT_OVERRIDE বা BOTH_PERMIT ব্যবহার করে, তাহলে ক্লাউড সার্চ চেইনের উপরের দিকে মূল্যায়ন চালিয়ে যায়।

নিয়ন্ত্রণ এবং আইটেম মুছে ফেলা

কোনো আইটেমকে ইন্ডেক্স করার সময়, আপনি IndexingItemBuilder ক্লাসের setContainer মেথড ব্যবহার করে সেটিকে একটি কন্টেইনার হিসেবে লেবেল করতে পারেন। এই সম্পর্কটি ভৌত ​​স্তরবিন্যাস স্থাপন করে এবং সঠিক ডিলিট হওয়া নিশ্চিত করে। যখন আপনি একটি কন্টেইনার ডিলিট করেন, তখন এর ভেতরের আইটেমগুলোও ডিলিট হয়ে যায়।

ধারণ সম্পর্কগুলো ACL উত্তরাধিকারের নিয়ম থেকে স্বাধীন। উদাহরণস্বরূপ, একটি ফোল্ডারে মুছে ফেলার উদ্দেশ্যে একটি ফাইল থাকতে পারে, কিন্তু ফাইলটি তার ACL অন্য একটি ফোল্ডার থেকে উত্তরাধিকার সূত্রে পেতে পারে। একটি ফোল্ডার মুছে ফেললে তার ACL উত্তরাধিকার সূত্রে পাওয়া আইটেমগুলো মুছে যায় না, যদি না সেই আইটেমগুলোও তার ধারণ শ্রেণিবিন্যাসের মধ্যে থাকে।

চিত্র ২-এ এই প্রবেশাধিকার নিয়ন্ত্রণগুলো দেখানো হয়েছে:

• ব্যবহারকারী ১ হলেন দফা ‘ক’-এর একজন সরাসরি অনুমোদিত মূল ব্যক্তি।
• ব্যবহারকারী ২ হলেন দফা B-এর একজন সরাসরি অনুমোদিত অধ্যক্ষ।
• ব্যবহারকারী ৩ হলেন দফা C-এর একজন সরাসরি অনুমোদিত প্রধান।
• আইটেম C, আইটেম A-এর ACL উত্তরাধিকারসূত্রে পায়।
• আইটেম B, আইটেম A-কে তার ধারক হিসেবে উল্লেখ করে।
• আইটেম C, আইটেম B-কে তার ধারক হিসেবে উল্লেখ করে।

এই নিয়ন্ত্রণগুলোর উপর ভিত্তি করে, প্রবেশাধিকারের নিয়মগুলো হলো:

• setInheritFrom মেথডটির মাধ্যমে পরোক্ষ অ্যাক্সেস পাওয়া যায়। ব্যবহারকারী ১ আইটেম C অ্যাক্সেস করতে পারে, কারণ এটি আইটেম A থেকে ইনহেরিট করেছে।
• পরোক্ষ প্রবেশাধিকার আবদ্ধকরণ থেকে আসে না। ব্যবহারকারী ২ আইটেম C অ্যাক্সেস করতে পারবে না।

চিত্র ২. setInheritFrom মেথডের ব্যবহার।

ধারণ থেকে ACL উত্তরাধিকারের পৃথকীকরণ আপনাকে অনেক কাঠামো মডেল করতে দেয়।

যখন আপনি কোনো আইটেম মুছে ফেলেন:

• যে কোনো আইটেমে মুছে ফেলা আইটেমটি থাকলে তা অনুসন্ধানযোগ্য থাকে না এবং মুছে ফেলার জন্য নির্ধারিত হয়।
• setInheritFrom এ মুছে ফেলা আইটেমটি উল্লেখ করা যেকোনো আইটেম অনুসন্ধানযোগ্য থাকে না।

যদি কোনো রিসোর্স মুছে ফেলা আইটেমের জন্য setInheritFrom ব্যবহার করে, কিন্তু তার কোনো কন্টেইনার সেট করা না থাকে বা তার হায়ারার্কিতে কোনো মুছে ফেলা আইটেম না থাকে, তাহলে আইটেমটি ডেটা সোর্সে থেকে যায়। এটি মুছে ফেলার দায়িত্ব আপনার।

চিত্র ৩-এ একটি আইটেম শ্রেণিবিন্যাস থেকে মুছে ফেলার একটি উদাহরণ দেখানো হয়েছে।

চিত্র ৩. কোনো আইটেম মুছে ফেলা এবং ACL উত্তরাধিকার।

চিত্র ৩-এ এই প্রবেশাধিকার নিয়ন্ত্রণগুলো দেখানো হয়েছে:

• ব্যবহারকারী ১ হলেন দফা ‘ক’-এর একজন সরাসরি অনুমোদিত মূল ব্যক্তি।
• ব্যবহারকারী ২ হলেন আইটেম D-এর একজন সরাসরি অনুমোদিত অধ্যক্ষ।
• আইটেম D এবং E উভয়ই আইটেম A থেকে উত্তরাধিকার সূত্রে প্রাপ্ত।
• আইটেম D, আইটেম A-কে তার ধারক হিসেবে উল্লেখ করে।
• আইটেম A এবং E হলো রুট-লেভেলের আইটেম।

ডিলিট করার প্রক্রিয়াটি কন্টেইনার রেফারেন্স জুড়ে পর্যায়ক্রমে ঘটে। যখন আপনি আইটেম A ডিলিট করেন:

• setInheritFrom রেফারেন্সের সমস্ত বংশধর অ্যাক্সেস হারায়।
• ব্যবহারকারীরা আর আইটেম A অ্যাক্সেস করতে পারবেন না।
• আইটেম D স্বয়ংক্রিয়ভাবে মুছে যায় এবং অপ্রাপ্য হয়ে পড়ে।
• আইটেম E মুছে ফেলা হয় না, কিন্তু এটি নাগালের বাইরে এবং অনুসন্ধান অযোগ্য হয়ে পড়ে।