এমভিসি এবং কাদের দ্বারা ব্যবহারকারীর অনুমতি যাচাই করা উচিত?


26

মডেল বা নিয়ামক ব্যবহারকারীর অনুমতি চেক করা উচিত? এবং অনুমতি চেকগুলি, ব্যবহারকারীর অবজেক্ট বা কোনও ব্যবহারকারীর পরিচালনা সহায়ক কে পরিচালনা করতে হবে?

এটা কোথায় হওয়া উচিত?

নিয়ামকটিতে চেক করা হচ্ছে:

class MyController {
  void performSomeAction() {
    if (user.hasRightPermissions()) {
      model.someAction();
    }
  }
  ...

কন্ট্রোলারে চেক থাকা মডেলগুলিকে সাধারণ ক্রিয়া তৈরি করতে সহায়তা করে, তাই আমরা সমস্ত যুক্তি নিয়ন্ত্রণকারীদের কাছে রাখতে পারি।

মডেলটি পরীক্ষা করা হচ্ছে:

class MyModel {
  void someAction() {
    if (user.hasRightPermissions()) {
      ...
    }
  }
  ...

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

আর কার দ্বারা?

একবার আমরা জায়গাটিতে স্থির হয়ে গেলে, চেকগুলি করা উচিত? ব্যবহারকারী?

Class User {
  bool hasPermissions(int permissionMask) {
    ...
  }
  ...

তবে তিনি কী কী আদায় করতে পারেন তা জানা ব্যবহারকারীর সত্যিই দায়িত্ব নয়, তাই সম্ভবত কোনও সহায়ক শ্রেণি?

Class UserManagement {
  bool hasPermissions(User user, int permissionMask) {
    ...
  }
  ...

আমি জানি যে কেবল একটি প্রশ্ন, খুব ভাল, একটি প্রশ্ন জিজ্ঞাসা করা সাধারণ, তবে আমি মনে করি এগুলির উত্তর একসাথে দেওয়া যেতে পারে।

উত্তর:


20

যথারীতি "এটি নির্ভর করে"

  • অনুমতি চেকগুলি যে কোনও জায়গায় কার্যকরভাবে কাজ করা উপযুক্ত যেখানে এটি স্থাপন করা সুবিধাজনক হবে,
  • তবে আপনি যদি কোনও প্রযুক্তিগত প্রশ্ন জিজ্ঞাসা করছেন তবে উত্তরটি হতে পারে 'চেকটি সম্পাদনের জন্য প্রয়োজনীয় ডেটার মালিকানাযুক্ত অবজেক্টে চেকগুলি রাখুন' (যা সম্ভবত নিয়ামক)।
  • তবে আপনি যদি দার্শনিক প্রশ্ন জিজ্ঞাসা করেন তবে আমি একটি বিকল্প উত্তর দেওয়ার পরামর্শ দিচ্ছি: ব্যবহারকারীদের এমন ক্রিয়াকলাপ দেখাবেন না যাতে তাদের সম্পাদনের অনুমতি দেওয়া হয় না

সুতরাং পরবর্তী ক্ষেত্রে আপনি বুলিয়ান সম্পত্তি হিসাবে প্রয়োগ করা নিয়ন্ত্রকের অনুমতি পরীক্ষা করতে পারেন এবং সেই সম্পত্তিটি ব্যবহারকারী-ইন্টারফেসের বোতাম বা প্যানেলের দৃশ্যমান সম্পত্তিতে আবদ্ধ করুন যা ক্রিয়া নিয়ন্ত্রণ করে

একজন ব্যবহারকারী হিসাবে, আমি যে কর্ম সম্পাদন করতে পারছি না তার বোতামগুলি দেখে হতাশাব্যঞ্জক; মনে হচ্ছে আমি মজা থেকে দূরে আছি;)


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

11
"আমি যে ক্রিয়াকলাপগুলি করতে পারছি না তার বোতামগুলি দেখে হতাশাব্যঞ্জক" -> আপনার নিজের পোস্টকে উজ্জীবিত করার চেষ্টা করুন :)
রোয়ান ফ্রিম্যান

5
ব্যবহারকারী যে ক্রিয়াকলাপ সম্পাদন করতে পারে না তার জন্য কেবল বোতামগুলি আড়াল করার পক্ষে এটি যথেষ্ট নয়, সার্ভারকে অনুমতিগুলির জন্য প্রতিটি অনুরোধ পরীক্ষা করতে হবে। তৃতীয় বুলেট আইটেমটি "বিকল্প উত্তর" নয়, অনুমতি সার্ভার-সাইডের জন্য এটি পরীক্ষা করা ছাড়াও এটি করার মতো কিছু।
Flimm

@ ফ্লিম সম্মত হয়েছে, যদি অনুরোধগুলি কোনও সার্ভার দ্বারা পরিচালনা করা হয়; নির্দিষ্ট প্রশ্নটি ছিল নিয়ামক শ্রেণির সম্পর্কে
স্টিভেন এ লো।

7

সুরক্ষা ক্রস কাটিয়া উদ্বেগ, তাই একাধিক স্তরে প্রয়োগ করা প্রয়োজন। নিম্নলিখিতটি এমভিসির জন্য উদাহরণ তবে ধারণাটি অন্যান্য আর্কিটেকচার এবং / বা নিদর্শনগুলির জন্য প্রযোজ্য, আপনাকে কেবল প্রয়োগের পয়েন্টগুলি সনাক্ত করতে হবে।

এটা কোথায় হওয়া উচিত?

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

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

অনুমতিগুলির ভিত্তিতে সংস্থানগুলি প্রদর্শিত হয়। এটি সাধারণত ডাটাবেস স্তরে করা হয়, যেহেতু আপনি ডাটাবেস থেকে সমস্ত কিছু টানতে চান না এবং তারপরে অনুমতিগুলি প্রয়োগ করতে চান না।

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

কে এটা করা উচিত?

স্পষ্টভাবে মডেল না। প্রতিটি স্তরের একটি প্রয়োগকারী পয়েন্ট থাকা উচিত যা অনুমোদন পরিচালনা করে। উপরের তির্যক পাঠ্য প্রতিটি স্তরের সম্ভাব্য প্রয়োগের পয়েন্টটি হাইলাইট করে।

কটাক্ষপাত আছে XACML । আপনাকে এটিকে যেমন বাস্তবায়ন করতে হবে না, তবে এটি আপনাকে কিছু দিকনির্দেশনা দেবে যা আপনি অনুসরণ করতে পারেন।


এটি সেরা উত্তর। কোনও কারণে শীর্ষস্থানীয় এবং অন্যরা নিয়ামক এবং দর্শন, বা দর্শন এবং মডেলগুলির মধ্যে পার্থক্যগুলি মোকাবেলা করে, যা ওপি জিজ্ঞাসা করে না। ধন্যবাদ!
redFur

1

আমি নিম্নলিখিত স্কিম ব্যবহার করি। বলা বাহুল্য যে বেশিরভাগ ব্যবহারকারীর অনুমতি চেক দুটি সাধারণ ক্ষেত্রে বিভক্ত করা যায়:

  • প্যারামিটারগুলির ক্রিয়াটি পরীক্ষা না করে ব্যবহারকারীর ভূমিকার ভিত্তিতে নিয়ন্ত্রক ক্রিয়ায় ব্যবহারকারী অ্যাক্সেস ডেকে আনা হয়,
  • নির্দিষ্ট ব্যবহারকারী এবং নির্দিষ্ট মডেলের মধ্যে কোনও যুক্তি বা সম্পর্কের ভিত্তিতে মডেলটিতে ব্যবহারকারী অ্যাক্সেস।

বৈশিষ্ট্যগুলি পরীক্ষা না করে নিয়ামক অ্যাক্সেস অ্যাক্সেস সাধারণত এমভিসি ফ্রেমওয়ার্কগুলিতে প্রয়োগ করা হয়। এটি মোটেই সহজ: আপনি বিধিগুলি সংজ্ঞায়িত করেন, আপনার ব্যবহারকারীর ভূমিকা রয়েছে। আপনি সহজেই পরীক্ষা করে দেখুন যে ব্যবহারকারীর বিধিগুলিতে এর ভূমিকাটি অনুসন্ধান করার অনুমতি রয়েছে।

নির্দিষ্ট মডেলটিতে ব্যবহারকারীর অ্যাক্সেসকে মডেলে সংজ্ঞায়িত করা উচিত। (অভিনেতা বেস ব্যবহারকারী শ্রেণি। ধরুন এটি গ্রাহক, বিক্রেতা বা অতিথি হতে পারে))

interface ICheckAccess
{
    public function checkAccess(Actor $actor, $role);
}

class SomeModel implements ICheckAccess
{
    public function checkAccess(Actor $actor, $role)
    {
        // Your permissions logic can be as sophisticated as you want.
    }
}

সেই যুক্তিটি মডেলটিতে রাখলে কিছু লাভ হয়। অ্যাক্সেস চেক পদ্ধতি উত্তরাধিকার সূত্রে প্রাপ্ত হতে পারে, আপনার কোনও অতিরিক্ত ক্লাস তৈরি করার দরকার নেই, আপনি সাধারণ ওওপি সুবিধা ব্যবহার করতে পারেন।

এর পরে, অ্যাক্সেস চেকিংকে সহজ করার জন্য, আমরা কিছু অনুমান গ্রহণ করি যা সরলতা এবং ভাল স্টাইলের জন্য ইতিমধ্যে প্রায়শই প্রয়োগ করা হয়:

  • সাধারণত নিয়ন্ত্রকরা কিছু মডেল শ্রেণীর সাথে সম্পর্কিত;
  • অ্যাক্সেসের জন্য পরীক্ষা করা কর্মগুলি একক মডেল আইডিটিকে প্যারামিটার হিসাবে গ্রহণ করে;
  • বেস নিয়ামক শ্রেণীর পদ্ধতি থেকে এই প্যারামিটারটি সর্বদা অভিন্নভাবে অ্যাক্সেস করা যায়;
  • ক্রিয়াটি মডেলটির সাথে সম্পর্কিত আইডি ক্রিয়াটি নিয়ন্ত্রকের মধ্যে স্থাপন করা হয়।

এই অনুমানের সাথে, মডেল আইডি ব্যবহার করে এমন ক্রিয়াগুলি নির্দিষ্ট মডেলের উদাহরণের সাথে যুক্ত হতে পারে। প্রকৃতপক্ষে, বেশিরভাগ ক্রিয়াগুলি সহজেই পরিবর্তিত হতে পারে এবং উপরে বর্ণিত অনুমানগুলির সাথে ফিট হতে পারে।

তারপরে, কিছু বেস বিমূর্ত নিয়ন্ত্রক শ্রেণীর সংজ্ঞা দেওয়া উচিত এবং উত্তরাধিকার সূত্রে প্রাপ্ত হওয়া উচিত।

abstract class ModelController
{
    // Retrieve model from database using id from action parameter.
    public abstract function loadModel($id);

    // Returns rules for user role to pass to SomeModel::checkAccess()
    // Something like array('view' => 'viewer', 'delete' => 'owner', 'update' => 'owner')
    public abstract function modelRules();

    public abstract fucntion getIdParameter();

    public function filterModelAccess()
    {
        $id = $this->getIdParameter();
        if(!$this->checkModelAccess($id))
            throw new HttpException(403);
    }

    public function checkModelAccess($id)
    {
        $model = $this->loadModel($id);
        $actor = My::app()->getActor();
        $rules = $this->modelRules();
        $role = $rules[My::app()->getActionName()];
        return $model->chechAccess($actor, $role);
    }
}

আপনি যখন নিজের মেনুগুলি তৈরি করেন এবং কোনও লিঙ্ক প্রদর্শন করবেন কিনা তা স্থির করে আপনি সোমারকন্ট্রোলার :: চেকমোডেলএ্যাক্সেস ($ আইডি) পদ্ধতিতে কল করতে পারেন।


আমি পিএইচপি জন্য দুঃখিত।
জর্জ সোভেটোভ

1

মডেল এবং ভিউ উভয় ক্ষেত্রে

ভিউতে - কারণ ইউআই-তে ইউআই-উপাদানগুলি দেখা উচিত নয় যা বর্তমান ব্যবহারকারীর মধ্যে সীমাবদ্ধ are

(যেমন, বলুন, "মুছুন" বোতামটি উপযুক্ত অনুমতিযুক্ত লোকদের দেখানো উচিত)

মডেলটিতে - কারণ আপনার অ্যাপ্লিকেশনটিতে সম্ভবত কোনও ধরণের এপিআই রয়েছে, তাই না? এপিআই'র পাশাপাশি অনুমতিগুলিও পরীক্ষা করতে হবে এবং সম্ভবত মডেলটিকে পুনরায় ব্যবহার করতে হবে।

(যেমন, বলুন, আপনার কাছে ইউআইতে "মুছুন" বোতাম এবং একই সাথে "HTTP: / সার্ভার / এপিআই / ডিলিটএন্ট্রি / 123" এপিআই পদ্ধতি রয়েছে


আপনি কেন নিয়ামকের উপরে মডেলটি বেছে নিলেন?
Flimm

নিশ্চিত নয় কেন ভিউ, মডেল এবং নিয়ামক নয় কেন, বেশিরভাগ সময় এটি করা হয়ে থাকে।
ভিপি

@ ভিপি কন্ট্রোলারের কাছে ইউআই উপাদানগুলি দেখানোর / আড়াল করার ক্ষমতা নেই (
ভিউতে একটি বুল

আমি জানি না, সর্বত্র নিয়ন্ত্রক স্তরে সাধারণত কাজ করা হয়, এজন্য আমি কৌতূহলী ছিলাম।
ভিপি

0

এমভিসি একটি উপস্থাপনা প্যাটার্ন। যেমন মতামত এবং নিয়ন্ত্রকের কেবল উপস্থাপনা সম্পর্কিত দায়িত্ব থাকা উচিত। বিশেষজ্ঞ মোড, পরীক্ষামূলক ইউআই বৈশিষ্ট্য বা বিভিন্ন ডিজাইনের মতো কিছু উপস্থাপনা উপস্থাপনার ক্ষেত্রে প্রযোজ্য। সেগুলি এমভিসি-নিয়ামক দ্বারা পরিচালিত হতে পারে।

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

  • উপস্থাপনা স্তরটি সম্পাদনা বৈশিষ্ট্যগুলি গোপন করতে হবে
  • যদি কোনও সম্পাদনা বৈশিষ্ট্যটিকে যাইহোক বলা হয় তবে এটি সনাক্ত করা উচিত / (ব্যবসায়ের স্তরের নির্দিষ্ট অংশগুলি প্রয়োগ করে, এর ডোমেন নির্দিষ্ট অংশ নয় - ট্রেনএডিটর, ট্রেন নয়) এবং সম্ভবত ব্যতিক্রম ঘটায়
  • ডেটা অ্যাক্সেস লেয়ারটি লেখার জন্যও পরীক্ষা করতে পারে তবে আরও জটিল ধরণের অনুমতিগুলির জন্য দ্রুত ব্যবসায়-স্তর সম্পর্কে খুব বেশি জ্ঞানের প্রয়োজন একটি ভাল ধারণা।

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

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.