সেশনগুলি কি সত্যিই বিশ্রামের লঙ্ঘন করে?

Question

কোনও RESTful API এ সেশনগুলি কী সত্যিই RESTfulness লঙ্ঘন করছে? আমি অনেক মতামতকে উভয় দিকেই যেতে দেখেছি, তবে আমি নিশ্চিত নই যে সেশনগুলি অস্থির । আমার দৃষ্টিকোণ থেকে:

• বিশ্রামের জন্য প্রমাণীকরণ নিষিদ্ধ নয় (অন্যথায় RESTful পরিষেবাদিতে খুব কম ব্যবহার হবে না)
• অনুরোধটিতে একটি শংসাপত্রের টোকন প্রেরণ করে সাধারণত শিরোনাম হয় authe
• এই প্রমাণীকরণ টোকেনটি কোনওরকম প্রাপ্ত হওয়া দরকার এবং তা প্রত্যাহারযোগ্য হতে পারে, সেক্ষেত্রে এটি পুনর্নবীকরণ করা দরকার
• প্রমাণীকরণ টোকেন সার্ভার দ্বারা বৈধ করা প্রয়োজন (অন্যথায় এটি প্রমাণীকরণ হবে না)

তাহলে সেশনগুলি কীভাবে এটি লঙ্ঘন করবে?

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

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

আমার অনুমানগুলি কি ভুল? কী সেশন কুকিজ অস্থির করে তোলে ?

Comments

আমি সেই সঠিক সমস্যাটি এখানে covered েকে

— হার্টং

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

— হার্টং

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

— প্রতারণা করুন

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

— উইল Hartung

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

— উইল হার্টুং

Answer 1

প্রথমে কিছু শর্ত সংজ্ঞায়িত করা যাক:

• RESTful:

  এই বিভাগে বর্ণিত REST সীমাবদ্ধতার সাথে সামঞ্জস্য রেখে অ্যাপ্লিকেশনগুলিকে "RESTful" হিসাবে চিহ্নিত করতে পারে [[15] যদি কোনও পরিষেবা প্রয়োজনীয় যে কোনও বাধা লঙ্ঘন করে তবে এটিকে বিশ্রামের জন্য বিবেচনা করা যাবে না।

  উইকিপিডিয়া অনুসারে ।

• রাষ্ট্রহীন বাধা:

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

  অনুযায়ী ফিন্ডিং গবেষণা প্রবন্ধে ।

সুতরাং সার্ভার সাইড সেশনগুলি REST এর রাজ্যহীন সীমাবদ্ধতা লঙ্ঘন করে, এবং তাই RESTfulness হয়।

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

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

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

আমার দৃষ্টিকোণ থেকে:

• বিশ্রামের জন্য প্রমাণীকরণ নিষিদ্ধ নয় (অন্যথায় RESTful পরিষেবাদিতে খুব কম ব্যবহার হবে না)
• অনুরোধটিতে একটি শংসাপত্রের টোকন প্রেরণ করে সাধারণত শিরোনাম হয় authe
• এই প্রমাণীকরণ টোকেনটি কোনওরকম প্রাপ্ত হওয়া দরকার এবং তা প্রত্যাহারযোগ্য হতে পারে, সেক্ষেত্রে এটি পুনর্নবীকরণ করা দরকার
• প্রমাণীকরণ টোকেন সার্ভার দ্বারা বৈধ করা প্রয়োজন (অন্যথায় এটি প্রমাণীকরণ হবে না)

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

• চিত্র 1. - বিশ্বস্ত ক্লায়েন্টদের স্টেটলেস প্রমাণীকরণ

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

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

• চিত্র 2. - তৃতীয় পক্ষের ক্লায়েন্টদের স্টেটলেস প্রমাণীকরণ

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

Comments

হ্যাঁ, আপনি পুরোপুরি ঠিক বলেছেন। যেহেতু আমি এই প্রশ্নটি পোস্ট করেছি আমি তা দেখতে পুরোপুরি এসেছি। প্রযুক্তিগত বিবরণগুলিতে সেশন কুকিজগুলি বিশেষ কিছু নয় তবে গাছগুলির জন্য বনটি অনুপস্থিত। দুর্দান্ত চার্টের কারণে আপনার উত্তর গৃহীত হয়েছে। ;)

— ছদ্মবেশ

ঠিক আছে, আমি পুনরায় চিন্তা করেছি, আরআরএসটি পরিষেবার প্রতিক্রিয়া অনুমোদনের উপর নির্ভর করা উচিত নয়, তাই আমি মনে করি প্রথম 2 টি সমাধান 100% ঠিক আছে, এবং অন্যরা ঠিক আছে যদি পরিষেবাটি কেবল অনুরোধের অনুমতি দেয় কিনা তা সিদ্ধান্ত নিতে তথ্য ব্যবহার করে বা না. সুতরাং আমি মনে করি ব্যবহারকারীর অনুমতিগুলি বর্তমান সংস্থানটির উপস্থাপনার উপর প্রভাব ফেলবে।

— inf3rno

আমি উপস্থাপনার অনুমতি নির্ভরতা সম্পর্কে একটি প্রশ্ন তৈরি করব। যথাযথ সমাধান পেলেই আমি এই উত্তরটি প্রসারিত করব।

— inf3rno

@ inf3rno, এটি সত্য যে একটি সম্পূর্ণরূপে RESTful পরিষেবাদি traditionতিহ্যগতভাবে প্রয়োগ করা হয় এমনভাবে প্রমাণীকরণের জন্য সেশন কুকিজের উপর নির্ভর করতে পারে না। তবে, কুকিটিতে সার্ভারের পরে যে সমস্ত রাজ্যের তথ্য প্রয়োজন হবে তা প্রমাণীকরণের জন্য আপনি কুকিজ ব্যবহার করতে পারেন। আপনি কুকিকে কোনও পাবলিক / প্রাইভেট কী জুটির সাথে সাইন ইন করে তা হস্তক্ষেপ থেকে সুরক্ষিত করতে পারেন। নীচে আমার মন্তব্য দেখুন।

— jcoffland

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

— lvoelk

Answer 2

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

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

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

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

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

Comments

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

— ড্যারেল মিলার

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

— জেরেড হার্ডিং

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

— ছদ্মবেশ

আমি এত প্রচার প্রচার শুনেছি যে সেশনগুলি শান্তিময় নয়। আপনি যদি কোনও ওয়েব অ্যাপ তৈরির চেষ্টা করছেন তবে এইচটিটিপি মৌলিক প্রমাণীকরণ হ'ল পিছনের দিকে real

— বেন থারলি

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

— jcoffland

Answer 3

কুকিজ প্রমাণীকরণের জন্য নয়। চাকা পুনরুদ্ধার কেন? এইচটিটিপিতে প্রমাণীকরণ প্রক্রিয়াটি সু-নকশিত। আমরা যদি কুকি ব্যবহার করি তবে আমরা এইচটিটিপি কেবলমাত্র পরিবহন প্রোটোকল হিসাবে ব্যবহার করতে পারি, সুতরাং আমাদের নিজস্ব সিগন্যালিং সিস্টেম তৈরি করা দরকার , উদাহরণস্বরূপ, ব্যবহারকারীদের বলতে যে তারা ভুল প্রমাণীকরণ সরবরাহ করেছে (HTTP 401 ব্যবহার করা সম্ভবত ভুল হবে না তাই) Www-Authenticateকোনও ক্লায়েন্টকে সরবরাহ করুন, যেমন HTTP চশমা প্রয়োজন :))। এটিও লক্ষ করা উচিত যে Set-Cookieএটি কেবল ক্লায়েন্টের জন্য একটি সুপারিশ। এর সামগ্রীগুলি সংরক্ষণ বা নাও হতে পারে (উদাহরণস্বরূপ, কুকিজ অক্ষম থাকলে) ifAuthorization প্রতিটি অনুরোধে শিরোনাম স্বয়ংক্রিয়ভাবে প্রেরণ করা হয়।

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

• তুমি চেষ্টা করো GET /a কুকি ছাড়া
• আপনি কোনওভাবে অনুমোদনের অনুরোধ পাবেন
• আপনি যান এবং একরকম অনুমোদন POST /auth
• তুমি পাও Set-Cookie
• আপনি কুকি GET /a দিয়ে চেষ্টা করুন । তবে কি GET /aএই ক্ষেত্রে আদর্শবান আচরণ করে ?

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

Comments

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

— ছদ্মবেশ

ওয়েব ব্রাউজারগুলি কেবল সমর্থন করে Authorization: Basicবা এটি সমর্থন করে তা সত্যই বিবেচ্য নয় Digest। আপনি যদি ব্রাউজারের প্রসঙ্গে মৌলিক বা হজম লেখক (এবং আপনার উচিত) এর চেয়ে আরও উন্নত কিছু করতে চান তবে আপনার Authorizationশিরোনাম ব্যতীত অন্য কিছু প্রয়োজন ।

— অলিভার চার্লসওয়ার্থ

অবশ্যই - যদি আপনি খাঁটি জেএস করছেন তবে জিনিসগুলি মূলত ঠিক আছে (উদাহরণস্বরূপ, ওয়েবসকেটগুলি বাদে)। তবে আমার বক্তব্যটি হ'ল এপিআই-ভিত্তিক লেখক ব্রাউজারের দৃশ্যে কেবল বিবেচ্য নয়।

— অলিভার চার্লসওয়ার্থ

GET /aএকটি কুকি ছাড়া এবং একটি কুকি সহ স্পষ্টভাবে দুটি পৃথক অনুরোধ, এবং তাদের পক্ষে আলাদা আচরণ করা গ্রহণযোগ্য acceptable

— ট্রিগ

@ টিআরআইজি যোগ করার জন্য, এই যুক্তি অনুসরণ করে, GET /aপ্রমাণীকরণ শিরোনাম ছাড়াও GET /aপ্রমাণীকরণের শিরোনাম ছাড়াই সমান, এটি আরএসটি-র জন্য সমানভাবে অকেজো হয়ে ওঠে । আপনি যদি একজন এইচটিএসপি শিরোনামের সাথে অন্যের থেকে আলাদা আচরণ করতে চলেছেন তবে আপনি এটি খুব কম সময়েই সম্বোধন করতে যাচ্ছেন।

— জেস্পার

Answer 4

প্রকৃতপক্ষে, বিশ্বব্যাপী রিসোর্স আইডেন্টিফায়ার দ্বারা নির্দেশিত হিসাবে কেবলমাত্র রিসোর্টফুলেন্স কেবলমাত্র রিসোর্সেসে প্রযোজ্য। তাই এমনকি REST এর ক্ষেত্রে শিরোনাম, কুকিজ ইত্যাদির মতো জিনিস সম্পর্কে কথা বলাও যথাযথ নয়। এইচটিটিপি-র মাধ্যমে নিয়মিতভাবে সম্পন্ন হওয়া সত্ত্বেও REST যে কোনও প্রোটোকল নিয়ে কাজ করতে পারে।

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

তেমনি, কোনও পোষ্ট বা পুটের ক্ষেত্রে, আপনি কোনও প্রদত্ত ইউআরআই / পে-লোড প্রেরণ করতে পারেন, এবং আপনি যত বার বার বার্তা প্রেরণ করেন না কেন, এটি সর্বদা একই ডেটা আপডেট করে, যাতে পরবর্তী জিইটিগুলি একটি ধারাবাহিক ফলাফল ফিরিয়ে দেয়?

আরআরইএসটি অ্যাপ্লিকেশন ডেটা সম্পর্কিত, সেই ডেটা স্থানান্তরিত করার জন্য প্রয়োজনীয় নিম্ন-স্তরের তথ্য সম্পর্কে নয়।

নিম্নলিখিত ব্লগ পোস্টে, রয় ফিল্ডিং পুরো REST ধারণার একটি দুর্দান্ত সংক্ষিপ্তসার দিয়েছে:

http://groups.yahoo.com/neo/groups/rest-discuss/conversations/topics/5841

"একটি বিশ্রাম ব্যবস্থা একটি স্থিতিশীল রাষ্ট্র থেকে পরের দিকে অগ্রসর হয় এবং এ জাতীয় প্রতিটি অবিচল রাষ্ট্র একটি সম্ভাব্য প্রারম্ভিক অবস্থা এবং সম্ভাব্য শেষ-রাষ্ট্র উভয়ই। অর্থাত্, একটি বিশ্রাম ব্যবস্থা এমন একটি অজানা সংখ্যক উপাদান যা একটি সাধারণ সেট মান্য করে is এমন নিয়মগুলি থাকে যেগুলি সর্বদা হয় REST এ থাকে বা একটি RESTful রাষ্ট্র থেকে অন্য RESTful অবস্থায় স্থানান্তরিত হয় প্রতিটি রাজ্য এতে উপস্থিত প্রতিনিধিত্ব (গুলি) এবং এটি সরবরাহ করে এমন ট্রানজিশনের সেট দ্বারা সম্পূর্ণ বোঝা যায় যে ট্রান্সমিশনগুলি ইউনিফর্মের মধ্যে সীমাবদ্ধ থাকে with ক্রিয়াগুলির সেটটি বোধগম্য হতে পারে The সিস্টেমটি একটি জটিল রাষ্ট্রের ডায়াগ্রাম হতে পারে তবে প্রতিটি ব্যবহারকারী এজেন্ট কেবল একবারে একটি রাষ্ট্র (বর্তমান অবিচলিত রাষ্ট্র) দেখতে সক্ষম হয় এবং এইভাবে প্রতিটি রাজ্য সহজ এবং স্বতন্ত্রভাবে বিশ্লেষণ করা যায় A ব্যবহারকারী, OTOH, যে কোনও সময় তাদের নিজস্ব ট্রানজিশন তৈরি করতে সক্ষম (যেমন, একটি URL লিখুন, একটি বুকমার্ক নির্বাচন করুন,একটি সম্পাদক খুলুন ইত্যাদি) "।

---

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

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

সুতরাং, ক্লায়েন্ট ব্যবহারকারী কী করছে তার উপর নজর রাখে এবং কেবলমাত্র সার্ভারে যৌক্তিকভাবে সম্পূর্ণ রাষ্ট্রীয় ট্রান্সজিশন প্রেরণ করে।

Comments

আমি দেখছি না কীভাবে এটি উত্থাপিত প্রশ্নের উপর কোনও আলোকপাত করে।

— jcoffland

Answer 5

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

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

সুতরাং সেই সমস্যাটি প্রাথমিক অ্যাক্সেস প্রমাণীকরণ ব্যবহার করে সমাধান করা যাবে না।

এই সমস্যাটি সমাধান করার জন্য, সেশন রক্ষণাবেক্ষণ করা জরুরি এবং কিছু উত্তর অনুসারে, আরএসটি-র সাথে দ্বন্দ্ব রয়েছে।

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

আমার জন্য এইচটিটিপি-র উপর অধিবেশন বজায় রাখার অনেকগুলি উপায় নেই। একটি সেশনআইড সহ একটি কুকি বা সেশনআইড সহ একটি শিরোনাম ব্যবহার করতে পারে।

কারও যদি অন্য ধারণা থাকে তবে তা শুনে আমি আনন্দিত হব।

Answer 6

আমি মনে করি টোকেন অবশ্যই অবশ্যই এর ভিতরে এনকোড হওয়া সমস্ত প্রয়োজনীয় তথ্য অন্তর্ভুক্ত করবে, যা টোকেনকে বৈধ করে এবং তথ্যটি ডিকোড করে https://www.oauth.com/oauth2-servers/access-tokens/self-encoded-access-tokens/

Answer 7

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

Comments

কুকিটি সার্ভারে একটি সেশনের জন্য একটি সেশন কী সঞ্চয় করতে ব্যবহার করা উচিত নয় যা প্রমাণীকরণ টোকেন ধারণ করে। তবে যদি কুকি নিজেই প্রমাণীকরণের টোকেন ধরে রাখে তবে এটি একটি সম্ভাব্য সমাধান। (অবশ্যই কুকিটি httponly এবং সুরক্ষিত হওয়া উচিত)

— রবারকুলস