ডিডিডি সিকিউআরএস - প্রতি-ক্যোয়ারী এবং প্রতি-আদেশের অনুমোদন


15

সারসংক্ষেপ

সিকিউআরএস / ডিডিডি-তে অনুমোদনের জন্য প্রতি-আদেশ / কোয়েরি প্রয়োগ করা উচিত কি না?

আমি প্রথমবারের মতো কম বেশি কঠোরভাবে ডিডিডি সিকিউআরএস প্যাটার্ন ব্যবহার করে একটি অনলাইন অ্যাপ্লিকেশন বিকাশ করছি। আমি কিছু সমস্যায় জড়িয়ে পড়েছি, যা সত্যই আমি মাথা ঘুরিয়ে নিতে পারি না।

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

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

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

এটি ডিডিডি টিউটোরিয়ালে সমস্ত জায়গার চারদিকে বলা হয়েছে যে কমান্ডগুলি সর্বব্যাপী ভাষার অংশ। তারা অর্থপূর্ণ। এগুলি দৃ actions় পদক্ষেপ যা "আসল জিনিস" উপস্থাপন করে।

যেহেতু সমস্ত কমান্ড এবং কোয়েরিগুলি প্রকৃত ক্রিয়া যা ব্যবহারকারীরা "বাস্তব জীবনে" চালিত করে, তাই অনুমোদনের বাস্তবায়নগুলি কি এই সমস্ত "কমান্ড" এবং "অনুসন্ধানগুলি" এর সাথে মিলিত হওয়া উচিত? উদাহরণস্বরূপ কোনও ব্যবহারকারীর TLedger.addTransaction () চালানোর অনুমোদন থাকবে তবে উদাহরণস্বরূপ TLedger.removeTransaction () নয়। অথবা, কোনও ব্যবহারকারীকে "getSummaries ()" কোয়েরি কার্যকর করার অনুমতি দেওয়া হবে তবে "getTransferences ()" নয়।

অ্যাক্সেসের অধিকার নির্ধারণের জন্য ত্রি-মাত্রিক ম্যাপিংটি ব্যবহারকারী-খাত্ত-কমান্ড বা ব্যবহারকারী-খাত্তর-কোয়েরির আকারে উপস্থিত থাকবে।

অথবা, একটি decoupled উপায়ে, "অনুমতি" নামক একটি ব্যবহারকারীর জন্য নিবন্ধিত হবে। অনুমতিগুলি যা নির্দিষ্ট কমান্ডের জন্য ম্যাপ করা হবে। উদাহরণস্বরূপ, অনুমতি "ম্যানেজট্রান্সট্র্যাকশনস" ব্যবহারকারীর "অ্যাডট্রান্সঅ্যাকশন ()", "সরান ট্রান্সজিশন ()" ইত্যাদি চালানোর অনুমতি দেয় etc.

  1. অনুমতি ম্যাপিং ব্যবহারকারী -> খাতা -> কমান্ড / কোয়েরি

  2. অনুমতি ম্যাপিং ব্যবহারকারী -> খাতা -> অনুমতি -> কমান্ড / কোয়েরি

এটা প্রশ্নের প্রথম অংশ। বা সংক্ষেপে, সিকিউআরএস / ডিডিডি-তে অনুমোদনের জন্য প্রতি-আদেশ বা প্রতি-কোয়েরি প্রয়োগ করা উচিত? অথবা, কমান্ডগুলি থেকে অনুমোদনকে ডিউপল করা উচিত?

দ্বিতীয়ত, অনুমতিগুলির ভিত্তিতে অনুমোদনের বিষয়ে। একজন ব্যবহারকারীকে তার লেজারগুলিতে বা যে লেজারগুলি পরিচালনা করার অনুমতি দেওয়া হয়েছে সেগুলির অনুমতিগুলি পরিচালনা করতে সক্ষম হওয়া উচিত।

  1. অনুমোদনের ব্যবস্থাপনার আদেশগুলি লেজারে ঘটে

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

উদাহরণ স্বরূপ :

class TLedger{ 
    function addTransactionCmdHandler(cmd){
        if (!this.permissions.exist(user, 'addTransaction')
            throw new Error('Not Authorized');
    }
}
  1. ব্যবহারকারীর মধ্যে অনুমোদনের কমান্ড

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

class TAddTransactionCmdHandler(cmd) {
    this.userRepository.find(cmd.userId)
    .then(function(user){
        if (!user.can(cmd)){
            throw new Error('Not authorized');
        }
        return this.ledgerRepository.find(cmd.ledgerId);
    })
    .then(function(ledger){
        ledger.addTransaction(cmd);
    })

}
  1. পরিষেবা সহ অন্য একটি ডোমেন

আরেকটি সম্ভাবনা হ'ল সম্পূর্ণভাবে অন্য অনুমোদনের ডোমেনটি মডেল করা। এই ডোমেনটি অ্যাক্সেসের অধিকার, অনুমোদন ইত্যাদিতে আগ্রহী হবে The অ্যাকাউন্টিং সাবডোমেন তারপরে এই অনুমোদনের ডোমেনটির আকারে অ্যাক্সেস করার জন্য কোনও পরিষেবা ব্যবহার করবে AuthorizationService.isAuthorized(user, command)

class TAddTransactionCmdHandler(cmd) {
    authService.isAuthorized(cmd)
    .then(function(authorized){
        if (!authorized) throw new Error('Not authorized');
        return this.ledgerRepository.find(cmd.ledgerId)
    })
    .then(function(){
        ledger.addTransaction(cmd);
    })

}

সর্বাধিক "ডিডিডি / সিকিউআরএস" উপায় কী হবে?


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

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

উত্তর:


5

প্রথম প্রশ্নের জন্য আমি একই জাতীয় কিছু নিয়ে লড়াই করছি। আরও অনেক বেশি আমি তিন-পর্যায়ের অনুমোদনের স্কিমের দিকে ঝুঁকছি:

1) "এই ব্যবহারকারীর এই আদেশটি কার্যকর করার অনুমতি আছে কি ?" একটি এমভিসি অ্যাপে সম্ভবত এটি নিয়ামক স্তরে পরিচালিত হতে পারে তবে আমি একটি জেনেরিক প্রাক-হ্যান্ডলারের জন্য বেছে নিচ্ছি যা বর্তমান ব্যবহারকারীর এবং এক্সিকিউটিভ কমান্ডের উপর ভিত্তি করে অনুমতি স্টোরটি জিজ্ঞাসা করবে।

2) "এই ব্যবহারকারী" এর * অ্যাপ্লিকেশন পরিষেবার ভিতরে অনুমোদনের কি কখনও এই সত্তাটি অ্যাক্সেস করার অনুমতি আছে? "আমার ক্ষেত্রে এটি সম্ভবত रिपোটিটরিতে ফিল্টারগুলির দ্বারা একটি অন্তর্নিহিত চেক হয়ে যাবে - আমার ডোমেইনে এটি হ'ল অর্গানাইজেশন আইডি এর আরও কিছুটা গ্রানুলারিটি সহ মূলত একটি টেন্যান্টআইডি।

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

আমি এই ধারণার বিষয়ে অন্যের প্রতিক্রিয়া শুনতে খুব পছন্দ করব - আপনি চাইলে এটি ছেঁড়া করুন (আপনি যদি কিছু করেন তবে কিছু বিকল্প সরবরাহ করুন :))


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

0

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

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