আপনার অ্যাপ সিকিউর রাখতে, আপনাকে কন্ট্রোল করতে হবে কে এবং কী অ্যাক্সেস করতে পারে। অ্যাক্সেস কন্ট্রোল দুটি ক্যাটাগরিতে ভাগ করা যায়: অথেন্টিকেশন—"কে"কে অনুমতি দেবে—এবং অথরাইজেশন—"কী"তে তারা অ্যাক্সেস করতে পারবে।
অথেন্টিকেশন অন্য দিনের বিষয়, কিন্তু ইউজার অথরাইজেশনের কথা হলে, আপনার সাধারণত দুটি পথ থাকে: রোল-ভিত্তিক বা রিসোর্স-ভিত্তিক স্ট্র্যাটেজি ব্যবহার করা।
এই দুই-ভাগী সিরিজে, আমরা একটি রুবি অন রেলস ব্লগ অ্যাপ্লিকেশনের জন্য Action Policy জেম ব্যবহারে গভীরভাবে ডুব করব।
এই পার্টে, আমরা Action Policy-এর বেসিকস কভার করব।
চলুন শুরু করি!
প্রে-রেকুইজিটস (Prerequisites)
- Ruby (আমরা ৩.২.২ ভার্সন ব্যবহার করছি)
- Rails (৭.০.৭ ভার্সন ব্যবহার করছি)
- রুবি ব্যবহার করার কিছু এক্সপেরিয়েন্স
চলুন রিসোর্স-ভিত্তিক অথরাইজেশন ডিফাইন করি।
রিসোর্স-ভিত্তিক অথরাইজেশন কী?
যেখানে রোল-ভিত্তিক অথরাইজেশন প্রি-ডিফাইনড ইউজার রোল অনুযায়ী ইউজার পারমিশন সেট করার ওপর ফোকাস করে, সেখানে রিসোর্স-ভিত্তিক অথরাইজেশন অ্যাপ্লিকেশনের ভেতরের আসল রিসোর্সের ওপর রুল সেট করে অ্যাক্সেস এনফোর্স করে। প্রতিটি রিসোর্স একটি পলিসির সাথে জড়িত থাকে যা স্পষ্টভাবে ডিফাইন করে একজন ইউজার সেই রিসোর্সে কী করতে পারবে।
এই আর্টিকেল রিসোর্স-ভিত্তিক অথরাইজেশনের ওপর ফোকাসড হলেও, দুটি অথরাইজেশন স্ট্র্যাটেজির পার্থক্য জানা আপনাকে প্রতিটির ক্যাপাবিলিটি ভালোভাবে বুঝতে সাহায্য করবে।
রোল-ভিত্তিক অথরাইজেশন কখন ব্যবহার করবেন
রোল-ভিত্তিক অথরাইজেশন ব্যবহার করা উচিত:
- সিম্পল অ্যাপ্লিকেশন - আপনি যদি একটি স্ট্রেইটফরওয়ার্ড পারমিশন সিস্টেম এবং কম ইউজার রোলোয়ালা অ্যাপে কাজ করেন, তবে রোল-ভিত্তিক অথরাইজেশন স্ট্র্যাটেজি আপনার জন্য কাজ করতে পারে।
- সুস্পষ্ট ইউজার গ্রুপ - আপনার অ্যাপে যদি "অ্যাডমিন", "এডিটর", "রাইটার" ইত্যাদি সুস্পষ্ট ইউজার গ্রুপ থাকে, তবে রোল-ভিত্তিক অথরাইজেশন ব্যবহার করুন কারণ এটি ইউজার রোল লেভেলে অ্যাক্সেস কন্ট্রোল হ্যান্ডেল করে।
রিসোর্স-ভিত্তিক অথরাইজেশন কখন ব্যবহার করবেন
রিসোর্স-ভিত্তিক অথরাইজেশন উপযোগী:
- ডাইনামিক বা কমপ্লেক্স অ্যাক্সেস কন্ট্রোল - যখন আপনার অ্যাপ্লিকেশনের অথরাইজেশন 니ডস ঘন ঘন পরিবর্তন হয় বা ডাইনামিক কন্ডিশন দ্বারা নির্ধারিত হয়, তবে রিসোর্স-ভিত্তিক অথরাইজেশন সিস্টেম একটি ভালো চয়েস।
- ফাইন-গ্রেইনড কন্ট্রোল - উপযোগী যখন আপনাকে একাধিক কন্ডিশন ভিত্তিক রিসোর্সে অ্যাক্সেস অনুমতি বা অস্বীকৃতি দিতে হয় (উদাহরণস্বরূপ, একটি রেলস হেল্পডেস্ক অ্যাপ যেখানে ইউজাররা ডাইনামিক ক্যাটেগরির ভিত্তিতে সাপোর্ট টিকেট সাবমিট করে)। ধরে নিই সাপোর্ট স্টাফ ক্যাটেগরি অনুযায়ী টিকেট অ্যাসাইন করা হয়। এটি এমন একটি সিনেরিও যেখানে রিসোর্স-ভিত্তিক অথরাইজেশন সত্যিকারের অর্থে চমকে উঠবে।
- অবজেক্ট-অরিয়েন্টেড কন্ট্রোল - যেহেতু রিসোর্স-ভিত্তিক অথরাইজেশন অবজেক্ট লেভেলে হয়, জটিল অবজেক্ট-অরিয়েন্টেড রুল ডিফাইন করা সহজ হয় যখন আপনি রিসোর্স-ভিত্তিক অথরাইজেশন টেকনিক ব্যবহার করেন।
কথা হলো, আপনি রোল-ভিত্তিক এবং রিসোর্স-ভিত্তিক অথরাইজেশনের মধ্যে যেকোনো একটি বেছে নেন, সেটা আপনার অ্যাপ্লিকেশনের ইউনিক ক্যারেক্টারিস্টিক্সের ওপর নির্ভর করবে।
চলুন এখন আমাদের দৃষ্টি Action Policy জেমের দিকে ফিরিয়ে আনি।
রুবি এবং রেলসের জন্য Action Policy জেম
Action Policy রুবি এবং রেলস অ্যাপের জন্য একটি ফ্লেক্সিবল, এক্সটেনসিবল এবং পারফরম্যান্ট অথরাইজেশন ফ্রেমওয়ার্ক। এটি মাল্টিপল ক্যাশিং স্ট্র্যাটেজি আউট-অফ-দ-বক্স ব্যবহার করে, যা এটাকে খুব দ্রুত করে তোলে, বিশেষ করে যদি আপনার অথরাইজেশন রুল ডাটাবেস কুয়েরি রিকোয়ার করে।
এই জেমকে রিসোর্স-ভিত্তিক রুল বানাতে আইডিয়াল করে তোলে এর কাস্টোমাইজেবিলিটি। এটি বেশ কিছু রুবি ক্লাস এবং মডিউল প্রদান করে যেগুলো বহুবিধভাবে কম্বাইন করা যায়। আপনি প্রায় যেকোনো জায়গায় ফাইন-গ্রেইনড অ্যাক্সেস কন্ট্রোল রুল সেট করতে পারেন রেলস কন্ট্রোলারের বাইরে।
Action Policy প্রজেক্ট হোমপেজ চেক আউট করুন আরও জানতে।
এখন আমরা আজ বানানো রেলস অ্যাপের ওপর যাই।
রেলস অ্যাপ তৈরি করা
আগামীতে, আমরা একটি রেলস ৭ ব্লগ অ্যাপ্লিকেশন রেফারেন্স করব যেখানে ইউজাররা পোস্ট Create, Read, Update, এবং Delete (CRUD) করতে পারবে।
আমরা প্রোগ্রেসিভলি Post মডেলের জন্য একটি অ্যাকশন পলিসি ডিফাইন করব যা রিসোর্স-ভিত্তিক অ্যাক্সেস কন্ট্রোল অফার করে। আপনি শিখবেন কীভাবে Action Policy ব্যবহার করে এই অ্যাক্সেস কন্ট্রোল স্ট্র্যাটেজি কাজ করাতে হয়।
আগে যান এবং একটি নতুন রেলস অ্যাপ্লিকেশন জেনারেট করুন:
নোট: আমরা আমাদের উদাহরণ অ্যাপের জন্য Pico CSS স্টাইলস ব্যবহার করব, কিন্তু আপনি যা পছন্দ করেন সেটা ব্যবহার করতে পারেন।
তারপর দ্রুত একটি Post রিসোর্স স্কাফোল্ড করি যা আমরা টিউটোরিয়ালের বাকি অংশে ব্যবহার করব:
এখন rails db:migrate দিয়ে মাইগ্রেশন রান করুন।
ইউজার অথেন্টিকেশন সেটআপ করা
যতটুকু এই আর্টিকেল ইউজার অথরাইজেশনের ওপর, ততটুকু একটি জরুরি বিষয় কভার করতে হবে: ইউজার অথেন্টিকেশন। এর বিনা, আমরা পরবর্তীতে যে কোনো অথরাইজেশন পলিসি ডিফাইন করার চেষ্টা করব, সেটা بےকার। কিন্তু স্ক্র্যাচ থেকে অথেন্টিকেশন লিখতে হবে না। চলুন Devise ব্যবহার করি।
Devise ইনস্টল করা
Gemfile-এ Devise জেম যোগ করে শুরু করুন:
তারপর ইনস্টল করুন এবং একটি User মডেল জেনারেট করুন:
এছাড়া, অ্যাপের ডেভেলপমেন্ট কনফিগারেশনে config.action_mailer.default_url_options = { host: 'localhost', port: 3000 } যোগ করতে ভুলবেন না।
এরপর, Post রিসোর্সের জন্য আলাদা আলাদা ইউজার অ্যাক্সেস সিনেরিও টেস্ট করার জন্য কিছু বেসিক ইউজার রোল ইমপ্লিমেন্ট করি।
বেসিক ইউজার রোল ডিফাইন করা
প্রথমে, ইউজার টেবিলে role কলাম যোগ করুন। এই কমান্ড রান করে একটি মাইগ্রেশন জেনারেট করুন:
নোট: আমরা রোলের জন্য ইন্টিজার ডেটা টাইপ ব্যবহার করছি, যাতে enum ব্যবহার করতে পারি—রোল ইমপ্লিমেন্ট করার একটি কুইক এবং সহজ পদ্ধতি।
এখন rails db:migrate দিয়ে মাইগ্রেশন রান করুন, তারপর User মডেল খুলুন এবং এডিট করুন:
এটা হয়ে গেলে, চলুন Action Policy ইনস্টল করার ওপর ফোকাস করি।
রুবি এবং রেলসের জন্য Action Policy সেটআপ
অ্যাপের Gemfile খুলুন এবং নিচের লাইনটি যোগ করুন:
তারপর bundle install কমান্ড রান করুন Action Policy ইনস্টল করার জন্য।
নিচের কমান্ড রান করে ইনস্টলেশন ফাইনালাইজ করুন:
এটি আমাদের একটি বেস দেবে—app/policies আন্ডারে ApplicationPolicy ক্লাস:
Action Policy-এর বেসিক ব্যবহার
Action Policy-এর কোর ফাউন্ডেশন হলো একটি policy ক্লাস, ApplicationPolicy, যেখানে আপনি গ্লোবাল কনফিগারেশন ডিফাইন করতে পারেন যেখান থেকে সকল পলিসি ইনহেরিট করতে পারে। একটি ভালো রিকমেন্ডেশন হলো সকল পলিসি app/policies আন্ডারে রাখা, এবং আপনার অ্যাপের রিসোর্স অনুযায়ী পলিসি আলাদা করা। উদাহরণস্বরূপ, আপনার যদি Post রিসোর্স থাকে, তবে সংশ্লিষ্ট পলিসি হবে PostPolicy, Comment রিসোর্সের সাথে CommentPolicy থাকবে, এবং így vidare।
Action Policy-র সাথে কাজ করার সময় আর একটা কথা মনে রাখতে হবে: রুল ডেফিনিশন পলিসি ক্লাসের পাবলিক মেথডের ভিতরে হতে হবে। প্রাইভেট মেথড ব্যবহার করলে এরর উঠবে।
চলুন, এই ইনফরমেশন ব্যবহার করে একটি PostPolicy তৈরি করি যেখানে আমরা প্রোগ্রেসিভলি বিভিন্ন লেভেলের ইউজার অ্যাক্সেস বানাব।
আমাদের প্রথম পলিসি তৈরি করা
app/policies আন্ডারে post_policy.rb নামে একটি নতুন ফাইল তৈরি করুন:
এখানে, আমরা Post রিসোর্সের ওপর একটি সিম্পল রুল ডিফাইন করছি যে কেউ একটি Post অ্যাক্সেস করতে পারে।
পোস্টগুলো ইউজারের সাথে অ্যাসোসিয়েট করা
এই নতুন পোস্ট পলিসির সাথে কাজ করতে, আমাদের আগে জেনারেট করা Post রিসোর্স মডিফাই করতে হবে যাতে ক্রিয়েশন সময় লগড-ইন ইউজারের সাথে অ্যাসোসিয়েট হয় (পোস্ট টেবিলে user_id কলাম যোগ করে):
তারপর rails db:migrate দিয়ে মাইগ্রেশন রান করুন।
পরবর্তী, আমাদের পোস্টস কন্ট্রোলার মডিফাই করতে হবে এই পরিবর্তনের জন্য। প্রথমে, user_id কে আলাউড post_params-এ যোগ করুন:
তারপর create অ্যাকশন মডিফাই করুন:
এখন, PostsController সিকিউর করি।
কন্ট্রোলারে অথরাইজেশন ইমপ্লিমেন্ট করা
আমাদের PostsController মডিফাই করতে হবে একটি কলব্যাক দিয়ে যাতে শুধু লগড-ইন ইউজারদের অ্যাক্সেস দেওয়া হয়:
এরপর, নতুন Post পলিসি ব্যবহার করে কিছু বেসিক ইউজার অ্যাক্সেস কন্ট্রোল যোগ করি:
এখানে, আমরা পোস্টস কন্ট্রোলারের update এবং destroy অ্যাকশনে একটি অ্যাক্সেস রুল ডিফাইন করছি। আমরা নির্দিষ্ট করছি যে একটি পোস্টের লেখক (অথবা "author" রোলবিশিষ্ট একজন ইউজার) একটি পোস্ট আপডেট করতে পারবে, কিন্তু শুধু পোস্টের লেখকই একটি পোস্ট ডিলিট করতে পারবে।
কুইক টিপ: Action Policy Devise-দ্বারা প্রদত্ত current_user রেফারেন্স করতে পারে এবং এটাকে পলিসির ভিতরে user এ অ্যাসাইন করতে পারে।
এরপর, আমাদের অ্যাক্সেস রুলটি পোস্টস কন্ট্রোলারে এইভাবে ব্যবহার করতে হবে:
অ্যাক্সেস রুল পোস্টস কন্ট্রোলারে অ্যাপ্লাই হয়ে গেলে, আমাদের পরবর্তী করণীয় হলো ভিউগুলো প্রোটেক্ট করা।
অথরাইজেশন দিয়ে ভিউ প্রোটেক্ট করা
নিচের স্ক্রিনশটে, <user2@example.com> ইমেইল এবং "reader" রোলবিশিষ্ট একজন ইউজার লগড-ইন আছে। দেখতে পাচ্ছেন, এই ইউজার <user@example.com> দ্বারা তৈরি পোস্টটি দেখতে পাচ্ছে, এবং সে এই পোস্টের এডিট এবং ডিলিট লিংকও অ্যাক্সেস করতে পারছে। এটি আদর্শ নয়—এডিট এবং ডিলিট লিংক শুধু পোস্টের লেখকের জন্য উপলব্ধ হওয়া উচিত।
আমাদের প্রথম টাস্ক হবে এই লিংকগুলো সেই ইউজারদের জন্য রিমুভ করা যারা পোস্টের লেখক নয়। যেহেতু আমরা ইতিমধ্যে এই অ্যাক্সেস রুল ডিফাইন করেছি, আমাদের শুধু show ভিউতে এটি অ্যাপ্লাই করতে হবে Action Policy-এর চমৎকার allowed_to? মেথড ব্যবহার করে:
এই রুল অ্যাপ্লাই হয়ে গেলে, আমরা পোস্টের show পেজ রিফ্রেশ করে দেখতে পারি কী পাওয়া যায়:
সেই ইউজার যিনি আগে অ্যাক্সেস পাতেন, এখন পোস্টের ভিউতে থাকাকালীন সীমিত কাজ করতে পারছেন।
শেষ কথা
এই দুই-ভাগী সিরিজের প্রথম পার্টে, আমরা অথরাইজেশন জেম Action Policy-এর কিছু বেসিক শিখলাম।
দ্বিতীয় এবং চূড়ান্ত পার্টে, আমরা কিছু আরও অ্যাডভান্সড ইউজ কেস এক্সপ্লোর করব।
হ্যাপি কোডিং!
P.S. রুবি ম্যাজিক পোস্টগুলো প্রেস থেকে বের होते সাথে পেতে চাইলে আমাদের রুবি ম্যাজিক নিউজলেটার সাবস্ক্রাইব করুন এবং একটিও পোস্ট মিস করবেন না!
