কোনও জিইটি অনুরোধ সার্ভারে ডেটা পরিবর্তন করা উচিত নয় কেন?

109

সমস্ত ইন্টারনেটে, আমি নিম্নলিখিত পরামর্শটি দেখতে পাচ্ছি:

জিইটি কখনই সার্ভারে ডেটা পরিবর্তন করতে পারে না - এর জন্য একটি পোষ্ট অনুরোধ ব্যবহার করুন

এই ধারণার ভিত্তি কী?

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

নাকি এর কোন historicতিহাসিক কারণ আছে? যদি তাই হয় তবে আজ এই পরামর্শটি কতটা বৈধ?

http http-request

— দেবদত্ত টেংশে
সূত্র

35

এখানে প্রাসঙ্গিক ডেইলিডব্লিউটিএফ প্রবেশ রয়েছে ।

— জোচিম সৌর 15

3

কমান্ড / কোয়েরি বিচ্ছেদ।

— ম্যাসন হুইলারের 18

এই প্রশ্নটি জিজ্ঞাসা করার জন্য আপনাকে ধন্যবাদ, এবং আপনাকে ধন্যবাদ ধন্যবাদ ভাল উত্তর দেওয়ার জন্য আমার এই প্রশ্নটি জিজ্ঞাসা করা লোকদের পাঠানোর জন্য আমার সবসময় একটি রেফারেন্সের দরকার ছিল :)

— বেনজামিন গ্রুইনবাউম

এছাড়াও এইচটিটিপি পুট দেখুন - stackoverflow.com/questions/630453/put-vs-post-in-rest ( আদর্শবান হিসাবে নোট সহ)

— ব্রাচ

2

@ জোয়াচিমসৌয়ার জিইটি তাদের ক্রলার থেকে বাঁচাতে পারত, তবে মূল সমস্যা ছিল প্রমাণীকরণের অভাব। যে কোনও স্ক্রিপ্ট কিডি তাদের পাশাপাশি বিস্মৃত হতে পারে।

— কোডসইনচওস

185

এটি পরামর্শ নয়।

একজন GETএই ভাবে সংজ্ঞায়িত করা হয় HTTP প্রোটোকলের । এটি আদর্শবান এবং নিরাপদ বলে মনে করা হচ্ছে ।

কেন হিসাবে - একটি GETক্যাশে এবং একটি ব্রাউজারে সতেজ করা যেতে পারে। আবার, আবার, আবার।

এর মানে হল যে আপনি যদি একই করতে GETআবার, আপনি আপনার ডাটাবেস মধ্যে সন্নিবেশ হবে আবার ।

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

আমি ইউআরআই, ঠিকানাযোগ্যতা এবং এইচটিটিপি জিইটি এবং পোস্ট ব্যবহার করার পরামর্শও দিচ্ছি ।

কিছু ব্রাউজারে লিঙ্ক প্রিফেচিংয়ের ক্ষেত্রেও সমস্যা রয়েছে - তারা পৃষ্ঠার লেখক দ্বারা নির্দেশিত না হলেও, প্রাক লিঙ্কগুলি লিঙ্কে কল করবে।

যদি বলুন, আপনার লগ আউটটি "জিইটি" এর পিছনে রয়েছে, আপনার সাইটের প্রতিটি পৃষ্ঠা থেকে লিঙ্ক করা হয়েছে, লোকেরা কেবল এই আচরণের কারণে লগ আউট করতে পারে।

— ওবেদের
সূত্র

35

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

— জোচিম সউর 12

7

@ নিমচিম্পস্কি: এটি এ দ্বারা পরিবর্তিত হয় GET। সেই পরামর্শটি কেবল ভুল। নিরাপদ মানে ব্যবহারকারীকে পার্শ্ব-প্রতিক্রিয়াগুলির জন্য দায়বদ্ধ রাখা যায় না, পার্শ্ব প্রতিক্রিয়া হতে পারে না তা নয়। অন্যথায় আপনার সার্ভারের জন্য লগ ফাইলগুলি থাকতে পারত না, যা অযৌক্তিক হবে! এটি আরএফসি 2616 এর 9.1.1 বিভাগে বেশ স্পষ্টভাবে বর্ণিত।

— Jörg ডব্লু মিটাগ

8

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

— জোছিম সৌর

23

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

— এরিক কিং

8

বেশ কয়েক বছর আগে, গুগল একটি ব্রাউজার অ্যাড-অন (iirc) প্রকাশ করেছে যা লিঙ্কগুলির মাধ্যমে পৃষ্ঠাগুলি প্রাক-আনতে পারে। এটি এমন কিছু নিয়ন্ত্রণ প্যানেলে ঘটেছিল যা খারাপভাবে ডিজাইন করা হয়েছিল - ইউআরএলগুলির ফলে সার্ভারে একটি রেকর্ড বা কিছু লেখা বা এমনকি মুছে ফেলা হতে পারে (মনে হয় পোস্ট? ক্রিয়া = মুছুন)। এটি ব্যবহারকারীকে না জেনে কর্ম সম্পাদন করে caused গুগল সেই কারণেই এই অ্যাডন বন্ধ করে দিয়েছে, আইআরসিপি, এমনকি যদি জিইটিগুলি রাষ্ট্র পরিবর্তন করতে ব্যবহার করার জন্য ওয়েবপ্যাপ প্রস্তুতকারকের দোষ ছিল।

— চথুলহু

24

প্রতিটি HTTP ক্রিয়াটির নিজস্ব দায়বদ্ধতা রয়েছে। উদাহরণস্বরূপ GET, আরএফসি দ্বারা নির্ধারিত হিসাবে

মানে অনুরোধ-ইউআরআই দ্বারা চিহ্নিত যে কোনও তথ্য (সত্তার আকারে) সনাক্ত করা।

POSTঅন্যদিকে, মানে meansোকানো বা আরও আনুষ্ঠানিকভাবে

POST পদ্ধতিটি অনুরোধ-লাইনে অনুরোধ-ইউআরআই দ্বারা চিহ্নিত
রিসোর্সের নতুন অধীনস্থ হিসাবে অনুরোধে অন্তর্ভুক্ত থাকা সত্তাকে গ্রহণ করার অনুরোধের জন্য উত্স সার্ভারটি অনুরোধ করতে ব্যবহৃত হয়

এটি এভাবে রাখার কারণগুলি:

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

সম্পূর্ণতার জন্য এবং কেবল সঠিক ব্যবহার (উত্স) প্রয়োগ করতে :

GETপ্যারামিটারগুলি ইউআরএলের অংশ হিসাবে পাস করা হয়, যা ডিফল্টরূপে 256 অক্ষরের ছোট এবং সীমাবদ্ধ দৈর্ঘ্যের, কিছু সার্ভার 4000+ অক্ষর সমর্থন করে। আপনি যদি একটি দীর্ঘ রেকর্ড সন্নিবেশ করতে চান তবে এই ডেটাটি পাস করার কোনও বৈধ উপায় নেই
যখন ব্যবহার করে সুরক্ষিত সংযোগ, ̶ যেমন TLS, ̶ URL হল না পেয়ে এনক্রিপ্ট, ̶ অত: পর সব The প্যারামিটার ̶ ̶G̶E̶T̶̶ স্থানান্তরিত প্লেইন টেক্সট। ইউআরএল টিএলএস সহ সত্যই এনক্রিপ্ট করা আছে, তাই টিএলএস ঠিক আছে।
ব্যবহার করে বাইনারি ডেটা বা অ-এসসিআইআই অক্ষর সন্নিবেশ করানো GETঅবৈধ
GET যদি ব্যবহারকারী কোনও ব্রাউজারে একটি পিছনে বোতাম টিপায় তবে তা কার্যকর করা হয়
কিছু পুরানো ক্রোলার ?ভিতরে কোনও সাইন সহ ইউআরএল সূচক নাও করতে পারে

— oleksii
সূত্র

1

আপনি কি নিশ্চিত যে টিআরএলএসের মাধ্যমে ইউআরএল এনক্রিপ্ট করা নেই? আমি ছাপে ছিলাম যে এইচটিটিপি হেডারগুলি স্থানান্তরিত হওয়ার আগে এসএসএল / টিএলএস হ্যান্ডশেকগুলি ঘটে। এই কারণেই কোনও আইপি ঠিকানার মাধ্যমে ভার্চুয়াল হোস্টিং এইচটিটিপিএস সাইটগুলি কঠিন। আমি কি ভুল করছি?

— ব্র্যান্ডন

ঠিক আছে, আমি এটি ঠিক করেছি

— ওলেক্সি

2

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

— কোডসইনচাউস ২১:৪১

9

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

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

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

— শেরেল বোথা
সূত্র

1

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

— কোডসইনচাউস

8

যদি আমি এমন কোনও পিএইচপি পরিষেবা করি যা ডেটাবেজে ডেটা সন্নিবেশ করে এবং এটি জিইটি কোয়েরি স্ট্রিংয়ে প্যারামিটারগুলি দিয়ে যায় তবে কেন এটি ভুল?

সবচেয়ে সহজ উত্তর "কারণ এটি এর GETঅর্থ নয় " "

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

— নাথান লম্বা
সূত্র

5

ডাটাবেস কেন্দ্রিক অ্যাপ্লিকেশনটিতে আপনার সিআরইউডি অপারেশনের জন্য নিম্নলিখিত স্কিমা ব্যবহার করুন:

রিড অপারেশনগুলির জন্য HTTP জিইটি ব্যবহার করুন (এসকিউএল নির্বাচন করুন)

আপডেট অপারেশনগুলির জন্য HTTP পুট ব্যবহার করুন (এসকিউএল আপডেট)

অপারেশনস (এসকিউএল ইনসার্ট) তৈরি করার জন্য এইচটিটিপি পোস্ট ব্যবহার করুন

মুছে ফেলা অপারেশনগুলির জন্য HTTP মোছা ব্যবহার করুন (এসকিউএল মোছা)

3

পুট বনাম পোস্ট আপনার রাজ্যের মতো নয়। পুট যখন নির্দিষ্ট ক্লায়েন্টটি সঠিক স্থানে সংস্থানটি সংশোধন করে তখন জন্য হয়। কোনও পোস্টের জন্য সার্ভার শেষ পর্যন্ত সংস্থানটিকে সঠিকভাবে সংস্থান করে।

— অ্যান্ডি

এইচটিটিপি পুট কি আপডেটের চেয়ে এসকিউএল ডিলিট এবং ইনসার্টের মতো নয়? এছাড়াও এসকিউএল আপডেট আপডেট একবারে অনেকগুলি রেকর্ড আপডেট করতে পারে তবে HTTP PUT কেবল একটি জিনিস আপডেট করবে।

— পিছনে_ডভ

0

জিইটি কখনই সার্ভারে ডেটা পরিবর্তন করতে পারে না - এর জন্য একটি পোষ্ট অনুরোধ ব্যবহার করুন

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

একটি জিইটি- এর সার্ভারে খুব কমই ডেটা পরিবর্তন করা উচিত - এর জন্য একটি পোষ্ট অনুরোধ ব্যবহার করুন

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

এটি স্পষ্টতই একটি প্রান্তের মামলা, তবে অবশ্যই লক্ষণীয়।

— ttt
সূত্র

3

যদি আপনার মেইলক্লিয়েন্ট আপনি ক্লিক না করেই লিঙ্কটি আনার সিদ্ধান্ত নেন? উদাহরণস্বরূপ কারণ এটি ম্যালওয়ারের জন্য এটি স্ক্যান করতে চায়। সাবস্ক্রাইব লিঙ্কগুলির জন্য সঠিক পদ্ধতির হ'ল এমন একটি পৃষ্ঠায় নিয়ে যাওয়া যেখানে ব্যবহারকারী সাবস্ক্রাইব করতে একটি বোতামে ক্লিক করতে পারে (যেখানে বোতাম ক্লিকটি একটি পোস্টের অনুরোধকে ট্রিগার করে)।

— কোডসইনচাউস

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

— টিটিটি

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

— কোডসইনচাউস

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

— টিটিটি