আপনি এই আমাকে বুঝতে সাহায্য করতে পারেন? "সাধারণ বিশ্রামের ভুল: সেশনগুলি অপ্রাসঙ্গিক"


159

দাবি অস্বীকার: আমি বিশ্রামের চিন্তায় নতুন, এবং আমি আমার মনটিকে এটি ঘিরে রাখার চেষ্টা করছি।

সুতরাং, আমি এই পৃষ্ঠাটি পড়ছি, সাধারণ বিশ্রামের ভুলগুলি এবং আমি পেয়েছি যে সেশনগুলির বিভাগটি অপ্রাসঙ্গিক বলে আমি পুরোপুরি বিস্মিত। এই পৃষ্ঠাটি বলে:

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

ঠিক আছে, আমি পেয়েছি যে প্রতিটি বার্তায় এইচটিটিপি প্রমাণীকরণ স্বয়ংক্রিয়ভাবে সম্পন্ন হয় - তবে কীভাবে? প্রতিটি অনুরোধের সাথে ব্যবহারকারীর নাম / পাসওয়ার্ড প্রেরণ করা হয়? এটি কি কেবল আক্রমণ পৃষ্ঠের ক্ষেত্রফল বাড়ায় না? আমার মনে হচ্ছে আমি ধাঁধাটির কিছু অংশ মিস করছি।

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


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

উত্তর:


79

বিশ্রামের জন্য, এইচটিটিপি-র রাষ্ট্রহীন প্রকৃতির সাথে সম্পূর্ণ সাদৃশ্যপূর্ণ হওয়ার জন্য প্রতিটি এইচটিটিপি অনুরোধের প্রাপককে এটির জন্য যথেষ্ট তথ্য বহন করতে হবে।

ঠিক আছে, আমি পেয়েছি যে প্রতিটি বার্তায় এইচটিটিপি প্রমাণীকরণ স্বয়ংক্রিয়ভাবে সম্পন্ন হয় - তবে কীভাবে?

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

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

এটি বিশ্রামের মতো হবে না কারণ এটি রাষ্ট্র বহন করে তবে এটি বেশ সাধারণ কারণ এটি ব্যবহারকারীদের জন্য একটি সুবিধাজনক; ব্যবহারকারীর প্রত্যেকবার লগইন করতে হয় না।

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


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

33

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


3
+1 আপনি দয়া করে বিশদটি বর্ণনা করতে পারেন: কোনও আক্রমণকারী যে এটিকে বাধা দেয় (যেহেতু এটি বর্তমান সময়ের উপর নির্ভরশীল) এর সীমিত ব্যবহার ? আপনি কি এমন কোনও কুকি সম্পর্কে কথা বলছেন না যাতে এনক্রিপ্ট করা ব্যবহারকারীর নাম এবং পাসওয়ার্ড রয়েছে? যেমন কি তাই করে? (আইএমএইচও)
রয়ী নমির

2
@ রইনিমির: আমি কোনও কুকির কথা বলছি না। এস 3 দ্বারা ব্যবহৃত স্বাক্ষর HTTP অনুরোধ করার জন্য একটি প্যারামিটার, কিন্তু না একটি কুকি, এটা প্রত্যেক অনুরোধের জন্য পুনঃগণনা করা হয়।
গ্রেগ হিউগিল

সুতরাং যদি আমার কোনও ব্যবহারকারীর সম্পর্কে কিছু তথ্য সংরক্ষণ করার দরকার হয় তবে আমি এটি কোথায় সংরক্ষণ করব? ডিবিতে? আমি প্রতিটি অনুরোধ ডিবি করতে চাই না .... এবং তবুও আমি বিশ্রাম ব্যবহার করতে চাই .... আপনি দয়া করে সাহায্য করতে পারেন?
রই নমির

@ রায়নিমির: কীভাবে কিছু লক্ষ্য অর্জন করতে হয় সে সম্পর্কে আপনার যদি নির্দিষ্ট প্রশ্ন থাকে তবে দয়া করে একটি নতুন প্রশ্ন জিজ্ঞাসা করুন । আমি মন্তব্যগুলিতে এখানে অতিরিক্ত প্রশ্নের উত্তর দিতে পারি না।
গ্রেগ হিউগিল

10

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

আপনার ক্ষেত্রে আমি বলি হ্যাঁ এটি বিশ্রাম, তবে আপনার আরএসটি এপিআইতে নেটিভ পিএইচপি সেশনগুলি ব্যবহার এড়িয়ে চলার চেষ্টা করুন এবং আপনার নিজস্ব হ্যাশড টোকেনগুলি তৈরি করা শুরু করুন যা সময়ের নির্ধারিত পেরিওডে শেষ হয়!


1
ধন্যবাদ. কেন একজন লোক নেটিভ পিএইচপি সেশন এড়ানো উচিত এবং তার পরিবর্তে নিজস্ব হ্যাশ টোকেন ব্যবহার করা উচিত?
ম্যাথু

আমি বলি এমন কোনও উজ্জ্বল কারণ নয়, কেবল আরও সুরক্ষা এবং আরও নিয়ন্ত্রণের জন্য।
ইভিলথিংকার

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

8

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


11
@ unforgiven3 যতক্ষণ না ফেরত টোকেন কেবল ব্যবহারকারীর অনুমোদনের জন্য ব্যবহার করা হয় এবং সার্ভারে ব্যবহারকারীকে অন্য সার্ভারে সঞ্চিত অন্য রাজ্যে সংযুক্ত করতে ব্যবহার করা হয় না, তারপরে আমি আরইএসএসটির কোনও বাধা লঙ্ঘন করতে দেখছি না see
ড্যারেল মিলার

4
@ unforgiven3 সার্ভার দ্বারা ফিরিয়ে দেওয়া টোকেনটি প্রকৃতপক্ষে, ব্যবহারকারী যারা তারা বলে তারা প্রমাণ করে। সুতরাং, ব্যবহারকারীর নাম এবং পাসওয়ার্ড সহ প্রতিটি অনুরোধের পরিবর্তে, প্রতিটি অনুরোধে টোকেন অন্তর্ভুক্ত রয়েছে যা এমনভাবে নির্মিত হয়েছে যাতে সার্ভার তার সত্যতার বিষয়ে আস্থা রাখতে পারে।
ড্যারেল মিলার 16

1
@ unforgiven3, ড্যারেল ঠিক আছে। টোকেন প্রতিধ্বনিত টোকেনটি মেয়াদ শেষ না হওয়া অবধি মৌলিক, ডাইজেস্ট প্রমাণীকরণের মতো প্রতিটি HTTP অনুরোধে ক্লায়েন্ট দ্বারা প্রেরণ করতে হবে। যখন এটি ঘটে তখন ক্লায়েন্টটি লগইনটি পুনরাবৃত্তি করতে পারে option আমি চাইলে উত্তরটি বিস্তারিতভাবে বলতে পারি। সম্পাদনা করুন: (এবং পুরানো প্রশ্নের উত্তরগুলি রাখার জন্য ধন্যবাদ!)
মোগসি

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

6
@ unforgiven3, এটি সাহায্য করতে পারে: টোকেন হ'ল একটি স্বাক্ষরিত তথ্য piece সুতরাং এটি স্বয়ংসম্পূর্ণ। সার্ভারটি পূর্ব-সঞ্চিত স্থিতি পরীক্ষা না করে টোকেনকে বৈধতা দিতে পারে। সুতরাং এটি কেবলমাত্র একটি রাষ্ট্র যা ক্লায়েন্টের উপর সংরক্ষণ করা হয় এবং পিছনে পিছনে স্থানান্তরিত হয়।
ইরাভানচি

5

ঠিক আছে, আমি পেয়েছি যে প্রতিটি বার্তায় এইচটিটিপি প্রমাণীকরণ স্বয়ংক্রিয়ভাবে সম্পন্ন হয় - তবে কীভাবে?

"অনুমোদন:" HTTP শিরোনাম ক্লায়েন্ট দ্বারা প্রেরণ। হয় বেসিক (সরল পাঠ্য) বা হজম করুন

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

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

উদাহরণ: পৃষ্ঠাগুলি সহ অনুসন্ধান করুন। আপনার ফর্মের URL আছে

http://server/search/urlencoded-search-terms/page_num

বুকমার্কযোগ্য ইউআরএলগুলির সাথে এর প্রচুর মিল রয়েছে


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

আপনি যদি এই ক্রিয়াটি কার্যকর করার জন্য অনুমোদিত হন তবে প্রমাণীকরণটি প্রতিষ্ঠিত করে এবং RESTful অ্যাপ্লিকেশনটিতে এর ফলাফলকে প্রভাবিত করবে না।
ভের্টেক

4
আপনি যদি এই ক্রিয়াটি চালানোর জন্য অনুমোদিত হন তবে একটি সেশন টোকেনও প্রতিষ্ঠিত করে। আপনি কী বোঝাতে চেয়েছেন যে এটি এর ফলাফলকে প্রভাবিত করবে না? যদি কলার অনুমোদিত না হয় তবে তারা একটি অনুমোদিত নয় ত্রুটি পান। একটি সেশন টোকেন সহ একই জিনিস। আমি কি সত্যিই পার্থক্য দেখছি না?
রব

3
না, সেশন টোকেন হ'ল একটি হ্যান্ডেল যা রাষ্ট্রটিতে সংরক্ষিত থাকে। এটি কেবল বিশ্রামের নয়। অনুমোদিত নয় হিসাবে, আমি ফলাফল হিসাবে এটি দেখতে পাচ্ছি না। আমি বরং এটি ব্যতিক্রম বিবেচনা করব (চেষ্টা / ধরার ক্ষেত্রে)।
ভের্টেক

যথেষ্ট ন্যায্য, বৈকল্পিক - এটি উপলব্ধি করে। ফলোআপের জন্য ধন্যবাদ!
রব

3

আমি মনে করি আপনার পরামর্শটি ঠিক আছে, আপনি যদি ক্লায়েন্ট সেশন লাইফ টাইম নিয়ন্ত্রণ করতে চান। আমি মনে করি যে RESTful আর্কিটেকচার আপনাকে রাষ্ট্রবিহীন অ্যাপ্লিকেশনগুলি বিকাশ করতে উত্সাহিত করে। যেমন @ 2pence লিখেছেন "প্রতিটি এইচটিটিপি অনুরোধের প্রাপক এটির জন্য এইচটিটিপি-র রাষ্ট্রহীন প্রকৃতির সাথে সম্পূর্ণ সাদৃশ্যপূর্ণ হতে প্রক্রিয়া করার জন্য পর্যাপ্ত তথ্য বহন করে

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

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