$ _REQUEST [] ব্যবহার করে কী ভুল হয়েছে?

Question

আমি এখানে বেশ কয়েকটি পোস্ট দেখেছি যা $_REQUESTভেরিয়েবলটি ব্যবহার না করার জন্য বলেছে । আমি সাধারণত না, তবে কখনও কখনও এটি সুবিধাজনক। এতে দোষ কী?

Comments

সম্পর্কিত প্রশ্নোত্তর দেখুন: স্ট্যাকওভারফ্লো.com

— গর্ডন

পিএইচপি 5.3 থেকে ডিফল্ট php.ini বলছে কেবল জিইটি এবং পোষ্টের ডেটা intoোকানো হয় $_REQUEST। Php.net/request_order দেখুন কুকি ডেটা থাকার কথা আশা করে $_REQUESTএবং কেন এটি কাজ করছে না তা ভেবে আমি এই পিছনের দিকে সামঞ্জস্যতা বিরতিতে গিয়ে হোঁচট খেয়েছি ! সুতরাং $ _REQUEST ব্যবহার এড়াতে সবচেয়ে বড় কারণ এখন আপনার স্ক্রিপ্ট request_orderনিজেকে সেট করতে পারে না (এটি এটি PHP_INI_PERDIR), সুতরাং একটি php.ini পরিবর্তন সহজেই আপনার স্ক্রিপ্টটি নির্মিত অনুমানগুলি ভেঙে ফেলতে পারে। এই অনুমানগুলি সরাসরি আপনার স্ক্রিপ্টে রাখাই ভাল।

— ড্যারেন কুক

Answer 1

উভয় থেকে $_GETএবং $_POSTসম্মিলিত উপায়ে ইনপুট নেওয়ার সাথে একেবারেই ভুল নেই । আসলে আপনি প্রায় সবসময় এটি করতে চান:

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

• একটি সত্যিকারের প্রভাবের অনুরোধের জন্য, আপনাকে পরীক্ষা করতে হবে যে এটি পোষ্ট পদ্ধতিতে জমা দেওয়া হয়েছে। তবে এটি করার উপায় হ'ল $_SERVER['REQUEST_METHOD']স্পষ্টভাবে চেক করা, $_POSTকোনও জিইটি-র জন্য খালি থাকার উপর নির্ভর করবেন না । এবং যাইহোক, যদি পদ্ধতিটি হয় তবে POSTআপনি এখনও URL এর বাইরে কিছু ক্যোয়ারী প্যারামিটার নিতে চাইতে পারেন।

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

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

আপনি এই আচরণটি পিএইচপি 5.3- র অনুরোধ_র্ডার কনফিগারেশনের মাধ্যমে আরও বেশি সংবেদনশীল GP(না C) আদেশে পরিবর্তন করতে পারেন । যেখানে এটি সম্ভব নয়, আমি ব্যক্তিগতভাবে এড়াতে পারতাম এবং, যদি আমার সম্মিলিত জিইটি + পোষ্ট অ্যারের প্রয়োজন হয় তবে এটি ম্যানুয়ালি তৈরি করুন।$_REQUEST

Comments

এই পরিস্থিতি (জিইটির মাধ্যমে জমা দেওয়ার জন্য ডেটা খুব দীর্ঘ) কোনও ব্যতিক্রম নয়, কোনও নিয়ম নয়

— বেন জেমস

চমৎকার উত্তর. আমি আরও লক্ষ্য করেছি যে জেন্ডার ফ্রেমওয়ার্ক জিইটি এবং পোষ্ট প্যারামগুলির মতো ফ্রেমওয়ার্কগুলির সাথে 1 অনুরোধ অবজেক্টে একত্রিত করা হয়েছে। আমি আপনার পোস্টটি পড়া না হওয়া পর্যন্ত এটি কখনই আমাকে আঘাত করে না।

— জে সিড্রি

ডিফল্টরূপে request_order কনফিগারেশন "জিপি" এ সেট করা হয় php.ini পিএইচপি হিসাবে 5.4+ তাই আমি বলতে চাই এটি জন্য যান ... কিন্তু হিসাবে সবসময়, সাবধানতার সাথে এগিয়ে যান।

— বিএমএমনি

যদি $ _POST হয় a="foo"এবং $ _COOKIE হয় a="bar", তবে এখানে কি কোনও ওভাররাইড / বিবাদ হবে?

— মরিচা

Answer 2

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

পিএইচপি ইন্টার্নালগুলিতে স্টেফান এসারের উদ্ধৃত করা

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

এবং পরে একই থ্রেডের জবাব

কেউ GET, পোষ্ট জাল করতে পারে এই বিষয়টি নিয়ে নয়; কুকি ভেরিয়েবল। এটি সত্য যে কুকিগুলি জিইটি এবং পোষ্ট ডেটাগুলিকে অনুরোধে ওভাররাইট করবে।

অতএব আমি আপনার ব্রাউজারটিকে একটি কুকি দ্বারা সংক্রামিত করতে পারি যা বলছে যেমন অ্যাকশন = লগআউট এবং সেই দিন থেকে আপনি আর অ্যাপ্লিকেশনটি ব্যবহার করতে পারবেন না কারণ অনুরোধ [ক্রিয়া] চিরতরে লগআউট হয়ে যাবে (যতক্ষণ না আপনি নিজে কুকি মুছবেন)।

এবং আপনাকে কুকির সাথে সংক্রামিত করা এত সহজ ...
ক) আমি সাবডোমেনের যে কোনও অ্যাপ্লিকেশনটিতে একটি এক্সএসএস ভালান ব্যবহার করতে পারি
খ) আপনার নিজের মালিকানাধীন যখন কখনও * .co.uk বা * .co.kr এর জন্য একটি কুকি সেট করার চেষ্টা করেছি b সেখানে একক ডোমেইন?
গ) অন্যান্য ক্রস ডোমেন যাই হোক না কেন ...

এবং যদি আপনি বিশ্বাস করেন যে এটি কোনও সমস্যা নয় তবে আমি আপনাকে বলতে পারি যে ফিতে একটি * .co.kr কুকি সেট করার একটি সহজ সম্ভাবনা রয়েছে যার ফলস্বরূপ বেশ কয়েকটি পিএইচপি সংস্করণ কেবল সাদা পৃষ্ঠাগুলি ফিরে আসে। কল্পনা করুন: * .co.kr- তে সমস্ত পিএইচপি পৃষ্ঠাগুলি মারার জন্য কেবল একটি কুকি

এবং + পিএইচপিএসইএসআইডি = অবৈধ নামে একটি চলকতে * .co.kr এর বৈধ কুকিতে একটি অবৈধ সেশন আইডি সেট করে আপনি এখনও পিএইচপি সেশন ব্যবহার করে কোরিয়ার প্রতিটি পিএইচপি অ্যাপ্লিকেশন ডস করতে পারেন ...

আরও কয়েকটি পোস্টিংয়ের জন্য আলোচনা অব্যাহত রয়েছে এবং এটি পড়তে আগ্রহী।

---

আপনি দেখতে পাচ্ছেন, $ $QQUEST এর সাথে মুখ্য সমস্যাটি এতটা নয় যে এটির $ _GET এবং $ _POST থেকে নয়, তবে $ _COOKIE থেকেও ডেটা রয়েছে। তালিকার অন্য কয়েকজন ছেলের ক্রমটি পরিবর্তনের পরামর্শ দেওয়া হয়েছে যাতে filled _REQUEST টি পূরণ করা হয়েছে, যেমন $ _COOKIE দিয়ে প্রথমে এটি পূরণ করা, তবে এটি সেশন হ্যান্ডলিং সহ উদাহরণস্বরূপ অন্যান্য অসংখ্য সম্ভাব্য সমস্যা তৈরি করতে পারে ।

আপনি সম্পূর্ণরূপে Q _REQQUEST গ্লোবাল থেকে $ _COOKIES বাদ দিতে পারেন, যাতে এটি অন্য কোনও অ্যারে দ্বারা ওভাররাইট না করা হয় (প্রকৃতপক্ষে, আপনি এটিকে স্ট্যান্ডার্ড সামগ্রীর কোনও সংমিশ্রণে সীমাবদ্ধ করতে পারেন, যেমন ভেরিয়েবল_র্ডার ইনই সেটিংসে পিএইচপি ম্যানুয়াল হিসাবে আমাদের বলে:

ভেরিয়েবল_র্ডার EGPCS (পরিবেশ, গেট, পোস্ট, কুকি এবং সার্ভার) ভেরিয়েবল পার্সিংয়ের ক্রম সেট করে। উদাহরণস্বরূপ, যদি ভেরিয়েবল_র্ডারটি "এসপি" তে সেট করা থাকে তবে পিএইচপি সুপারগ্লোবালগুলি তৈরি করবে _S _SERVER এবং $ _POST, তবে create _ENV, $ _GET এবং $ _COOKIE তৈরি করবে না। "" সেট করার অর্থ কোনও সুপারগ্লোবাল সেট করা হবে না।

তবে আবার, আপনি পুরোপুরি _RE $QQUEST ব্যবহার না করার বিষয়টিও বিবেচনা করতে পারেন, কেবলমাত্র পিএইচপি-এ আপনি নিজের গ্লোবালগুলিতে পরিবেশ, গেট, পোস্ট, কুকি এবং সার্ভার অ্যাক্সেস করতে পারেন এবং একটি আক্রমণ ভেক্টর কম রাখতে পারেন। আপনার এখনও এই ডেটা স্যানিটাইজ করতে হবে, তবে এটি নিয়ে চিন্তিত হওয়া কম জিনিস।

---

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

আমরা এর থেকে যত বেশি স্টাফ সরিয়ে ফেলি, তত দ্রুততর পিএইচপি-র নতুন, দ্রুত এবং আরও সুরক্ষিত সংস্করণগুলিতে স্থানান্তর করা লোকের পক্ষে শক্ত হয়ে যায়। এটি কয়েকটি "কুশ্রী" উত্তরাধিকার বৈশিষ্ট্যগুলির চেয়ে সবার জন্য আরও হতাশার কারণ হয়ে দাঁড়ায়। যদি কোনও শালীন প্রযুক্তিগত কারণ, কর্মক্ষমতা বা সুরক্ষা থাকে তবে আমাদের এটির কঠোর নজর দেওয়া দরকার। এই ক্ষেত্রে, আমাদের যে জিনিসটির দিকে নজর দেওয়া উচিত তা হ'ল আমাদের $ _REQUEST অপসারণ করা উচিত নয় তবে এটি থেকে কুকি ডেটা সরিয়ে ফেলা উচিত কিনা isn't অনেকগুলি কনফিগারেশন ইতিমধ্যে আমার নিজের সমস্তগুলি সহ তা করেছে এবং $ _REQUEST তে কুকিজ অন্তর্ভুক্ত না করার জন্য একটি শক্তিশালী বৈধ সুরক্ষা কারণ রয়েছে। বেশিরভাগ লোকেরা জিইটি বা পোষ্ট বলতে বোঝায় $ _REQUEST ব্যবহার করে, বুঝতে পারে না যে এতে কুকিগুলিও থাকতে পারে এবং যেমন খারাপ ছেলেরা সম্ভবত কিছু কুকি ইনজেকশন ট্রিক করতে পারে এবং নিষ্পাপ অ্যাপ্লিকেশনগুলি ভেঙে ফেলতে পারে।

যাইহোক, আশা করি যে কিছু আলো ফেলেছে।

Comments

+1 এর কিছু আলোচনা দেখে ভাল লাগছে ... আমি ভেবেছিলাম আমি পাগল হয়ে যাচ্ছি!

— ববিনস

আমি মনে করি যে আলোচনাটি কিছুটা অতিমাত্রায় তৈরি হয়েছিল। আসল সমস্যাটি বিকাশকারীদের অজান্তেই, প্রতি সেয়ে $ _REQUEST এ কুকিজের অস্তিত্ব নয়। উদাহরণস্বরূপ স্থির PHPSESSID সমসাময়িক সেশন হ্যান্ডলিং কোড সহ যে কোনওভাবেই প্রতি-ডোমেন কুকির সাথে রিসেট হতে চলেছে। এবং কিছু অ্যাপ্লিকেশনের জন্য কুকি ওভাররাইডিংয়ের অনুরোধের ভারগুলি সত্যই কাম্য হতে পারে (উদাঃ সাজ্ট_র্ডার = এএসসি একটি অনুসন্ধান ফর্ম জিইটি ভার ওভাররাইড করে)। যদিও এই জাতীয় আচরণে কোডিং কোডিং আরও বোধগম্য।

— মারিও

খুব বিস্তৃত পোস্ট, এটির উত্তর হওয়া উচিত। লোকেরা দীর্ঘ পোস্টের আশঙ্কা করতে পারে;)

— জাজুন নগুইন

দুঃখিতভাবে, Rasmus 2009 সালে এটিতে মন্তব্য, এবং এখনও $ _REQUEST মূলত একই এখন, 2015. রয়েছে

— Kzqai

Answer 3

$_REQUESTসমস্ত ধরণের অনুরোধকে (জিইটি, পোস্ট ইত্যাদি) বোঝায়। এটি কখনও কখনও দরকারী, তবে সঠিক পদ্ধতিটি ($ _GET, $ _POST ইত্যাদি) নির্দিষ্ট করা সাধারণত ভাল।

Comments

এই উত্তরটি $ _REQUEST কী তা বর্ণনা করে তবে এটি প্রশ্নের উত্তর দেয় না।

— জুমব্যাট

তিনি বলছেন যে কী ধরনের অনুরোধ আসবে তা জানতে এবং সেই নির্দিষ্ট অনুরোধটির কোড করতে কোড করা আরও ভাল অনুশীলন।

— পোলারিস 878

Answer 4

$_REQUEST সাধারন থেকে মাঝারি-জটিলতার ডেটা-ট্রান্সফরমেশনগুলি প্রায়শই এসকিউএলে ঘোষণার পরিবর্তে অ্যাপ্লিকেশন কোডে সঞ্চালিত হয়: একই কারণেই সাধারণত ক্ষতিকারক হিসাবে বিবেচিত হয়: কিছু প্রোগ্রামার স্তন্যপান করেন।

যেমন, যদি কেউ $_REQUESTসর্বত্র ব্যবহারের দিকে ঝোঁক থাকে তবে আমি জিইটি এর মাধ্যমে পোস্টের মাধ্যমে যা কিছু করতে পারি, তার অর্থ <img>আমার (দূষিত) সাইটে ট্যাগগুলি স্থাপন করা যার ফলে ব্যবহারকারীরা আপনার ই-বাণিজ্য মডিউলে লগইন করে নীরবে পণ্য ক্রয় করতে পারে, বা আমি তাদের লিঙ্কগুলিতে ক্লিক করার কারণ হতে পারে যা বিপজ্জনক ক্রিয়া বা সংবেদনশীল তথ্য প্রকাশের ফলে ঘটতে পারে (সম্ভবত আমার কাছে)।

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

ফর্ম্যাট প্যারামিটারের সামগ্রীটি পরীক্ষা করার সময়, এটি কোয়েরিস্ট্রিং বা একটি পোস্টডেটার মাধ্যমে পাঠানো যেতে পারে, এটি বিভিন্ন কারণের উপর নির্ভর করে কলিং অ্যাপ্লিকেশনগুলি তার অনুরোধের সাথে "& ফর্ম্যাট = জেসন" মিশ্রিত করতে চায় কিনা তা নয় not এই ক্ষেত্রে, $_REQUESTখুব সুবিধাজনক কারণ এটি আমাকে এ জাতীয় কিছু টাইপ করে বাঁচায়:

$format = isset($_POST['format']) ? $_POST['format'] 
    : (isset($_GET['format']) ? $_GET['format'] : null);

আমি আরও কিছুটা দৌড়ঝাঁপ করতে যাচ্ছি না, তবে পর্যাপ্ত পরিমাণে বলার $_REQUESTঅপেক্ষা রাখে না যে ব্যবহারটি অন্তর্নিহিত বিপজ্জনক - কারণ এটি কেবলমাত্র অন্য একটি সরঞ্জাম যা এটি সম্পর্কে জিজ্ঞাসা করা ঠিক তা করে, আপনি সেগুলি বোঝেন বা না - এটি হ'ল কোনও দুর্বল, অলস বা অনভিজ্ঞ প্রোগ্রামার এর দুর্বল, অলস বা অজ্ঞাত সিদ্ধান্ত যা এই সমস্যার কারণ হয়ে দাঁড়ায়।

$_REQUESTনিরাপদে কীভাবে ব্যবহার করবেন

---

1. আপনার ডেটা জানুন : আপনি কী ধরণের ডেটা পাবেন সে সম্পর্কে আপনার কিছুটা আশা করা উচিত, সুতরাং সেই অনুযায়ী এটি স্যানিটাইজ করুন। একটি ডাটাবেসের জন্য ডেটা? addslashes()বা *_escape_string()। এটি আবার ব্যবহারকারীর কাছে প্রদর্শন করতে যাচ্ছেন? htmlentities()বা htmlspecialchars()। সংখ্যার ডেটা আশা করছেন? is_numeric()বা ctype_digit()। আসলে, filter_input()এবং এর সম্পর্কিত ফাংশনগুলি ডেটা পরীক্ষা এবং স্যানিটাইজ করা ছাড়া কিছুই করার জন্য ডিজাইন করা হয়েছে। এই সরঞ্জামগুলি সর্বদা ব্যবহার করুন।
2. সরাসরি ব্যবহারকারীর সরবরাহিত সুপারগ্লোবাল ডেটা অ্যাক্সেস করবেন না । প্রতিবার আপনার ডেটা স্যানিটাইজ করার অভ্যাস তৈরি করুন এবং আপনার ডেটাটি ভেরিয়েবলগুলি পরিষ্কার করার জন্য সরান, এমনকি যদি তা ঠিক থাকে $post_clean। বিকল্পভাবে, আপনি কেবল সুপারগ্লোবালগুলিতে সরাসরি পরিষ্কার করতে পারেন, তবে আমি পৃথক ভেরিয়েবল ব্যবহারের পক্ষে পরামর্শ করার কারণ হ'ল কোডটি দুর্বলতাগুলি চিহ্নিত করা সহজ করে তোলে কারণ কোনও সুপারগ্লোবালকে সরাসরি নির্দেশ করা এবং এর স্যানিটাইজড সমতুল্য না হয়ে কোনও কিছু বিপজ্জনক ত্রুটি হিসাবে বিবেচিত হয় ।
3. আপনার ডেটা কোথা থেকে আসা উচিত তা জানুন। উপরে থেকে আমার উদাহরণ উল্লেখ করে, প্রতিক্রিয়া ফর্ম্যাট ভেরিয়েবলটি জিইটি বা পোষ্টের মাধ্যমে প্রেরণের অনুমতি দেওয়া পুরোপুরি যুক্তিসঙ্গত। আমি উভয় পদ্ধতির মাধ্যমে "অ্যাকশন" ভেরিয়েবলটি প্রেরণের অনুমতি দিই। তবে এইচটিটিপি ভার্বনটি গ্রহণযোগ্য কিনা সে সম্পর্কে ক্রিয়াগুলির নিজস্ব নির্দিষ্ট সুনির্দিষ্ট প্রয়োজনীয়তা রয়েছে । উদাহরণস্বরূপ, কার্যগুলি যে পরিষেবা দ্বারা ব্যবহৃত ডেটাগুলিতে পরিবর্তন করে কেবলমাত্র POST এর মাধ্যমে প্রেরণ করা যেতে পারে। নির্দিষ্ট প্রকারের অ-বা নিম্ন-সুবিধাযুক্ত ডেটার জন্য অনুরোধ (যেমন গতিশীল উত্পন্ন মানচিত্রের চিত্রগুলি) উভয় পদ্ধতির অনুরোধের প্রতিক্রিয়া হিসাবে পরিবেশন করা যেতে পারে।

উপসংহারে, এই সাধারণ নিয়মটি মনে রাখবেন:

সুরক্ষা আপনি এটি তৈরি করেন কি, মানুষ!

সম্পাদনা করুন:

আমি বোবিন্সের পরামর্শটি দৃ strongly ়ভাবে প্রস্তাব দিচ্ছি: যদি আপনি পারেন তবে request_orderphp.ini এর প্যারামিটারটি "জিপি" তে সেট করুন ; এটি কোনও কুকি উপাদান নয়। 98% + ক্ষেত্রে এর জন্য প্রায় কোনও যৌক্তিক যুক্তি নেই, কারণ কুকি ডেটা প্রায় কখনওই ক্যোরিস্ট্রিং বা পোস্টডাটার সাথে তুলনীয় হিসাবে বিবেচনা করা উচিত নয়।

পিএস, উপাখ্যান!

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

Answer 5

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

যদি আপনার অ্যাপ্লিকেশনটি ডেটা ব্যবহার করে থাকে তবে $_REQUESTএটি জিইটি এবং পোষ্ট উভয় অনুরোধের জন্য একই আচরণ করবে, যা জিইটি এর আদর্শশক্তি লঙ্ঘন করে।

Comments

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

— স্প্রোগম্যান

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

— জুমব্যাট

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

— বেন জেমস

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

— এরিক পেট্রোলেজে

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

— স্প্রোগম্যান

Answer 6

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

Answer 7

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

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

ইটিএ :

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

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

Comments

এটা একটা ভয়াবহ ভুল আপনি কীভাবে গ্যারান্টি দিতে পারেন যে পোষ্টের উপরে অ-আদর্শবান কর্ম সম্পাদন করা হয়েছিল?

— কাইল বাট

@ কাইল - এটি অ-আদর্শহীন কর্মের জন্য ব্যবহার না করে। আমি অবশ্যই এটি সমস্ত কিছুর জন্য ব্যবহার করব না, কেবল এটি নির্দেশ করে যে এটি দরকারী, যেমন অনুসন্ধানগুলির জন্য যেমন আমি আমার উদাহরণে উল্লেখ করেছি।

— এরিক পেট্রোলেজে

এই magন্দ্রজালিক ধারণাটি যে _POST সুরক্ষিত এবং _গেটটি যেতে পারেনি। আমি যদি আপনার সফ্টওয়্যারটি সঠিকভাবে ব্যবহার না করে থাকি তবে জিইটি অনুরোধের বিপরীতে পোষ্ট অনুরোধ প্রেরণে আমার মধ্যে খুব কম (যদি থাকে) কিছু পার্থক্য নেই। সুরক্ষা আপনি ডেটা দিয়ে যা করেন তা তেমন নয়, কোথা থেকে আসে। সাধারণ এক্সএসএস / অনুরোধ শোষণের ক্ষেত্রে, এটি সম্পূর্ণরূপে এটি কেবলমাত্র POST বা GET এর সাথে বৈধ হবে এমন মানগুলির জন্য _REQUEST ব্যবহার করে এবং পোস্ট করা উচিত এমন জিনিসগুলির জন্য _POST ব্যবহার করে। সাধারণ জ্ঞান, যাদুকরী সুপারগ্লোবাল ব্যবহার নয়।

— ২১

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

— এরিক পেট্রোলেজে

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

— কাইল বাট

Answer 8

পোষ্ট কখন ব্যবহার করবেন, কখন জিইটি ব্যবহার করবেন এবং কখন কুকি ব্যবহার করবেন তা বোঝা গুরুত্বপূর্ণ। _RE _REQUEST দিয়ে আপনি যে মানটি দেখছেন সেগুলির মধ্যে যে কোনওটিই আসতে পারে। আপনি যদি কোনও পোষ্ট বা জিইটি বা কোনও কুকির কাছ থেকে মানটি পেতে চান, তবে আপনার কোডটি পড়ার কারও কাছে vari $QQUEST এর পরিবর্তে নির্দিষ্ট ভেরিয়েবলটি ব্যবহার করা আরও তথ্যবহুল।

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

Answer 9

কেবলমাত্র একবার ব্যবহার $_REQUESTকরা খারাপ ধারণা নয় এটি জিইটি এর সাথে।

• আপনি যদি এটি পোস্টের মানগুলি লোড করতে ব্যবহার করেন তবে আপনি ক্রস-সাইট অনুরোধ জালিয়াতি ঝুঁকিপূর্ণ
• আপনি যদি এটি কুকি মানগুলি লোড করতে ব্যবহার করেন তবে আপনি আবার ক্রস-সাইট অনুরোধ জালিয়াতি ঝুঁকিপূর্ণ

এমনকি জিইটি-র সাথেও $_GETটাইপ করার চেয়ে কম $_REQUEST;)

Comments

আমি যখন আপনার সাথে একমত হয়েছি $_POSTতখনও কেন এটি সত্য এবং / বা বিপজ্জনক তা নোট করা জরুরী মনে করি: ডেটা পোষ্টডাটা হওয়া জরুরী হওয়াতে একটি ব্যবহার করা উচিত । $_REQUESTডেটা যখন ব্যবহার করা এইচটিটিপি ভার্বের সাথে অজানা থাকে তখন ব্যবহার করা উচিত । এই সমস্ত ক্ষেত্রে সাবধানতার সাথে সমস্ত ইনপুট ডেটা স্যানিটাইজ করা উচিত।

— ডিসিলেজড

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

— ববিনস

জালিয়াতির জন্য জিইটি-কে অপব্যবহার করা অনেক সহজ। উদাহরণস্বরূপ, আপনি নিজের প্যারামিটারগুলির সাথে সিআরসি সেট করে কেবল ইমগ ট্যাগ রাখতে পারেন। এটি ব্যবহারকারী ছিল না জেনে এটি কাজ করবে।

— জানি হার্টিকাইনেন

Answer 10

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

Comments

তুমি কি বলতে চাচ্ছ? আপনি কি বিভ্রান্ত $_REQUESTকরছেন $_SERVER['QUERY_STRING']?

— হতাশ করেছেন

Answer 11

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

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

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

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

Answer 12

আমি মনে করি যে এতে কোনও সমস্যা নেই $_REQUEST, তবে এটি ব্যবহার করার সময় আমাদের অবশ্যই সতর্কতা অবলম্বন করা উচিত কারণ এটি 3 উত্স (জিপিসি) থেকে চলকগুলির সংগ্রহ।

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

// delete $_REQUEST when program execute, the program would be lighter 
// when large text submitted
unset($_REQUEST);

// wrapper function to get request var
function GetRequest($key, $default = null, $source = '') 
{
  if ($source == 'get') {
    if (isset($_GET[$key])) { 
      return $_GET[$key]; 
    } else { 
      return $default; 
    }
  } else if ($source == 'post') {
    if (isset($_POST[$key])) { 
      return $_POST[$key]; 
    } else { 
      return $default; 
    }
  } else if ($source == 'cookie') {
    if (isset($_COOKIE[$key])) { 
      return $_COOKIE[$key]; 
    } else { 
      return $default; 
    }
  } else {
    // no source specified, then find in GPC
    if (isset($_GET[$key])) {
      return $_GET[$key];     
    } else if (isset($_POST[$key])) {
      return $_POST[$key]; 
    } else if (isset($_COOKIE[$key])) {
      return $_COOKIE[$key]; 
    } else {
      return $default; 
    } 
  }
}

Answer 13

ড্যারেন কুক: "যেহেতু পিএইচপি ৫.৩ ডিফল্ট php.ini বলেছে যে কেবল জিইটি এবং পোষ্টের ডেটা রাখা হয়েছে $_REQUEST। পিএইচপি.এন.এইচ.এইচ.এস.আর_ দেখুন আমি যখন এই কুকি ডেটা রাখার প্রত্যাশা করছিলাম তখন কেন আমি এই পিছনে-সামঞ্জস্যতা বিরতিতে গিয়ে হোঁচট খেয়েছি$_REQUEST ? ' কাজ করছে না! "

বাহ ... পিএইচপি 5.3 এ আপগ্রেড হওয়ার কারণে আমার স্ক্রিপ্টগুলির কিছু কাজ বন্ধ করে দিয়েছে । একই জিনিসটি করেছেন: ধরে নিন যে $_REQUESTভেরিয়েবলটি ব্যবহার করার সময় কুকি সেট করা হবে । আপগ্রেডের সাথে ঠিক এটি কাজ করা বন্ধ করে দিয়েছে।

আমি এখন আলাদাভাবে কুকি মানগুলি কল করি $_COOKIE["Cookie_name"]...

Answer 14

কেন্দ্রীয় সমস্যাটি হ'ল এটিতে কুকি রয়েছে, যেমন অন্যরা বলেছেন।

পিএইচপি 7 এ আপনি এটি করতে পারেন:

$request = array_merge($_GET ?? [], $_POST ?? []);

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

Comments

যারা নিম্নে ভোটদান বেছে নিচ্ছেন, দয়া করে আমার সংশোধনের জন্য ব্যাখ্যা করুন।

— amh15

Answer 15

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

Comments

আপনি ব্রাউজারের ইউআরএল বারে কোনও POST অনুরোধ টাইপ করতে পারবেন না $ _POST এবং $ _GET এর মধ্যে সুরক্ষার মধ্যে কোনও পার্থক্য নেই। পোষ্টটি ব্যবহার করে একটি কমান্ড-লাইন সিআরএল অনুরোধটি বজায় রাখতে কেবল 5 সেকেন্ড সময় লাগে।

— জুমব্যাট

@ জোম্বাট: আমাদের জিইটি-র তুলনায় পোষ্ট সহজাতভাবে নিরাপদ বা এমনকি নিরাপদ নয় এমন লোকদের বোঝাতে এক ধরণের প্রচারণা শুরু করা দরকার। সুরক্ষা হ'ল আপনি কীভাবে ডেটা ট্রিট করেন তা নয় যে এইচটিটিপি ভার্বন এটি পেতে সেখানে ব্যবহৃত হয়েছিল।

— ছাড়লেন

@ ডিয়ারলিজেড - আমি নীচে "পরিবর্তন" শব্দটি সহ কিছুটা বজ্রপাতের বোল্টের সাথে মেঘের একটি আইকনিক দ্বৈত সুরের ছবিটি প্রস্তাব করছি।

— জুমব্যাট

@ গুয়াইট: এটি অত্যন্ত সংকীর্ণ দৃষ্টিভঙ্গি। এটি কেবল "নিরাপদ" কী তা নয়, তবে এটি কতটা গোপনীয়। GET প্যারামিটারগুলি ব্রাউজার ইউআরএল, এমনকি ব্রাউজারের ইতিহাসে স্বয়ংক্রিয়রূপ হিসাবে দেখাতে পারে। এছাড়াও, ব্রাউজার দিয়ে সুরক্ষা শেষ হয় না। উদাহরণস্বরূপ, অনেক সার্ভার লগ HTTP urls, তাই ইউআরএল মধ্যে কিছু লগ হবে, উদাহরণস্বরূপ। লগগুলিতে একটি ব্যবহারকারীর নাম / পাসওয়ার্ড থাকা কোনও পার্থক্য করে। নিরাপদ দিকে, সর্বদা সংবেদনশীল তথ্য GET পরামিতি হিসাবে পাস করা এড়াতে হবে।

— stan

বিশেষত অ্যাপাচি অ্যাক্সেস লগগুলি। যে কোনও অনুরোধ ইউআরএল লগ হবে এবং লগগুলিতে অ্যাক্সেস রয়েছে এমন যে কেউ আপনার শংসাপত্রগুলি দেখতে পাবে।

— stan