মানচিত্র ACLs

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

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

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

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

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

এই নথির অবশিষ্ট অংশে কিছু ধারণা রয়েছে যা আপনাকে ACLs মডেল এবং তৈরি করতে জানতে হবে, যেমন উত্তরাধিকার এবং নিয়ন্ত্রণ।

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

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

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

সতর্কতা: একটি আইটেমের পরিচয় অন্য পরিচয়ে রিম্যাপ করার পরে, নতুন পরিচয় ধরে রাখার জন্য আপনাকে অবশ্যই আইটেমগুলিকে পুনঃসূচীকরণ করতে হবে। আরও তথ্যের জন্য, রিম্যাপিং পরিচয় পড়ুন।

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

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

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

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

একটি আইটেম setInheritFrom() পদ্ধতি ব্যবহার করে পরোক্ষ অনুমোদিত প্রিন্সিপাল এবং পরোক্ষ অস্বীকৃত প্রিন্সিপালের উত্তরাধিকারী হতে পারে। একজন পরোক্ষ অনুমোদিত প্রিন্সিপাল হলেন একজন ব্যবহারকারী যিনি, ACL উত্তরাধিকারের মাধ্যমে, একটি নির্দিষ্ট আইটেমে পরোক্ষ অ্যাক্সেস রয়েছে। একজন পরোক্ষ অস্বীকৃত প্রিন্সিপ্যাল ​​হল একজন ব্যবহারকারী যিনি, ACL উত্তরাধিকারের মাধ্যমে, একটি নির্দিষ্ট আইটেমের অ্যাক্সেস অস্বীকার করেন।

দ্রষ্টব্য: আপনি setInheritFrom() পদ্ধতি ব্যবহার করে উত্তরাধিকার সেট করলে, আপনাকে অবশ্যই setInheritanceType() পদ্ধতি ব্যবহার করে উত্তরাধিকারের ধরণ সেট করতে হবে। উত্তরাধিকারের প্রকারের তথ্যের জন্য, উত্তরাধিকারের ধরন সেট করুন দেখুন।

চিত্র 1 দেখায় কিভাবে setInheritFrom() পদ্ধতিটি পরোক্ষ অনুমোদিত এবং পরোক্ষ অস্বীকৃত প্রিন্সিপালের উত্তরাধিকারী হতে ব্যবহৃত হয়।

চিত্র 1. setInheritFrom() পদ্ধতি।

এই অ্যাক্সেস নিয়ন্ত্রণগুলি চিত্র 1 এ উপস্থাপন করা হয়েছে:

• ব্যবহারকারী 1 হল আইটেম A এর সরাসরি অনুমোদিত প্রধান।
• ব্যবহারকারী 2 হল আইটেম B এর সরাসরি অনুমোদিত প্রধান।
• আইটেম B আইটেম A-এর ACL উত্তরাধিকার সূত্রে পায়।

অ্যাক্সেস নিয়ন্ত্রণের উপর ভিত্তি করে, অ্যাক্সেসের নিয়মগুলি হল:

• ব্যবহারকারী 1 আইটেম B এর একটি পরোক্ষ অনুমোদিত অধ্যক্ষ হতে আইটেম B এর প্রধান হিসাবে স্পষ্টভাবে নির্দিষ্ট করার প্রয়োজন নেই; অ্যাক্সেস উত্তরাধিকারসূত্রে প্রাপ্ত কারণ ব্যবহারকারী 1 আইটেম A এর সরাসরি অনুমোদিত প্রধান হিসাবে তালিকাভুক্ত এবং আইটেম B আইটেম A থেকে তার ACL উত্তরাধিকার সূত্রে প্রাপ্ত।
• ব্যবহারকারী 2 আইটেম 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 উত্তরাধিকার শৃঙ্খল মূল্যায়ন করার সময়, মূল্যায়নের ক্রম অনুমোদনের সিদ্ধান্তের ফলাফল পরিবর্তন করতে পারে। ক্লাউড অনুসন্ধান ACL উত্তরাধিকার চেইনের জন্য মূল্যায়নের পাতা-থেকে-মূল ক্রম প্রদান করে। বিশেষভাবে, একটি চেইনের জন্য ACL সিদ্ধান্তটি একটি শিশুর তার পিতামাতার সাথে মূল্যায়নের মাধ্যমে শুরু হয় এবং এটি মূল অভিভাবকের কাছে সমস্ত উপায়ে অগ্রসর হতে পারে।

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

ধারণ এবং আইটেম মুছে ফেলা

একটি আইটেম ইন্ডেক্স করার সময়, আপনি IndexingItemBuilder ক্লাসের setContainer() পদ্ধতি ব্যবহার করে একটি আইটেমকে একটি ধারক হিসাবে লেবেল করতে পারেন। কন্টেইনার/কন্টেইনার সম্পর্ক আইটেমগুলির শারীরিক শ্রেণিবিন্যাস স্থাপন করে এবং আইটেমগুলি সঠিকভাবে মুছে ফেলা হয়েছে তা নিশ্চিত করে। যখন একটি ধারক মুছে ফেলা হয়, এতে থাকা আইটেমগুলিও মুছে ফেলা হয়।

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

এই অ্যাক্সেস নিয়ন্ত্রণগুলি চিত্র 2 এ উপস্থাপন করা হয়েছে:

• ব্যবহারকারী 1 হল আইটেম A এর সরাসরি অনুমোদিত প্রধান।
• ব্যবহারকারী 2 হল আইটেম B এর সরাসরি অনুমোদিত প্রধান।
• ব্যবহারকারী 3 হল আইটেম C এর সরাসরি অনুমোদিত প্রধান।
• আইটেম সি আইটেম A-এর ACL উত্তরাধিকার সূত্রে পায়।
• আইটেম বি আইটেম A এর ধারক হিসাবে নাম দেয়।
• আইটেম C এর ধারক হিসাবে আইটেম B এর নাম দেয়।

অ্যাক্সেস নিয়ন্ত্রণের উপর ভিত্তি করে, অ্যাক্সেসের নিয়মগুলি হল:

• পরোক্ষ অ্যাক্সেস setInheritFrom() পদ্ধতি থেকে আসে। অতএব, ব্যবহারকারী 1 আইটেম C অ্যাক্সেস করতে পারে কারণ আইটেম C আইটেম A-এর ACL উত্তরাধিকারসূত্রে পায়।
• আইটেম B দ্বারা থাকা আইটেম C থেকে পরোক্ষ অ্যাক্সেস আসে না । তাই, ব্যবহারকারী 2 আইটেম C অ্যাক্সেস করতে পারে না।

চিত্র 2. setInheritFrom() পদ্ধতি ব্যবহার করা হচ্ছে।

কন্টেনমেন্ট হায়ারার্কি থেকে ACL উত্তরাধিকারের বিচ্ছেদ আপনাকে বিভিন্ন বিদ্যমান কাঠামোর মডেল করতে দেয়।

যখন একটি আইটেম সফলভাবে মুছে ফেলা হয়:

• যে কোনো আইটেম যেটিতে একটি মুছে ফেলা আইটেম রয়েছে তা অনুসন্ধানের অযোগ্য হয়ে যায় এবং Google এর ডেটা উত্স থেকে মুছে ফেলার জন্য নির্ধারিত হয়৷
• setInheritFrom() পদ্ধতি ব্যবহার করে মুছে ফেলা আইটেমটি নির্দিষ্ট করেছে এমন যেকোন আইটেম অনুসন্ধানযোগ্য নয়।

যদি একটি রিসোর্সে setInheritFrom() পদ্ধতি ব্যবহার করে একটি মুছে ফেলা আইটেম থাকে, কিন্তু এটিতে setContainer() ব্যবহার করে একটি কন্টেইনার সেট না থাকে, বা এর কন্টেনমেন্ট শ্রেণিবিন্যাসে কোনো মুছে ফেলা আইটেম না থাকে, তাহলে সেই আইটেমটি এবং এর ডেটা Google-এর ডেটা উৎসে থেকে যায়। আপনি আইটেম মুছে ফেলার জন্য দায়ী.

চিত্র 3 একটি আইটেম অনুক্রমের জন্য কীভাবে মুছে ফেলা কাজ করে তার একটি উদাহরণ দেখায়।

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

এই অ্যাক্সেস নিয়ন্ত্রণগুলি চিত্র 3 এ উপস্থাপন করা হয়েছে:

• ব্যবহারকারী 1 হল আইটেম A এর সরাসরি অনুমোদিত প্রধান।
• ব্যবহারকারী 2 হল আইটেম D এর সরাসরি অনুমোদিত প্রধান।
• আইটেম D এবং আইটেম E উভয়ই আইটেম A-এর ACL উত্তরাধিকারী।
• আইটেম ডি নাম আইটেম A এর ধারক হিসাবে.
• আইটেম A এবং E রুট-স্তরের আইটেম কারণ তাদের একটি ধারক আইটেম নেই।

কন্টেইনার রেফারেন্সের মাধ্যমে ক্যাসকেড মুছে দেয়। যখন আইটেম A মুছে ফেলা হয়:

• setInheritFrom() রেফারেন্সের সমস্ত বংশধর সকল ব্যবহারকারীর জন্য অ্যাক্সেস হারাবে।
• কোনো ব্যবহারকারী আইটেম A অ্যাক্সেস করতে পারবেন না।
• আইটেম D স্পষ্টভাবে মুছে ফেলা হয়েছে. কোনো ব্যবহারকারী আইটেম D অ্যাক্সেস করতে পারবেন না।
• আইটেম E মুছে ফেলা হয় না, কারণ মুছে ফেলা শুধুমাত্র কন্টেইনার রেফারেন্সের মাধ্যমে ক্যাসকেড হয়।
• আইটেম E পৌঁছানো যায় না এবং কোনো ব্যবহারকারী আইটেম E অনুসন্ধান করতে সক্ষম হয় না।