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