এর অর্থ কী, “কোনও ব্যবহারকারীর সিদ্ধান্ত নেওয়া উচিত নয় যে এটি প্রশাসক কিনা is সুবিধাগুলি বা সুরক্ষা ব্যবস্থা করা উচিত ”"

Question

প্রশ্নটিতে ব্যবহৃত উদাহরণটি কোনও ফাংশনের ন্যূনতম ডেটা ব্যবহারকারীর প্রশাসক কিনা তা নির্ধারণের সর্বোত্তম উপায়ে স্পর্শ করে। একটি সাধারণ উত্তর ছিল:

user.isAdmin()

এটি এমন একটি মন্তব্যকে উত্সাহিত করেছিল যা বেশ কয়েকবার পুনরাবৃত্তি হয়েছিল এবং বহুবার ভোট দিয়েছিল:

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

আমি উত্তর দিলাম,

ব্যবহারকারী কোনও কিছুর সিদ্ধান্ত নিচ্ছেন না। ব্যবহারকারী অবজেক্ট / টেবিল প্রতিটি ব্যবহারকারীর সম্পর্কে ডেটা সঞ্চয় করে। প্রকৃত ব্যবহারকারীরা নিজের সম্পর্কে সমস্ত কিছু পরিবর্তন করতে পারে না।

তবে এটি ফলপ্রসূ হয়নি। স্পষ্টতই দৃষ্টিভঙ্গির একটি অন্তর্নিহিত পার্থক্য যা যোগাযোগকে জটিল করে তুলছে। কেউ আমাকে ব্যাখ্যা করতে পারে কেন ইউজারআইআর অ্যাডমিন () খারাপ, এবং এটি "ডান" হয়ে গেছে বলে মনে হচ্ছে তার একটি সংক্ষিপ্ত চিত্র আঁকুন?

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

Comments

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

— সেফালপড

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

— ফিলিপ

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

— PSr

@ ফিলিপ আমার মনে হয় না ... উভয় UserisAdmin()

— সাইটই

সম্পাদনা করতে খুব দেরী; আমি "উভয় পক্ষ" বলতে

— চাইছিলাম

Answer 1

কী হিসাবে ব্যবহারকারী এবং মান হিসাবে অনুমতিগুলি সম্পর্কে ভাবুন।

বিভিন্ন প্রসঙ্গে প্রতিটি ব্যবহারকারীর জন্য পৃথক অনুমতি থাকতে পারে। অনুমতিগুলি যেমন প্রাসঙ্গিক-প্রাসঙ্গিক তাই আপনাকে প্রতিটি প্রসঙ্গে ব্যবহারকারীকে পরিবর্তন করতে হবে। সুতরাং এটি যুক্তিযুক্ত অন্য কোথাও রাখা ভাল (যেমন প্রসঙ্গ শ্রেণি), এবং যেখানে প্রয়োজন সেখানে অনুমতিগুলি সন্ধান করুন।

একটি পার্শ্ব-প্রতিক্রিয়া হ'ল এটি আপনার সিস্টেমটিকে আরও সুরক্ষিত করে তুলতে পারে, কারণ আপনি যে জায়গাগুলি প্রাসঙ্গিক নয় সেগুলির জন্য অ্যাডমিন পতাকা সাফ করতে ভুলবেন না।

Answer 2

এই মন্তব্যটি খারাপভাবে বলা হয়েছিল।

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

Comments

আউচ (এটি আমার মন্তব্য ছিল), তবে আপনি এটি আমার চেয়ে অনেক ভাল রেখেছিলেন।

— মার্জন ভেনেমা

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

— গ্লেনপিটারসন

@ গ্লেনপিটারসন: অগত্যা নয় যে কেবল ক্লাস <> টেবিল এবং সাধারণত টেবিলের চেয়ে অনেক বেশি ক্লাস রয়েছে। ডেটা-ওরিয়েন্টড হওয়ার কারণে ক্লাসগুলিতে সাবলিস্টগুলি সংজ্ঞায়িত করতে পারে যদিও অনেক সময় এই তালিকাগুলি অন্য "খাত্তর" (অর্ডার) বা ব্যবহারকারীর (বা অর্ডার) পাস করে এমন কিছু শ্রেণীর জন্য সংশোধন করা উচিত যার জন্য পুনরুদ্ধার করতে হবে ... এটি ক্রিয়াপদ এবং বিশেষ্যগুলির চেয়ে দায়িত্বের বিষয়।

— মার্জন ভেনেমা

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

— উইলবার্ট

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

— গ্লেনপিটারসন

Answer 3

আমি মূল মন্তব্যটি যেভাবে বলা হয়েছিল সেভাবে শব্দটি বেছে নিতে চাইতাম না, তবে এটি কোনও সম্ভাব্য বৈধ সমস্যা চিহ্নিত করে ।

বিশেষতঃ, উদ্বেগ যে ওয়ারেন্ট বিচ্ছিন্নতা তা প্রমাণীকরণ বনাম অনুমোদন ।

প্রমাণীকরণ বলতে লগ ইন এবং একটি পরিচয় পাওয়ার প্রক্রিয়া বোঝায়। এটি কীভাবে সিস্টেমগুলি জানে যে আপনি কে , এবং ব্যক্তিগতকরণ, বস্তুর মালিকানা ইত্যাদির মতো জিনিসগুলির জন্য ব্যবহৃত হয় knows

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

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

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

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

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

User.IsAdminক্ষেত্রের সাথে কোনও সমস্যা নেই ... যদি ক্ষেত্রও না থাকে User.Name। এটি ইঙ্গিত দেয় যে "ব্যবহারকারী" ধারণাটি সঠিকভাবে সংজ্ঞায়িত হয়নি এবং এটি দুঃখের বিষয়, সুরক্ষার কথা বলতে গেলে এই বিকাশকারীদের মধ্যে খুব সাধারণ একটি ভুল যা কানের পিছনে কিছুটা ভিজে যায়। সাধারণত, পরিচয় এবং নীতি দ্বারা ভাগ করা উচিত একমাত্র জিনিসটি ইউজার আইডি, যা কাকতালীয়ভাবে নয়, ঠিক কীভাবে এটি উইন্ডোজ এবং * নিক্স সুরক্ষা মডেল উভয় ক্ষেত্রে প্রয়োগ করা হয়।

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

ইয়াজিএনআই এবং সমস্ত কিছুর কারণে আপনি যখন প্রথম নতুন অ্যাপ্লিকেশনটি ডিজাইন করেন তখন সরল সুরক্ষা মডেলটি সর্বদা একটি ভাল ধারণা বলে মনে হয় তবে এটি সর্বদা আপনাকে পরে কামড়ানোর জন্য ফিরে আসে কারণ অবাক করা অবাক, নতুন বৈশিষ্ট্য যুক্ত হয়!

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

Comments

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

— মার্জান ভেনেমা

এটি আমি যে প্রকল্পে কাজ করছি তার মতোই ধাক্কা দেওয়ার মতো শোনায় এবং আপনার উত্তর আমাকে অন্য দৃষ্টিকোণ দিয়েছে। তোমাকে অনেক ধন্যবাদ!

— ব্র্যান্ডন

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

— কাপ্তজনকোল্ড

@ ক্যাপ্টজনকোল্ড: আমি এই ফোরামে বিভিন্ন প্রশ্নোত্তর থ্রেডগুলিতে এই অনুভূতিটি পড়তে থাকি। যদি কোনও পদ্ধতি বিদ্যমান থাকে তবে তা সরাসরি অপারেশনগুলি সম্পাদন করে বা এটি তাদের প্রতিনিধি দেয় কিনা তা বিবেচ্য নয় , এটি এখনও একটি দায়িত্ব হিসাবে গণ্য হয় কারণ অন্যান্য শ্রেণিগুলি এর উপর নির্ভর করতে পারে । আপনার User.IsAdminসম্ভবত একটি ওয়ান-লাইনার হতে পারে যা কল ছাড়া কিছুই করে না PermissionManager.IsAdmin(this.Id), তবে এটি যদি অন্য 30 টি ক্লাস দ্বারা রেফারেন্স হয়ে যায় তবে আপনি এটিকে পরিবর্তন বা সরাতে পারবেন না। এজন্য এসআরপি রয়েছে।

— অ্যারোনআউট

এবং, @ ক্যাপ্টজনকোল্ড, যতদূর সম্পর্কের মডেলগুলি যায়, আমি নিশ্চিত নই যে আপনি কী পাচ্ছেন; এটা এমনকি এর চেয়েও খারাপ একটি আছে IsAdmin ক্ষেত্র । সিস্টেমটি আরবিএসি বা আরও জটিল কিছুতে বিবর্তিত হওয়ার পরে এবং ধীরে ধীরে "সত্যিকারের" অনুমতিগুলির সাথে সিঙ্কের বাইরে চলে যায় এবং লোকেরা ভুলে যায় যে এটিকে আর ব্যবহার করার কথা নয়, তারা এই জাতীয় ক্ষেত্রের চারপাশে প্রায় স্থির থাকে people এবং ... ঠিক আছে, না বলুন। এমনকি যদি আপনার মনে হয় যে আপনার কেবল দুটি প্রশাসনিক ভূমিকা রয়েছে, "অ্যাডমিন" এবং "নন-অ্যাডমিন", এটি বুলিয়ান / বিট ক্ষেত্র হিসাবে সংরক্ষণ করবেন না, সঠিকভাবে স্বাভাবিক করুন এবং অনুমতি টেবিলটি রাখুন।

— অ্যারোনআউট

Answer 4

ভাল, খুব কমপক্ষে এটি একক দায়িত্বের নীতি লঙ্ঘন করে । এই ধরণের ডিজাইনের পরিবর্তনগুলি (একাধিক প্রশাসকের স্তর, আরও আরও বিভিন্ন ভূমিকা?) হওয়া উচিত?

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

Comments

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

— মার্জন ভেনেমা

class Userসনাক্তকরণ, প্রমাণীকরণ, অনুমোদনের সুরক্ষা ট্রিপলেটের মূল উপাদান । এগুলি নকশার স্তরে নিবিড়ভাবে আবদ্ধ হয়, সুতরাং কোডটির পক্ষে এই আন্তঃনির্ভরতা প্রতিফলিত করা অযৌক্তিক নয়।

— এমসাল্টারস

প্রশ্নটি হল, ট্রিপলেটটি পরিচালনা করার জন্য ব্যবহারকারী শ্রেণিতে সমস্ত যুক্তি থাকা উচিত!

— জাভিয়র

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

— মার্জন ভেনেমা

Should there be changes- ভাল, আমরা জানি না যে পরিবর্তনগুলি হতে চলেছে। ইয়াগনি এবং সমস্ত। যখন এটি প্রয়োজনীয় হয়ে যায় তখন কি এই পরিবর্তনগুলি হয়?

— ইজকাটা

Answer 5

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

পরিবর্তে, আপনি বিভিন্ন ধরণের অনুমতিগুলির একটি এনাম এবং একটি PermissionsManagerশ্রেণি ব্যবহার করতে পারেন । PermissionsManager.userHasPermission(User, Permission)বুলিয়ান মানটি ফেরত দেওয়ার মতো পদ্ধতি সম্ভবত আপনার থাকতে পারে । অনুশীলনে, এটি দেখতে (জাভাতে) মতো লাগবে:

if (!PermissionsManager.userHasPermission(user, Permissions.EDITOR)) {
  Site.renderSecurityRejectionPage();
}

এটি মূলত রেল পদ্ধতি before_filterপদ্ধতির সমতুল্য , যা বাস্তব বিশ্বে এই ধরণের অনুমতি চেকের একটি উদাহরণ সরবরাহ করে।

Comments

user.hasPermission(Permissions.EDITOR)এটি ও এর পরিবর্তে আরও ভার্বোজ এবং পদ্ধতিগত ছাড়া এটি কীভাবে আলাদা ?

— সেফালপড

@ আরিয়ান: কারণ user.hasPermissionsব্যবহারকারী শ্রেণিতে অনেক বেশি দায়বদ্ধতা রয়েছে। এটি ব্যবহারকারীর অনুমতি সম্পর্কে জেনে রাখা প্রয়োজন, যখন কোনও ব্যবহারকারীর (শ্রেণি) এমন জ্ঞান ছাড়াই উপস্থিত থাকতে পারা উচিত। আপনি নিজেই কীভাবে মুদ্রণ করবেন বা প্রদর্শন করবেন (কোনও ফর্ম তৈরি করবেন) সে ​​সম্পর্কে জেনে কোনও ব্যবহারকারী শ্রেণি চান না, আপনি এটি প্রিন্টার রেন্ডারার / বিল্ডার বা ডিসপ্লে রেন্ডারার / বিল্ডার শ্রেণিতে রেখে দেন।

— মার্জন ভেনেমা

user.hasPermission(P)সঠিক এপিআই, তবে এটি কেবল ইন্টারফেস। আসল সিদ্ধান্ত অবশ্যই অবশ্যই একটি সুরক্ষা উপ-সিস্টেমে নেওয়া উচিত। পরীক্ষায় সিরিয়ানর মন্তব্যে ঠিকানা দেওয়ার জন্য, পরীক্ষার সময় আপনি সেই সাবসিস্টেমটি সরিয়ে নিতে পারেন। তবে, সোজাসাপ্টের সুবিধা user.hasPermission(P)হ'ল আপনি সমস্ত কোডকে কলুষিত করেন না ঠিক তাই আপনি পরীক্ষা করতে পারেন class User।

— এমসাল্টারস

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

— সেফালপড

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

— মার্জন ভেনেমা

Answer 6

অবজেক্ট.আইএসএক্স () অবজেক্ট এবং এক্স এর মধ্যে একটি সুস্পষ্ট সম্পর্কের প্রতিনিধিত্ব করতে ব্যবহৃত হয়, এটি বুলিয়ান ফলাফল হিসাবে প্রকাশ করা যেতে পারে, উদাহরণস্বরূপ:

Water.isBoiling ()

Circuit.isOpen ()

ইউজার.আইএসএডমিন () সিস্টেমের প্রতিটি প্রসঙ্গে 'অ্যাডমিনিস্ট্রেটর' এর একক অর্থ অনুমান করে যে একজন ব্যবহারকারী, সিস্টেমের প্রতিটি অংশে, প্রশাসক।

যদিও এটি যথেষ্ট সহজ শোনায়, সত্যিকারের বিশ্ব প্রোগ্রামটি কখনই এই মডেলটির সাথে খাপ খায় না, সেখানে অবশ্যই কোনও ব্যবহারকারীকে [এক্স] রিসোর্স পরিচালনা করতে হবে তবে [ওয়াই] নয়, বা আরও পৃথক ধরণের প্রশাসকের জন্য (একটি [প্রকল্প ] প্রশাসক বনাম একটি [সিস্টেম] প্রশাসক)।

এই পরিস্থিতিতে সাধারণত প্রয়োজনীয়তার তদন্ত প্রয়োজন। কদাচিৎ, যদি কখনও হয়, কোনও ক্লায়েন্ট কি এমন সম্পর্ক চাইবে যা ইউজার.আইসএডমিন () আসলে প্রতিনিধিত্ব করে, তাই আমি কোনও ব্যাখ্যা ছাড়াই এ জাতীয় কোনও সমাধান বাস্তবায়নে দ্বিধা করব।

Answer 7

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

Comments

Save tomorrow for tomorrow। হ্যাঁ। যখন আপনি বুঝতে পেরেছেন যে আপনি যে শক্তভাবে দ্বিধায়িত কোডটি সবে লিখেছেন তা আপনাকে কবুতর করেছে এবং আপনাকে এটি পুনরায় লিখতে হবে কারণ আপনি এটি ডিক্লোল করতে অতিরিক্ত 20 মিনিট সময় নেননি ...

— মিররফেটে

@ মিরর্ডেড ফেট: User.isAdminব্যবহারকারী শ্রেণিকে সেই নির্দিষ্ট ব্যবস্থায় মিলিত না করে একটি স্বেচ্ছাসেবী অনুমতি ব্যবস্থার সাথে কোনও পদ্ধতি যুক্ত হওয়া সম্পূর্ণভাবে সম্ভব ।

— কেভিন cline

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

— মার্জন ভেনেমা

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

— কেভিন cline

@ কেভিঙ্কলাইন অতি-জটিল এপিআইগুলি (সংজ্ঞায়িতভাবে) একটি খারাপ জিনিস হ'ল, আমি পরামর্শ দিচ্ছিলাম না যে অতিরিক্ত ও জটিল এপিআই লিখতে হবে। আমি বলছিলাম যে Save tomorrow for tomorrowএটি একটি ভয়াবহ নকশা পদ্ধতির কারণ এটি সমস্যা তৈরি করে যা ক্ষুদ্রতর হবে যদি সিস্টেমটি আরও খারাপভাবে প্রয়োগ করা হয়। প্রকৃতপক্ষে, সেই মানসিকতা হ'ল অতি-জটিল এপিআইগুলির ফলাফল যা লেয়ারের উপর স্তর হিসাবে প্রাথমিক দুর্বল নকশাকে প্যাচ করার জন্য যুক্ত করা হয়। আমার ধারণা আমার অবস্থান measure twice, cut once।

— মিররফেটে

Answer 8

আসলেই সমস্যা নয় ...

আমি কোন সমস্যা দেখতে পাচ্ছি না User.isAdmin()। আমি অবশ্যই এটিকে এমন কিছুতে পছন্দ করি PermissionManager.userHasPermission(user, permissions.ADMIN), যা এসআরপির পবিত্র নামে কোডটি কম পরিষ্কার করে দেয় এবং মানটির কোনও যোগ করে না।

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

... তবে কেন আপনি সত্যিই জানতে চান?

এটি বলেছিল, এটি আমার কাছে মনে হচ্ছে আপনার পক্ষে খুব কমই জানা দরকার যে কোনও ব্যবহারকারী কোনও অন্য কোনও প্রশ্নের উত্তর দিতে সক্ষম হওয়া ব্যতীত কোনও ব্যবহারকারীকে কোনও নির্দিষ্ট ক্রিয়া সম্পাদন করার অনুমতি দেয় কি না, যেমন কোনও উইজেট আপডেট করার মতো বলে get যদি এটি হয় তবে আমি উইজেটে একটি পদ্ধতি পছন্দ করতে পছন্দ করব isUpdatableBy(User user):

boolean isUpdatableBy(User user) {
    return user.isAdmin();
}

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

[সম্পাদনা]

না থাকার User.isAdmin()এবং ব্যবহারে সমস্যাPermissionManager.userHasPermission(...)

আমি ভেবেছি যে আমি কেন ব্যবহারকারী প্রশাসক (বা প্রশাসকের ভূমিকা আছে) তা জানতে চাইলে আমি যদি অনুমতি আইনে কোনও পদ্ধতি কল করার ক্ষেত্রে কেন ব্যবহারকারীর অবজেক্টে কোনও পদ্ধতিকে কল করতে পছন্দ করি তা ব্যাখ্যা করার জন্য আমি আমার উত্তরে যুক্ত করব।

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

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

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

Comments

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

— অ্যারোনআউট

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

— গ্লেনপিটারসন

@ গ্লেনপিটারসন ওয়েল, আমি সেই প্রশ্নের অংশটি সম্বোধন করার চেষ্টা করেছি যা "সঠিক" বলে মনে হচ্ছে "এছাড়াও: আমার সাথে একমত হওয়া সম্পর্কে আপনার একেবারে দোষী হওয়া উচিত নয় :)

— কাপ্তাজনকোল্ড

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

— কাপ্তজনকোল্ড

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

— কাপ্তজনকোল্ড

Answer 9

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

ফ্রেমওয়ার্ক ক্লাসগুলির এতগুলি সিলযুক্ত কেন?

বিশেষত এরিক বিষয়টি তুলে ধরেছে:

4) সুরক্ষিত। পলিমারফিজমের পুরো বক্তব্যটি হ'ল আপনি এমন বস্তুর চারপাশে যেতে পারেন যা প্রাণীর মতো দেখতে তবে বাস্তবে জিরাফস। এখানে সম্ভাব্য সুরক্ষার সমস্যা রয়েছে।

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

এটি স্পর্শকাতর মতো মনে হতে পারে তবে আমি মনে করি এটি অন্যান্য পোষ্টাররা সলড একক-দায়িত্ব নীতি সম্পর্কে উত্থাপিত বিন্দুটির সাথে কবুতরগুলি । কোনও User.IsAdminপদ্ধতি বা সম্পত্তি প্রয়োগ না করার কারণ হিসাবে নিম্নলিখিত দূষিত শ্রেণিকে বিবেচনা করুন ।

public class MyUser : User
{

    public new boolean IsAdmin()
    {
        // You know it!
        return true;
    }

    // Anything else we can break today?

}

মঞ্জুর, এটি কিছুটা প্রসারিত: এখনও কেউ IsAmdminভার্চুয়াল পদ্ধতি তৈরি করার পরামর্শ দেয়নি , তবে যদি আপনার ব্যবহারকারী / ভূমিকা আর্কিটেকচারটি উদ্ভট জটিল হয়ে যায় তবে এটি ঘটতে পারে। (বা সম্ভবত না! বিবেচনা করুন public class Admin : User { ... }: এ জাতীয় শ্রেণীর উপরে এটির ঠিক উপরে কোড থাকতে পারে)) কোনও দূষিত বাইনারি জায়গায় পাওয়া কোনও সাধারণ আক্রমণ ভেক্টর নয় এবং একটি অস্পষ্ট ব্যবহারকারী লাইব্রেরির চেয়ে বিশৃঙ্খলার অনেক বেশি সম্ভাবনা রয়েছে - তারপরে আবার এটি প্রিভিলেজ এসকেলেশন বাগ হতে পারে যা আসল শেননিগানের দরজা খুলে দেয়। অবশেষে, যদি কোনও দূষিত বাইনারি বা অবজেক্ট উদাহরণটি রান সময়টিতে পৌঁছায়, তবে "প্রিভিলেজ বা সুরক্ষা ব্যবস্থা" অনুরূপভাবে প্রতিস্থাপন করা হয়েছে তা কল্পনা করার মতো বিষয়গুলি খুব বেশি নয়।

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

ওহ, এবং কেবল রেকর্ডটির জন্য সুনির্দিষ্টভাবে বলতে গেলে, আমি এই প্রশ্নের মধ্যে পোস্টুলিটের সাথে একমত: "কোনও ব্যবহারকারী এটি প্রশাসক কিনা তা সিদ্ধান্ত নেওয়া উচিত নয়। সুবিধাগুলি বা সুরক্ষা ব্যবস্থা থাকা উচিত ”" User.IsAdminযদি আপনি সিস্টেমে কোডটি চালাচ্ছেন তবে আপনি কোডের 100% নিয়ন্ত্রণে না থেকে থাকেন তবে একটি পদ্ধতি একটি খারাপ ধারণা instead আপনার পরিবর্তে এটি করা উচিত Permissions.IsAdmin(User user)।

Comments

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

— অ্যারোনআউট

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

— প্যাট্রিক এম

আমি নিশ্চিত নই আপনি কেন এমনটি বলছেন। প্রচুর সুরক্ষা এবং অনুমতি ফ্রেমওয়ার্কগুলি অত্যন্ত এক্সটেনসিবল। কোর .NET নিরাপত্তা (IPrincipal, IIdentity, ClaimSet, ইত্যাদি) এর সাথে সম্পর্কিত ধরনের অধিকাংশই শুধুমাত্র নেই না সিল কিন্তু যাতে আপনি চলা করতে পারেন যাই হোক না কেন আপনি চান আসলে ইন্টারফেসগুলি বা বিমূর্ত শ্রেণীর মধ্যে আছে। এরিক যে বিষয়ে কথা বলছেন তা হ'ল আপনি System.Stringউত্তরাধিকার সূত্রে প্রাপ্ত হওয়ার মতো কিছু চান না কারণ সমস্ত ধরণের সমালোচনামূলক কাঠামো কোড এটি কীভাবে কাজ করে সে সম্পর্কে খুব নির্দিষ্ট ধারণা তৈরি করে। অনুশীলনে, বেশিরভাগ "ব্যবহারকারীর কোড" (সুরক্ষা সহ) পরীক্ষার দ্বিগুণ হওয়ার অনুমতি দেয় inher

— অ্যারোনআউট

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

— অ্যারোনআউট

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

— প্যাট্রিক এম

Answer 10

এখানে সমস্যাটি হ'ল:

if (user.isAdmin()) {
   doPriviledgedOp();
} else {
   // maybe we can anyway!
   doPriviledgedOp();
}

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

Comments

একটি অনিবদ্ধ শ্রেণি কী?

— ব্র্যান্ডন

এই ধরণের কোডটি লিখিত হওয়া থেকে রোধ করতে আপনার পক্ষে করার মতো কিছুই নেই। আপনি নিজের অ্যাপটি কীভাবে ডিজাইন করেন তা বিবেচনা না করেই কোথাও কোথাও এর মতো সুস্পষ্ট চেক হতে চলেছে এবং কেউ এটিকে সুরক্ষিত করে লিখতে পারে। এমনকি যদি আপনার অনুমতিগুলি সিস্টেম কোনও ভূমিকা বা অনুমতি বৈশিষ্ট্যের সাথে কোনও পদ্ধতি সাজানোর মতো সমৃদ্ধ হয় - তবে কেউ ভুলভাবে "জনসাধারণ" বা "প্রত্যেকে" অনুমতি এনে ফেলতে পারে। সুতরাং আমি সত্যিই দেখতে পাচ্ছি না এটি কীভাবে User.IsAdmin বিশেষত একটি সমস্যার মতো একটি পদ্ধতি করে ।

— অ্যারোনআউট