লগইন পৃষ্ঠায় পুনর্নির্দেশের সময় সঠিক HTTP স্থিতি কোডটি কী?


133

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

আমি জিজ্ঞাসা করছি কারণ ডাব্লু 3 সি দ্বারা নির্ধারিত 3xx প্রতিক্রিয়া কোডগুলির কোনওটিই প্রয়োজনীয়তার সাথে ফিট করে না বলে মনে হচ্ছে :

10.3.1 300 একাধিক পছন্দ

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

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

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

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

10.3.2 301 স্থায়ীভাবে সরানো হয়েছে

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

নতুন স্থায়ী ইউআরআই প্রতিক্রিয়া হিসাবে অবস্থান ক্ষেত্রের দ্বারা দেওয়া উচিত। অনুরোধের পদ্ধতিটি হেড না হলে প্রতিক্রিয়াটির সত্তায় নতুন ইউআরআই-তে হাইপারলিঙ্ক সহ একটি সংক্ষিপ্ত হাইপারটেক্সট নোট থাকতে হবে।

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

  Note: When automatically redirecting a POST request after
  receiving a 301 status code, some existing HTTP/1.0 user agents
  will erroneously change it into a GET request.

10.3.3 302 পাওয়া গেছে

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

অস্থায়ী ইউআরআই অবশ্যই প্রতিক্রিয়াতে অবস্থান ক্ষেত্রের দ্বারা দেওয়া উচিত। অনুরোধের পদ্ধতিটি হেড না হলে প্রতিক্রিয়াটির সত্তায় নতুন ইউআরআই-তে হাইপারলিঙ্ক সহ একটি সংক্ষিপ্ত হাইপারটেক্সট নোট থাকতে হবে।

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

  Note: RFC 1945 and RFC 2068 specify that the client is not allowed
  to change the method on the redirected request.  However, most
  existing user agent implementations treat 302 as if it

একটি 303 প্রতিক্রিয়া ছিল, মূল অনুরোধ পদ্ধতি নির্বিশেষে অবস্থান ক্ষেত্রের মানটিতে একটি জিইটি সম্পাদন করে। 303 এবং 307 স্ট্যাটাস কোডগুলি সার্ভারগুলির জন্য যুক্ত করা হয়েছে যা ক্লায়েন্টের কাছ থেকে কোন ধরণের প্রতিক্রিয়া প্রত্যাশা করা হয় তা নির্বিঘ্নে পরিষ্কার করতে চায়।

10.3.4 303 অন্যান্য দেখুন

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

প্রতিক্রিয়া হিসাবে পৃথক ইউআরআই লোকেশন ক্ষেত্র দ্বারা দেওয়া উচিত। অনুরোধের পদ্ধতিটি হেড না হলে প্রতিক্রিয়াটির সত্তায় নতুন ইউআরআই-তে হাইপারলিঙ্ক সহ একটি সংক্ষিপ্ত হাইপারটেক্সট নোট থাকতে হবে।

  Note: Many pre-HTTP/1.1 user agents do not understand the 303
  status. When interoperability with such clients is a concern, the
  302 status code may be used instead, since most user agents react
  to a 302 response as described here for 303.

10.3.5 304 সংশোধিত হয়নি

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

প্রতিক্রিয়াটি নিম্নলিখিত শিরোনাম ক্ষেত্রগুলি অন্তর্ভুক্ত করতে হবে:

  - Date, unless its omission is required by section 14.18.1 If a

ক্লকলেস অরিজিনাল সার্ভার এই নিয়মগুলি মান্য করে এবং প্রক্সিগুলি এবং ক্লায়েন্টরা কোনও উত্তর না পেয়ে প্রাপ্ত প্রতিক্রিয়ায় তাদের নিজস্ব তারিখ যুক্ত করে (ইতিমধ্যে [আরএফসি 2068], বিভাগ 14.19 দ্বারা নির্ধারিত হয়েছে), ক্যাশেগুলি সঠিকভাবে পরিচালনা করবে।

  - ETag and/or Content-Location, if the header would have been sent
    in a 200 response to the same request
  - Expires, Cache-Control, and/or Vary, if the field-value might
    differ from that sent in any previous response for the same
    variant If the conditional GET used a strong cache validator (see

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

যদি 304 টি প্রতিক্রিয়া কোনও সত্তাকে বর্তমানে ক্যাশে করা না নির্দেশ করে তবে ক্যাশে অবশ্যই প্রতিক্রিয়া উপেক্ষা করবে এবং শর্ত ছাড়াই অনুরোধটি পুনরাবৃত্তি করবে।

যদি কোনও ক্যাশে কোনও ক্যাশে এন্ট্রি আপডেট করতে 304 টি প্রাপ্ত প্রতিক্রিয়া ব্যবহার করে তবে ক্যাশে প্রতিক্রিয়াটিতে প্রদত্ত যে কোনও নতুন ক্ষেত্রের মান প্রতিফলিত করতে এন্ট্রিটি আপডেট করতে হবে।

10.3.6 305 প্রক্সি ব্যবহার করুন

অনুরোধ করা সংস্থানটি অবশ্যই ক্ষেত্রের প্রদত্ত প্রক্সি দিয়ে অ্যাক্সেস করতে হবে। অবস্থান ক্ষেত্র প্রক্সিটির ইউআরআই দেয়। প্রাপকের মাধ্যমে প্রাপক এই একক অনুরোধটির পুনরাবৃত্তি করবে বলে আশা করা হচ্ছে। 305 টি প্রতিক্রিয়া কেবল উত্স সার্ভার দ্বারা তৈরি করা আবশ্যক।

  Note: RFC 2068 was not clear that 305 was intended to redirect a
  single request, and to be generated by origin servers only.  Not
  observing these limitations has significant security consequences.

10.3.7 306 (অব্যবহৃত)

306 স্থিতি কোডটি নির্দিষ্টকরণের পূর্ববর্তী সংস্করণে ব্যবহৃত হয়েছিল, আর ব্যবহার করা হয় না এবং কোডটি সংরক্ষিত থাকে।

10.3.8 307 অস্থায়ী পুনঃনির্দেশ

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

অস্থায়ী ইউআরআই অবশ্যই প্রতিক্রিয়াতে অবস্থান ক্ষেত্রের দ্বারা দেওয়া উচিত। অনুরোধের পদ্ধতিটি হেড না হলে, প্রতিক্রিয়ার সত্তাকে নতুন ইউআরআই-এর হাইপারলিঙ্ক সহ একটি সংক্ষিপ্ত হাইপারটেক্সট নোট থাকতে হবে, কারণ অনেক প্রাক-এইচটিটিপি / ১.১ ব্যবহারকারী এজেন্ট 307 স্থিতি বুঝতে পারে না। অতএব, নোটটিতে কোনও ব্যবহারকারীকে নতুন ইউআরআই-তে মূল অনুরোধটির পুনরাবৃত্তি করতে প্রয়োজনীয় তথ্য থাকতে হবে।

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

আমি এখন জন্য 302 ব্যবহার করছি না হওয়া পর্যন্ত আমি খুঁজে সঠিক উত্তর।

আপডেট এবং উপসংহার:

এইচটিটিপি 302 ক্লায়েন্ট / ব্রাউজারগুলির সাথে সবচেয়ে ভাল সামঞ্জস্য রয়েছে বলে পরিচিত better


1
আমি একেবারে বইয়ের মাধ্যমে বলব 401 এবং একটি লগইন পৃষ্ঠা পুনর্নির্দেশ ছাড়াই ফিরিয়ে দেওয়া হবে তবে আপনার অপশনগুলি কী তা আমি নিশ্চিত নই।
নিক Craver

1
@ নিক ভালো পয়েন্ট, তবে আমি যদি ক্লাসিক লগইন সিস্টেম তৈরি করে থাকি তবে তার থেকে আমি পার্শ্ব প্রতিক্রিয়ার আশঙ্কা করব।
পেক্কা

1
@ পেক্কা - সম্পূর্ণরূপে সম্মত, এটি কী প্ল্যাটফর্মের উপর নির্ভর করে যে কীভাবে পরিষ্কারভাবে পরিচালনা করা যায়, এমনকি যদি এটি ইন্টারনেটের বনাম ইন্টারনেট খেলাতে আসে তবে আমি বিশ্বাস করি ... আপনি সাধারণত কোনও ইন্ট্রনেটে আলাদাভাবে প্রমাণীকরণ করেন, আমার অভিজ্ঞতা অন্তত.
নিক Craver

@ নিক 4040 সহ "প্রতিক্রিয়াতে একটি ডাব্লুডাব্লুডাব্লু-প্রমাণীকরণ শিরোনাম ক্ষেত্র অন্তর্ভুক্ত করা উচিত" - আমি কীভাবে এটি মাইএসকিউএল ডাটাবেসের সাথে একত্রিত করতে পারি? অ্যাথটাইপ বেসিক এবং ডাইজেস্ট কি .htpassword ইত্যাদির মতো অ্যাপাচি কনফিগারেশন ফাইলের মধ্যে সীমাবদ্ধ নয় ...?
বিদার ভেষ্টনেস

আমি একটি কাস্টম লগইন-পৃষ্ঠা চাই, ব্যবহারকারীর নাম এবং পাসওয়ার্ডের জন্য জিজ্ঞাসা করা বেসিক ব্রাউজার-সংলাপ নয় ...
বিদর ভেস্টনেস

উত্তর:


66

আমি বলতে চাই 303 অন্যান্য দেখতে 302 পাওয়া গেছে:

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

আমার মতে লগইন পৃষ্ঠায় সবচেয়ে ঘনিষ্ঠভাবে ফিট করে fits আমি প্রাথমিকভাবে বিবেচনা করেছি 303 see otherযা ঠিক পাশাপাশি কাজ করবে। কিছু চিন্তা করার পর, আমি বলতে চাই 302 Foundআরো ঝুলানো হয়, কারণ অনুরোধ করা সংস্থান ছিল পাওয়া, শুধু আগেই অ্যাক্সেস করা যেতে পারে মধ্য দিয়ে যেতে অন্য পাতা। প্রতিক্রিয়া ডিফল্ট হিসাবে ক্যাশে হয় না যা ভাল।


4
আমি সম্মত, তবে আমি মনে করি 302 পাওয়াটি নির্দেশ করে যে উত্সটি অন্য একটি url এর অধীনে পাওয়া গেছে। যাত্রা। আমি 302 দিয়ে / আমার-বার্তা / সার্ভারের উত্তরটি দেখতে চাই কারণ "আজ" আমার বার্তাগুলি "/ লগইন /" ("/ বার্তা /" এর পরিবর্তে) তে অবস্থিত ... আমি 302 ব্যবহার করি তবে আমি অনুভব করি না প্রসঙ্গটি 100% মিলছে। যেহেতু লগইন-পৃষ্ঠাটি একটি ভিন্ন উত্স এবং অনুরোধের মতো একই সামগ্রী নেই।
বিদার ভেষ্টনেস

2
@ পিএইচপি_জেডি সত্য। 303 দৃষ্টিকোণ থেকে আরও উপযুক্ত হতে পারে। তবে, ক্লায়েন্টের সামঞ্জস্যের ক্ষেত্রে 302 আরও নির্ভরযোগ্য।
পেক্কা

1
হ্যাঁ, আমি ভাবছি 303 প্রসঙ্গটি আরও ভাল মাপসই হতে পারে যেহেতু এটিতে "অনুরোধের প্রতিক্রিয়াটি একটি ভিন্ন ইউআরআইয়ের আওতায় পাওয়া যাবে"। এটি আমাকে বলছে যে এটি অন্য যে কোনও ইউআরআই-তে পাওয়া যায় সেই উত্স নিজেই নয়, কেবল এই অনুরোধের প্রতিক্রিয়া।
বিদার ভেষ্টনেস

3
@ পিএইচপি_জেডি আমি নিশ্চিত নই যে এটিতে এত বেশি সময় দেওয়া উপযুক্ত। HTTP বিশ্বের উভয় ক্লায়েন্ট এবং সার্ভারগুলিকে যে কোনও উপায়েই চূড়ান্ত উদার এবং ত্রুটি-সহনশীল হতে হবে, সুতরাং আপনি ব্যবহার করেন 302বা না 303, 302এটি আরও ভাল জানা ছাড়া কোনও আসল পার্থক্য থাকবে না । আমি বিশদের স্তরের প্রশংসনীয় বলে মনে করি এবং জিনিসগুলি সঠিকভাবে পাওয়া ভাল বরাবরই ভাল তবে এই নির্দিষ্ট ক্ষেত্রে খুব বেশি প্রচেষ্টা ব্যর্থ হতে পারে।
পেক্কা 15'10

28
এফওয়াইআই: গুগল 302 সেকেন্ড করেছে
ডেভিড

51

এটি HTTP পুনঃনির্দেশ প্রক্রিয়াটির অপব্যবহার। যদি ব্যবহারকারী অনুমোদিত না হয় তবে আপনার অ্যাপ্লিকেশন অবশ্যই ফিরে আসতে হবে 401 Unauthorized। যদি ব্যবহারকারী অনুমোদিত হয় তবে অনুরোধকৃত উত্সটিতে অ্যাক্সেস না থাকলে 403 Forbiddenঅবশ্যই ফিরে আসতে হবে।

আপনার ক্লায়েন্টের দিকে পুনঃনির্দেশ করা উচিত, যেমন জাভাস্ক্রিপ্ট দ্বারা। পুনঃনির্দেশের জন্য স্থিতি কোড কারণ প্রয়োজনীয় অনুমোদনের অস্তিত্ব নেই । এর জন্য 30x ব্যবহার করা HTTP- র সাথে সামঞ্জস্য নয়।

মার্ক নটিংহাম দ্বারা এইচটিটিপি স্থিতি কোড সম্পর্কে কীভাবে চিন্তা করবেন

401 অননুমোদিত HTTP- র অনুরোধ প্রমাণীকরণ প্রক্রিয়াটিকে ট্রিগার করে।

401 Unauthorizedস্থিতির WWW-Authenticateকোডটির শিরোনামের উপস্থিতি প্রয়োজন যা বিভিন্ন প্রমাণীকরণের ধরণগুলিকে সমর্থন করে:

ডাব্লুডাব্লুডাব্লু-প্রমাণীকরণ: <টাইপ> রিয়েলম = <রিলম>

বহনকারী, ওআউথ, বেসিক, ডাইজেস্ট, কুকি ইত্যাদি


20
একটি 401 কিছু ক্ষেত্রে A server generating a 401 (Unauthorized) response MUST send a WWW-Authenticate header field( আরএফসি ) হিসাবে উপযুক্ত নাও হতে পারে এবং সমস্ত লগইন সিস্টেমগুলি এই শিরোনামটি ব্যবহার করে না।
তারকাবিআমরনবোলাব

6
মনে করুন আপনি একটি সুরক্ষিত পৃষ্ঠাটি সতেজ করছেন; ক্লায়েন্ট সাইড জাভাস্ক্রিপ্ট কল করার জন্য কোনও পরিবর্তন হবে না, এবং ব্রাউজারটি লগইন পৃষ্ঠার দিকে ব্যবহারকারীকে পুনর্নির্দেশের পরিবর্তে একটি লগইন উইন্ডো পপআপ করবে - সুতরাং একমাত্র উপায় 30x কোড ব্যবহার করা।
ক্লোড ব্রিসন

2
পুনর্নির্দেশের জন্য গোলং 401 ব্যবহার করতে পারে না। এর অর্থ পুনঃনির্দেশগুলির জন্য আমাদের 30 * ব্যবহার করা উচিত।
EIMEI

4
@EIII আপনার যুক্তি অনুসরণ করে, যদি অন্য কোনও ভাষা বা গ্রন্থাগার আপনাকে 401 ব্যবহার করতে বাধ্য করে, তবে ইন্টারনেট বিনষ্ট হবে। আমার বক্তব্য: আপনি যা বলছেন তা গোলংয়ের সাথে একটি সমস্যার দিকে ইঙ্গিত করে (যদিও আমি অবাক করে দিয়েছি যে 401s পাঠানো অসম্ভব করে দেওয়ার জন্য এটির এমন নকশা থাকবে!)
গ্রেগ

2
@ স্টারবিআমরিনবোলাবস ডাব্লুডাব্লুডাব্লু-প্রমাণীকরণ শিরোনামে বিকল্প হিসাবে কুকি ভিত্তিক এইচটিটিপি প্রমাণীকরণের জন্য একটি খসড়া রয়েছে। দেখুন: tools.ietf.org/html/draft-broyer-http-cookie-auth-00
aef

12

আমি মনে করি উপযুক্ত সমাধানটি HTTP 401 (অনুমোদিত নয়) শিরোনাম।

http://en.wikipedia.org/wiki/HTTP_codes#4xx_Client_Error

এই শিরোনামটির উদ্দেশ্য হ'ল এটি। তবে, লগইন পৃষ্ঠায় পুনর্নির্দেশের পরিবর্তে সঠিক প্রক্রিয়াটি এমন কিছু হবে:

  • ব্যবহারকারী লগইন নেই একটি লগইন-সীমাবদ্ধ পৃষ্ঠা অ্যাক্সেস করার চেষ্টা করুন।
  • সিস্টেম সনাক্তকারী ব্যবহারকারী লগ করা হয়নি
  • সিস্টেম HTTP 401 শিরোনাম প্রদান করে এবং একই প্রতিক্রিয়াতে লগইন ফর্মটি প্রদর্শন করবে (কোনও পুনর্নির্দেশ নয়)।

সাইটম্যাপ লিঙ্ক সহ উদাহরণস্বরূপ একটি অনুসন্ধান ফর্ম যেমন একটি কার্যকর 404 পৃষ্ঠা সরবরাহ করার মতো এটি একটি ভাল অনুশীলন।

দেখা হবে.


20
আরএফসি জানিয়েছে: "প্রতিক্রিয়াটির মধ্যে একটি ডাব্লুডাব্লুডাব্লু-প্রমাণীকরণের শিরোলেখ ক্ষেত্র অন্তর্ভুক্ত করা উচিত (বিভাগ 14.46) যা অনুরোধকৃত উত্সের ক্ষেত্রে প্রযোজ্য একটি চ্যালেঞ্জ রয়েছে" " একটি এইচটিটিপি প্রমাণীকরণ স্কিম ব্যবহার করার সময় একটি 401 প্রতিক্রিয়া সত্যিই প্রযোজ্য।
bshacklett

4
সেক্ষেত্রে 403 আরও ভাল হবে যেহেতু এটিতে বলা হয়েছে যে অ্যাক্সেসটি কেবল নিষিদ্ধ এবং অনুমোদনের
শিরোনামটি

@bschacklett ডাব্লুডাব্লুডাব্লু-প্রমাণীকরণ অনেকগুলি প্রমাণীকরণের স্কিমগুলির সাথে একসাথে ব্যবহার করা যেতে পারে (যেমন, বহনকারী, OAuth)। দেখুন developer.mozilla.org/en-US/docs/Web/HTTP/Headers/... এবং iana.org/assignments/http-authschemes/http-authschemes.xhtml
filip26

ডাব্লুডাব্লুডাব্লু-প্রমাণীকরণ শিরোনামে বিকল্প হিসাবে কুকি ভিত্তিক এইচটিটিপি প্রমাণীকরণের জন্য একটি খসড়া রয়েছে। দেখুন: tools.ietf.org/html/draft-broyer-http-cookie-auth-00
aef
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.