কাস্টম HTTP অনুমোদনের শিরোনাম

Question

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

অনুমান অনুসারে এর মতো কিছু বৈধ হবে এবং অনুমোদিত হবে: Authorization: FIRE-TOKEN 0PN5J17HBGZHT7JJ3X82:frJIUN8DYpKDtOLCwo//yllqDzg=

দ্বিতীয় স্ট্রিংয়ের প্রথম অংশটি (':' এর আগে) হল API কী, দ্বিতীয় অংশটি কোয়েরি স্ট্রিংয়ের একটি হ্যাশ।

Answer 1

আরএফসি 2617 এ সংজ্ঞায়িত ফর্ম্যাটটি হ'ল credentials = auth-scheme #auth-param। সুতরাং, ফুমানছুর সাথে একমত হয়ে, আমি মনে করি সংশোধিত অনুমোদন স্কিমটি দেখতে হবে

Authorization: FIRE-TOKEN apikey="0PN5J17HBGZHT7JJ3X82", hash="frJIUN8DYpKDtOLCwo//yllqDzg="

FIRE-TOKENস্কিমটি কোথায় এবং দুটি কী-মান জোড় হ'ল এথের পরামিতি। যদিও আমি বিশ্বাস করি উদ্ধৃতিগুলি alচ্ছিক (পি 7-এথ -19-এর অ্যাপেন্ডিক্স বি থেকে) ...

auth-param = token BWS "=" BWS ( token / quoted-string )

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

এই লেখক-পরম সিনট্যাক্সের কয়েকটি উদাহরণ এখানে দেখা যায় ...

http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-19#section-4.4

https://developers.google.com/youtube/2.0/developers_guide_protocol_clientlogin

https://developers.google.com/accounts/docs/AuthSub#WorkingAuthSub

Comments

অ্যামাজনের সাধারণ স্টোরেজ এপিআই আরেকটি উদাহরণ দেয়।

— বিশপ

Answer 2

এটি একটি পৃথক, কাস্টম শিরোনামে রাখুন।

প্রমিত এইচটিটিপি শিরোনামগুলি ওভারলোড করা সম্ভবত এটির চেয়ে বেশি বিভ্রান্তি সৃষ্টি করবে এবং এটি অবাক করে দেওয়ার নীতি লঙ্ঘন করবে । এটি আপনার এপিআই ক্লায়েন্ট প্রোগ্রামারদের যারা আন্তঃশিক্ষা সরঞ্জাম কিটগুলি কেবলমাত্র আদর্শ HTTP শিরোনামগুলির (যেমন Authorization) স্ট্যান্ডার্ড ফর্মের সাথে মোকাবিলা করতে পারে তাদের ব্যবহার করতে চায় তাদের আন্তঃব্যবস্থাপনা সমস্যা হতে পারে ।

Comments

এটি প্রদর্শিত হওয়ার চেয়ে সঠিকভাবে পাওয়া শক্ত হতে পারে। ফুমানচু যে লিঙ্কটি সরবরাহ করেছে (তার উত্তরে একটি মন্তব্যে) ব্যাখ্যা করেছে যে কাস্টম শিরোনাম প্রবর্তন কেন এখন ম্যানুয়ালি সঠিকভাবে ক্যাশে-নিয়ন্ত্রণকে সেট করার অতিরিক্ত অতিরিক্ত চাপ যুক্ত করে।

— জন-এরিক

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

— উইল মুর তৃতীয়

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

— লেস হ্যাজলউড

Authorizationকাস্টম শিরোনামের চেয়ে শিরোনামগুলিতে শংসাপত্র প্রেরণের একটি ভাল কারণ হ'ল প্রক্সি এবং লগাররা তথ্যটিকে সংবেদনশীল হিসাবে বিবেচনা করে।

— অ্যারন রাইট

Answer 3

না, এটি আরএফসি 2617 এর "শংসাপত্রগুলি" সংজ্ঞা অনুযায়ী বৈধ উত্পাদন নয় । আপনি একটি বৈধ লেখক-স্কিম দেন, তবে লেখক-পরম মানগুলি অবশ্যই ফর্মের token "=" ( token | quoted-string )(বিভাগ 1.2 দেখুন) হতে হবে এবং আপনার উদাহরণটি "=" সেভাবে ব্যবহার করে না।

Comments

এটি সঠিক নয়। উদাহরণস্বরূপ বিন্যাসের জন্য নথির 5 নং পৃষ্ঠাগুলি দেখুন: অনুমোদন: বেসিক QWxhZGRpbjpvcGVuIHNlc2FtZQ ==

— এনআরএফ

সেটা সত্য. কিন্তু tools.ietf.org/html/draft-ietf-httpbis-p7-auth-16#section-2.3.1 বলেছেন, "" b64token "স্বরলিপি বিদ্যমান প্রমাণীকরণ স্কীম সাথে সামঞ্জস্যের জন্য চালু করা হয় এবং শুধুমাত্র প্রতি একবার ব্যবহার করা যাবে চ্যালেঞ্জ / শংসাপত্রসমূহ। নতুন স্কিমগুলির পরিবর্তে "auth-param" বাক্য গঠন ব্যবহার করা উচিত, কারণ অন্যথায় ভবিষ্যতের এক্সটেনশনগুলি অসম্ভব হয়ে উঠবে। " কাস্টম শিরোনামগুলিতে লেখক সম্পাদনের বিষয়ে ক্যাশে আলোচনাও দেখুন।

— ফুমানছু

Answer 4

পুরানো প্রশ্ন আমি জানি, তবে কৌতূহলের জন্য:

বিশ্বাস করুন বা না করুন, এই সমস্যাটি 2 দশক আগে এইচটিটিপি বেসিক দিয়ে সমাধান করা হয়েছিল, যা মান 64-কে এনকোডেড ব্যবহারকারীর নাম: পাসওয়ার্ড হিসাবে পাস করে। ( Http://en.wikedia.org/wiki/Basic_access_authentication#Client_side দেখুন )

আপনি একই কাজ করতে পারেন, যাতে উপরের উদাহরণটি হয়ে উঠবে:

Authorization: FIRE-TOKEN MFBONUoxN0hCR1pIVDdKSjNYODI6ZnJKSVVOOERZcEtEdE9MQ3dvLy95bGxxRHpnPQ==

Comments

আমি এই উত্তরের বিরুদ্ধে পরামর্শ দেব, যেমন এখানে অন্য উত্তরের একটি মন্তব্য অনুসারে , এখানে ব্যবহৃত স্বরলিপি বিদ্যমান স্কিমগুলির সাথে সামঞ্জস্যের জন্য এবং নতুন এক্সটেনশনের জন্য প্রস্তাবিত নয়।

— হোমারমার