মানচিত্র ACLs

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

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

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

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

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

এই নথিতে ACL মডেল এবং তৈরি করার ধারণাগুলি অন্তর্ভুক্ত করা হয়েছে, যেমন উত্তরাধিকার এবং নিয়ন্ত্রণ।

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

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

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

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

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

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

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

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

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

দ্রষ্টব্য: যদি আপনি setInheritFrom পদ্ধতি ব্যবহার করে উত্তরাধিকার সেট করেন, তাহলে আপনাকে setInheritanceType পদ্ধতি ব্যবহার করে উত্তরাধিকারের ধরণও সেট করতে হবে। উত্তরাধিকারের ধরণ সম্পর্কে তথ্যের জন্য, Set উত্তরাধিকারের ধরণ দেখুন।

চিত্র ১-এ দেখানো হয়েছে কিভাবে setInheritFrom পদ্ধতি ব্যবহার করে প্রিন্সিপালগুলি উত্তরাধিকার সূত্রে পেতে হয়।

চিত্র ১. setInheritFrom পদ্ধতি।

চিত্র ১ এই অ্যাক্সেস নিয়ন্ত্রণগুলিকে প্রতিনিধিত্ব করে:

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

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

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

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

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

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

ক্লাউড সার্চ পাতা থেকে মূল পর্যন্ত ACL উত্তরাধিকার শৃঙ্খল মূল্যায়ন করে। মূল্যায়ন শিশু এবং তার পিতামাতার সাথে শুরু হয় এবং মূল পিতামাতার কাছে অগ্রসর হতে পারে।

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

কন্টেনমেন্ট এবং আইটেম মুছে ফেলা

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

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

চিত্র ২ এই অ্যাক্সেস নিয়ন্ত্রণগুলিকে প্রতিনিধিত্ব করে:

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

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

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

চিত্র ২। ব্যবহৃত setInheritFrom পদ্ধতি।

ACL উত্তরাধিকারকে কন্টেনমেন্ট থেকে পৃথক করার মাধ্যমে আপনি অনেক কাঠামো মডেল করতে পারবেন।

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

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

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

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

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

চিত্র ৩ এই অ্যাক্সেস নিয়ন্ত্রণগুলিকে প্রতিনিধিত্ব করে:

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

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

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