অন্যান্য ব্যবহারকারীদের নিজস্ব সম্পদের জন্য এমভিসি / আরইএসটি 403 বা 404 ফেরত দেওয়া উচিত?


33

রিসোর্স-ভিত্তিক সাইট (যেমন একটি এমভিসি অ্যাপ্লিকেশন বা আরএসটি পরিষেবা) এর সাথে কাজ করার সময়, যখন আমাদের ক্লায়েন্টের কাছে এমন দুটি GETসংস্থান থাকে যে কোনও সংস্থার কাছে তাদের অ্যাক্সেস না থাকে:

  • 403 , যা বলে যে ক্লায়েন্ট অননুমোদিত ; অথবা
  • 404 , যা বলে যে সংস্থানটি বিদ্যমান নেই (বা অবস্থিত হতে পারে না)।

সাধারণ জ্ঞান এবং সাধারণ অনুশীলনটি সত্যের সাথে প্রতিক্রিয়া দেখাবে বলে মনে হচ্ছে - এটি একটি 403 But তবে আমি ভাবছি যে এটি আসলে সঠিক কাজ করা কিনা।

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

A থেকে গোপনীয়তা দৃষ্টিকোণ, এটা অনেক নিরাপদ বলে মনে হয় একটি 404. আমি তোমাদের সেই ঘটনাটাই স্মরণ করিয়ে করছি যেখানে কেউ বলে জানা দিকে তাকিয়ে রিয়েলিটি শো (সারভাইভার, আমি মনে করি) বিজয়ীদের খুঁজে পাওয়া যায় নি ফিরতে যা সম্পদ করা হয়নি উপস্থিত সাইট বনাম। যা করেছে। আমি 403 সম্ভাব্য সংবেদনশীল তথ্য যেমন সিরিয়াল নম্বর বা অ্যাকাউন্ট নম্বর দেওয়ার বিষয়ে উদ্বিগ্ন।

404 ফেরত না দেওয়ার জন্য কি বাধ্যতামূলক কারণ রয়েছে ? 404 নীতিমালা অন্য কোথাও নেতিবাচক পার্শ্ব প্রতিক্রিয়া থাকতে পারে? যদি তা না হয় তবে অনুশীলন কেন বেশি সাধারণ হয় না?


1
404 ফেরত না দেওয়ার বাধ্যতামূলক কারণ: যদি পরিষেবাটি বন্ধ থাকে বা প্রমাণীকরণে কোনও বাগ / ত্রুটি থাকে তবে আপনি একটি 404 পেয়ে যাবেন তবে গ্রাহক / ব্যবহারকারী / পরীক্ষক / বিকাশকারী / সহায়তা ব্যক্তি সমস্যাটি সনাক্ত করার চেষ্টা করছেন তাদের কোনও ধারণা থাকতে পারে ত্রুটি বার্তা থেকে কি ভুল।
স্টিভেন এভার্স

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

মনে রাখার আরেকটি দিক হ'ল: 404s কীভাবে নিম্ন প্রবাহে চিকিত্সা করা হয়? কোনও সিডিএন বা কোনও ধরণের ক্যাশে রয়েছে? আপনি যদি কখনও সেগুলিকে ক্যাশে রাখতে সক্ষম হতে চান তবে আপনি সম্ভবত 404s ক্যাশে হওয়ার জন্য আপনার "ব্যবহারকারীর অনুমতি নেই" চান না।
pc1oad1etter

উত্তর:


15

এর সাথে একটি সাধারণ ভুল ধারণা (এবং অপব্যবহার) যুক্ত আছে 403 Forbidden: সার্ভারটি অনুরোধ সম্পর্কে কী ভাববে সে সম্পর্কে কিছু দেওয়ার কথা নয়। এটি বিশেষত বলতে ডিজাইন করা হয়েছে,

আপনি যা অনুরোধ করছেন তা আমি পেয়েছি তবে আপনি যা চেষ্টা করবেন তা বিবেচনা করেই আমি এই আবেদনটি পরিচালনা করছি না। তাই চেষ্টা করা বন্ধ করুন।

যে কোনও ইউএ বা ক্লায়েন্টের ব্যাখ্যা করা উচিত এর অর্থ এই যে অনুরোধটি কখনই কাজ করবে না এবং যথাযথভাবে প্রতিক্রিয়া জানাবে।

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

403এর বিপরীতে রয়েছে 401 Authorization Required, যা আপনাকে দেয় যে আপনি সঠিক শংসাপত্রগুলি পাস করার পরে সার্ভারটি অনুরোধটি পরিচালনা করবে handle লোকেরা যখন শুনতে পায় তখন এটি সাধারণত চিন্তা করে 403

এটি এর বিপরীতেও রয়েছে 404 Page Not Found, যেমন অন্যরা দেখিয়েছে, কেবল "আমি সেই পৃষ্ঠাটি পাই না" বলার জন্যই নয় বরং ক্লায়েন্টকে পরামর্শ দেওয়ার জন্য তৈরি করা হয়েছে যে সার্ভার ভবিষ্যতের অনুরোধগুলির জন্য সাফল্য বা ব্যর্থতার কোনও দাবি করে না।

401এবং এর সাথে 404সার্ভার ক্লায়েন্ট বা ইউএকে কীভাবে এগিয়ে যেতে হবে সে সম্পর্কে কিছুই বলে না: তারা অন্যরকম প্রতিক্রিয়া পাওয়ার আশায় চেষ্টা চালিয়ে যেতে পারে।

আপনি 404যে পৃষ্ঠাটি সবার কাছে দেখাতে চান না তা হ্যান্ডেল করার উপযুক্ত উপায় হ'ল তবে আপনি কেন কিছু নির্দিষ্ট পরিস্থিতিতে এটি দেখাবেন না সে সম্পর্কে কিছু দিতে চান না।

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

এটি হ'ল বলুন আপনার হ্যান্ডলারটি users/*। যদি আমি জানি users/foo, users/barএবং users/baazকাজ, সার্ভারটি একটি এমন ফেরার 401, 403অথবা 404জন্য users/quuxমানে এই নয় আমি এটা চেষ্টা করতে যাচ্ছি না, বিশেষ করে যদি আমি বিশ্বাস করতে সেখানে কারণ আছে হয় একটি quuxব্যবহারকারী। একটি আদর্শ উদাহরণ দৃশ্যের নাম ফেসবুক: আমার প্রোফাইলটি ব্যক্তিগত, তবে পাবলিক প্রোফাইলে আমার মন্তব্য নেই। একজন দূষিত ক্লায়েন্ট জানেন যে আপনি 404আমার প্রোফাইল পৃষ্ঠায় ফিরে এলেও আমার অস্তিত্ব রয়েছে ।

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


4
401 বনাম 403 সম্পর্কে ভাল পয়েন্টগুলি 40 404-তে আপনার বক্তব্যের চূড়ান্ততার সাথে আমি একমত নই। অবশ্যই, ফেসবুকের উদাহরণে, আপনি ইতিমধ্যে জানেন যে এটি quuxবিদ্যমান। তবে সর্বদা বাহ্যিক প্রমাণ হতে পারে না, বিশেষত অ-সামাজিক সাইটে যেখানে ক্লায়েন্টের ডেটা সত্যিই ব্যক্তিগত । একটি দীর্ঘনাসা বা প্রতিকূল ব্যবহারকারী অবশেষে অনুমান করতে সক্ষম হতে পারেন যে তুমি মিথ্যা বলছ, কিন্তু না অগত্যা যা সম্পদ তুমি মিথ্যা বলছ সম্পর্কে । আমি মনে করি যে এখানে মূল বক্তব্যটি সত্যই, 404 রিসোর্সগুলিকে বিরক্ত করবেন না যদি না আবিষ্কারের অন্য কোনও পদ্ধতি উপলব্ধ না হয়।
অ্যারোনআট

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

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

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

8

আরএফসি 2616 অনুসারে

10.4.4 403 নিষিদ্ধ

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

এছাড়াও মনে রাখবেন যে নিষিদ্ধ সংস্থানগুলিতে অ্যাক্সেস করার সময়, অনুমোদন সাহায্য করবে না


আমি আরএফসি সম্পর্কে সচেতন, যদিও এটি বাস্তবতার সাথে সামান্য সাদৃশ্য রাখে। প্রায় কোনও সার্ভারই ​​এর প্রথম বাক্যটির বাইরে 403 এর কারণ ব্যাখ্যা করে না ("সার্ভারটি অনুরোধটি বুঝতে পেরেছিল, তবে এটি সম্পাদন করতে অস্বীকার করছে।") এবং বেশিরভাগ এমভিসি ফ্রেমওয়ার্কের কাছে এমন কিছু HttpUnauthorizedResultরয়েছে যা বিশেষাধিকারযুক্ত সংস্থাগুলির জন্য ব্যবহৃত হতে পারে । আমি আরও বুঝতে পারি (স্পষ্টতই) যে এর পরিবর্তে 404 ব্যবহার করা যেতে পারে; আমার প্রশ্ন হ'ল এটি ব্যবহার করা উচিত কি না এবং সেই সিদ্ধান্ত নেওয়ার সময় কী বিবেচনা করা উচিত।
অ্যারোনআট

@ অ্যারোনট: আরএফসি কেবল আপনাকে 404 ব্যবহার করার অনুমতি দেয় না, এটি প্রস্তাব দেয় যে 404 নিক্ষেপ করা হবে যখন আপনি কোনও কিছুই স্বীকার করতে চান না।
মিথ্যা রায়ান

3
এটা ঠিক আছে, কিন্তু আমি কখনই কিছু স্বীকার করব না? বা বরং, আমি কখন করা উচিত ? এটাই আসলে প্রশ্নের সারমর্ম।
অ্যারোনআট

5

আপনার উচিত? হ্যাঁ

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

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

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


404 ফেরত না দেওয়ার বাধ্যতামূলক কারণ: যদি পরিষেবাটি বন্ধ থাকে বা প্রমাণীকরণে কোনও বাগ / ত্রুটি থাকে তবে আপনি একটি 404 পেয়ে যাবেন তবে গ্রাহক / ব্যবহারকারী / পরীক্ষক / বিকাশকারী / সহায়তা ব্যক্তি সমস্যাটি সনাক্ত করার চেষ্টা করছেন তাদের কোনও ধারণা থাকতে পারে ত্রুটি বার্তা থেকে কি ভুল

বিকাশকারীদের লগগুলিতে অ্যাক্সেস থাকা উচিত, যা কোনও সুরক্ষিত সংস্থান অ্যাক্সেসের প্রয়াসকে নির্দেশ করবে। গ্রাহক / ব্যবহারকারী / পরীক্ষকরা প্রতিক্রিয়া উত্পন্ন করবে যা শেষ পর্যন্ত কোনও বিকাশকারীকে আঘাত করবে।

অস্পষ্টতার দ্বারা সুরক্ষা ... সত্যই?

এটি অস্পষ্টতার দ্বারা সুরক্ষা নয়। আপনি যথাযথ সুরক্ষা ব্যবস্থা ছাড়াও অস্পষ্টতা ব্যবহার করছেন ।

অন্যদিকে "404" পাওয়ার জন্য বৈধ অনুরোধগুলি কেবল জটিলতা এবং অস্পষ্টতা যুক্ত করছে যেখানে এটি প্রয়োজনীয় নয়

তারা বৈধ অনুরোধ নয়, তারা অননুমোদিত অনুরোধ। যে কোনও আক্রমণকারীদের যথেষ্ট সুবিধা পেতে আপনি একটি ছোট অংশ (403 এর পরিবর্তে 404 ফেরৎ) পরিবর্তন করছেন।


অস্পষ্টতার দ্বারা সুরক্ষা ... সত্যই? যদি কেউ আপনার পরিষেবা (গুলি) কে দূষিত অভিপ্রায় সহকারে চেষ্টা করার চেষ্টা করে তবে তারা ইতিমধ্যে জানতে পারে যে এটি সেখানে রয়েছে। অন্যদিকে "404" পাওয়ার জন্য বৈধ অনুরোধগুলি কেবল জটিলতা এবং অস্পষ্টতা যুক্ত করছে যেখানে এটি প্রয়োজনীয় নয়।
স্টিভেন এভার্স

4
@ স্নারফাস: সুরক্ষা এবং গোপনীয়তার মধ্যে এখানে একটি সূক্ষ্ম পার্থক্য রয়েছে । গোপনীয়তা হ'ল প্রায় সংজ্ঞা অনুসারে, "অস্পষ্টতার দ্বারা"। এটি একটি উত্স ভিত্তিক সিস্টেমের প্রসঙ্গে বিশেষত গুরুত্বপূর্ণ , যেহেতু কোনও সংস্থার অস্তিত্ব বা অস্তিত্ব সম্ভাব্য গুরুত্বপূর্ণ তথ্য। সুরক্ষা যুক্তিও থাকতে পারে, যদিও আমি তাদের সাথে কমই উদ্বিগ্ন। আমি চাই এই যোগ জটিলতা সম্পর্কে আরো শুনতে চাই; আপনার প্রাথমিক মন্তব্যের বাইরে আপনি কি বিশদে যেতে পারবেন? (সম্ভবত আরও বিস্তৃত উত্তরে? আপনার কি 404'ed 403s দ্বারা কামড় দেওয়া হয়েছে?)
অ্যারোনআউট

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

@ অ্যারোনট: আমি আরও গভীরতর উত্তর পোস্ট করব, তবে ইস্যুতে: যদি কোনও উত্স ব্যক্তিগত হয় তবে প্রকাশ্যে প্রকাশ করার পিছনে যুক্তি কী?
স্টিভেন ইভার্স

@ স্নারফাস: একটি সংস্থান কোনও ক্লায়েন্টের জন্য ব্যক্তিগত - বা একটি গোষ্ঠীর কাছে - পুরো বিশ্বের কাছে নয়।
অ্যারোনআট

0

এটি সত্যই 403 স্থিতি কোড দ্বারা প্রদত্ত তথ্যের উপর নির্ভর করে। যদি আপনার কাছে কোনও এপিআই এন্ডপয়েন্ট থাকে GET /myresource/{id}যখন 404 রিসোর্সের অস্তিত্ব নেই, তখন স্থিতি কোডটি শেষ পয়েন্টে ফিরে আসে যখন রিসোর্সটি উপস্থিত থাকে তবে বর্তমান ব্যবহারকারীর কাছে অনুমোদিত না হলে idপ্যারামিটারের পূর্বাভাসের উপর নির্ভর করতে হবে , এবং পরিমাণ এটি নিজেই রয়েছে তথ্যের।

  • যদি idকোনও ইমেল ঠিকানা বা কোনও ব্যাংক অ্যাকাউন্টের মতো ব্যক্তিগত ক্ষেত্র হয় তবে এটি সম্ভবত একটি 404 এর আড়ালে লুকানো উচিত an ইমেল ঠিকানার ক্ষেত্রে এটি স্প্যামিং বটগুলিকে আপনার ওয়েবসাইটে নিবন্ধিত বৈধ ইমেল ঠিকানাগুলির একটি তালিকা তৈরি করতে বাধা দিতে পারে।
  • যদি idসর্বজনীন ব্যবহারকারীর নাম হয় তবে বিরক্ত করবেন না, এই তথ্যে অ্যাক্সেস পাওয়ার অন্যান্য উপায় রয়েছে (যেমন, কেবলমাত্র আপনার ওয়েবসাইটের ফোরাম পৃষ্ঠাটি ব্রাউজ করে)।
  • যদি idএটি অস্বচ্ছ, তবে অনুমানযোগ্য সনাক্তকারী (উদাহরণস্বরূপ একটি স্বয়ং-বৃদ্ধিকরণ পূর্ণসংখ্যা) হয় তবে আপনি আক্রমণকারীকে এমন কোনও তথ্য দেবেন না যা তিনি অন্য উপায়ে পেতে পারেন নি। সুতরাং আমার মতে এটি 403 স্থিতির কোডটি ফিরিয়ে দেওয়া নিরাপদ।
  • যদি idঅস্বচ্ছ, অনির্দেশ্য সনাক্তকারী (এলোমেলো জিইউডির মতো) হয় তবে প্রশ্নটি আরও সূক্ষ্ম। আমি ব্যক্তিগতভাবে 403 স্থিতি কোডটি ফেরত দিতে কোনও সমস্যা নেই বলে মনে করি। এই আইডিটি ব্যবহার করে আপনার API এ অন্য কোনও ত্রুটিযুক্ত এন্ডপয়েন্ট রয়েছে তবেই এই তথ্যটি কাজে লাগানো যেতে পারে তবে আসল ত্রুটিটি আপনার অন্য শেষ পয়েন্ট।

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

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

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