স্তরযুক্ত আর্কিটেকচারে অনুমোদন কোথায় ফিট?


24

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

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

এটি কি যুক্তিসঙ্গত পন্থা? এর কি অসুবিধা আছে?

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

সুতরাং আমি জিজ্ঞাসা করছি যে কেউ এটি করেছে এবং তারা কীভাবে এটি একটি পরিষ্কার উপায়ে অর্জন করেছে বা আমি পড়তে পারি এমন কোনও ভাল সংস্থান আছে কিনা। আমি জাভা fwiw ব্যবহার করছি কিন্তু এটি একটি ভাষা অজ্ঞাত প্রশ্ন।

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

আমি স্প্রিং সুরক্ষা ডকগুলি পড়ছি যা এটি ক্রস কাটানোর উদ্বেগ হওয়ার জন্য কিছু ভাল যুক্তি তৈরি করে, তবে আমি উদ্বিগ্ন যে এটি কেবল "বসন্তের উপায়" এবং আরও বৃহত্তর দৃষ্টিভঙ্গি পছন্দ করবে। এটি আপনার প্রয়োগকে একটি নির্দিষ্ট কাঠামোর সাথেও যুক্ত করে ties


1
অনুমোদন সমস্যাগুলির জন্য স্থিতি 403 ভুল। 401.
gnasher729

@ gnasher729 আমি মনে করি এটি পিছনের দিকে। 401 উপায়ে প্রমাণীকরণ ব্যর্থ হয়েছে বা দেওয়া হয় না, 403 মানে আপনি অ্যাক্সেস করার অধিকার নেই: stackoverflow.com/questions/3297048/...
JimmyJames

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

1
@ বেরিনলরিটস দুঃখিত, আপনি কি বলছেন যে এটি প্রমাণীকরণ বা অনুমোদনের কোনও সমস্যা কিনা তা বোঝার পক্ষে ধারণাটি আরও কঠিন করা হবে? আরএফসিটি বেশ পরিষ্কার বলে মনে হচ্ছে তবে আপনি যদি খুব বেশি তথ্য প্রকাশ করতে না চান তবে 403 এর পরিবর্তে 404 ব্যবহার করতে পারবেন। 403 এর পরিবর্তে 401 ব্যবহারের জন্য আপনি কি যুক্তিটি সরবরাহ করতে পারেন এমন কোনও রেফারেন্স রয়েছে?
জিমি জেমস

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

উত্তর:


9

এটির জন্য ব্যবহারকারীর দ্বারা অনুমোদিত বিকল্পগুলিই প্রকাশ করা ভাল অভ্যাস।

এটি অনুমোদনকে ক্রস কাটা উদ্বেগ হতে বাধ্য করে। প্রদর্শনের জন্য অপশন এবং মেনুগুলি তৈরি করতে পারার আগে কোনও ব্যবহারকারীকে কী করতে দেওয়া উচিত তা "ভিউ" টি জানতে হবে।

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

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

এখানে বিবেচনা করার জন্য প্রযুক্তিগত অনুমোদন রয়েছে - লগগুলি কাকে দেখার অনুমতি দেওয়া হয়েছে, কে ডাটাবেস ব্যাকআপ / পুনরুদ্ধার করতে পারে ইত্যাদি

সুতরাং শেষ পর্যন্ত আপনার প্রতিটি উপাদানগুলির একটি নির্দিষ্ট সুরক্ষা এবং / বা অনুমোদনের প্রয়োজনীয়তা থাকতে পারে, বাস্তবে এটিকে একটি পৃথক "অনুমোদন স্তর" এ গুটিয়ে রাখা প্রায় অসম্ভব।


7

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

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

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


7

অনুমোদনের চেকগুলি যতটা কম যায় তত বেশি চাপ দেওয়া পছন্দ করি! (তবে আর নেই!)

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

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

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


@ শো যদি আমি আপনার উদ্বেগটি বুঝতে পারি - তবে এটি এমন বিষয়। ব্যবসায়ের নিয়ম অনুসারে যদি কোনও "প্রশাসক" এর অনুমতি থাকে তবে একটি তৈরি করতে Widget, একই নিয়ম সর্বত্র প্রযোজ্য। (সুতরাং কাউকে এটিকে অবহেলা না করার ঝুঁকি তৈরি করুন!) যদি নিয়মটি সর্বত্র প্রয়োগ না হয় তবে এটি আসলে Widgetsএবং কেবলমাত্র কোনও নিয়ম নয় Widgets। যতক্ষণ না তারা (স্বতন্ত্র নিয়মগুলি) যেতে পারে ততক্ষণ নিয়ম চাপুন; কিন্তু, না যতটা "বিধি" যেতে পারেন ... আমি আমি পার্থক্য ভাল জানায় করছি না মনে। তবে, সেখানে পার্থক্য থাকার কথা।
এসভিডজেন

আমার অভিজ্ঞতায়, অনুমোদনের নিয়মগুলি প্রায়শই ব্যবসায়ের নিয়মের অংশ। যেমন, "তারা যতদূর যেতে পারে নিচে" প্রায়শই আমার ডোমেন স্তর। তবে, আমি সন্দেহ করি যে যেখানে আপনার নিয়ম "পতন" হওয়া উচিত তা আপনার ডোমেনের একটি পরিণতি, নিয়মের প্রকৃতি এবং ব্যবসা তাদের সম্পর্কে কীভাবে কথা বলে।
এসভিডজেন 20
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.