কেন আমাদের পদ্ধতি স্তরের সুরক্ষা দরকার?

Question

বাস্তব বিশ্বে, কেন আমাদের পদ্ধতি স্তরের সুরক্ষা প্রয়োগ করা দরকার?

আমাদের হয় একটি ওয়েব অ্যাপ্লিকেশন বা একটি ডেস্কটপ অ্যাপ্লিকেশন রয়েছে, যেখানে ব্যবহারকারী ব্যবহারকারী ইন্টারফেসটি অ্যাক্সেস করে (এবং তাই সরাসরি পদ্ধতিটিতে অ্যাক্সেস করতে পারে না)।

তাহলে অ্যাক্সেসের পদ্ধতিগুলি এখানে সরাসরি ছবিতে আসে?

সম্পাদনা করুন: আমি এই প্রশ্নটি জিজ্ঞাসা করি কারণ আমি বসন্তের সুরক্ষা নিয়ে পরীক্ষা-নিরীক্ষা করছি এবং ব্যবহারকারীর অ্যাক্সেসের জন্য আমি কর্তৃপক্ষকে দেখছি।

কিছুটা এইরকম :

 @ROLE_ADMIN
public void update() {
      //update
}

Comments

সুরক্ষা সম্পর্কিত সমস্যাগুলি না ভেবে কোড পুনরায় ব্যবহার করতে হবে 2. সহজে কোনও ওয়েব সার্ভিসের সাথে একীকরণ করা ৩. যখন আপনি উপরের স্তরগুলির সুরক্ষা পদ্ধতিতে বিশ্বাস করেন না তখন সুরক্ষা সম্পর্কে নিশ্চিত হন

— এরকান এরল

Answer 1

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

Comments

আপনি এই প্রশ্নের উত্তর দেননি: কেন পদ্ধতি স্তর?

— কোডিজম

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

— জোসেফ লাস্ট

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

— কোডিজমে

কারণ এটি সর্বনিম্ন উপলব্ধ স্তর এবং এওপি বা অ্যাসপেক্টজে ব্যবহার করে অনায়াসে প্রয়োগ করা হয় applied আমি বিশ্বাস করি না এটি অন্যান্য সমস্ত সুরক্ষা বাস্তবায়নের ক্ষেত্রে প্রযোজ্য।

— জোসেফ

Answer 2

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

ভূমিকা ভিত্তিক অ্যাক্সেসের জন্য আরও সূক্ষ্ম দানাদার নিয়ন্ত্রণের ক্ষেত্রে এটি বিবেচনা করুন:

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

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

Answer 3

পদ্ধতি স্তরের সুরক্ষা দুটি প্রধান কারণে কার্যকর:

• সুরক্ষার অন্য স্তর হিসাবে (অন্যান্য স্তর ছাড়াও)

• পদ্ধতি স্তরে অনুমতি প্রাপ্তি আরও সুবিধাজনক বা যৌক্তিক ক্ষেত্রে এমন একটি ক্ষেত্রে বিবেচনা করা হয় যেখানে বিভিন্ন ব্যবহারকারী একই "সরাসরি" ক্রিয়া করতে পারে (যাতে ক্লায়েন্টের সুরক্ষা প্রাসঙ্গিক নয়)। তবে কিছু ক্ষেত্রে তাদের ক্রিয়াটি এমন একটি আচরণকে ট্রিগার করতে পারে যা আপনি সীমাবদ্ধ করতে চান - এই ক্ষেত্রে পদ্ধতি স্তরের সুরক্ষা একটি প্রাসঙ্গিক সমাধান হতে পারে।

Answer 4

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

সুরক্ষা কঠোর, সুরক্ষার একাধিক স্তর, সংঘর্ষের প্রচেষ্টা অবরুদ্ধ করার সম্ভাবনাগুলিকে উন্নত করবে। যেহেতু মেথড লেভেল সিকিউরিটি ক্লাসের মধ্যে সরাসরি কোডড থাকে, এওপি বৃদ্ধির পরে, আপনি যখন পদ্ধতিটি কল করেন, আপনি সর্বদা সুরক্ষা চেকটি আগে কল করবেন।

Answer 5

আমার ধারণা যে আপনি এখানে সরকারী, ব্যক্তিগত এবং সুরক্ষিত পদ্ধতি সম্পর্কে কথা বলছেন?

যদি তা হয় তবে সুরক্ষার প্রয়োজনে সেগুলি বিদ্যমান নেই। এটিকে আরও সহজ করার উদ্দেশ্যে যে সফ্টওয়্যারটি সঠিকভাবে সংশোধন করা হয়েছে তার গ্যারান্টি রয়েছে। (তারা এতে সফল হন কিনা সে বিতর্ক আমি অন্যের পক্ষে ছেড়ে দেব That এটি অবশ্য তারা কীসের দৃষ্টিভঙ্গি।)

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

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

Comments

আপনি এটি পেলেন না, তিনি পাবলিক, প্রাইভেট এবং সুরক্ষিত সম্পর্কে কথা বলছেন না, তবে

— কোনও