আমি সাধারণত এই তর্কটি ত্রুটি প্রতিরোধ করতে wp_remote_getএবং এর সাথে ব্যবহার করিwp_remote_post
array(
'sslverify' => false
)
সুরক্ষার কারণে আমি এটিকে সেট করতে চাই true(বা এটি পূর্বনির্ধারিত সত্য বলে মুছে ফেলা)।
এটা করে কি আমার কোনও সমস্যা আশা করা উচিত?
উত্তর:
টিএল; ডিআর: হ্যাঁ, ওয়ার্ডপ্রেস ৩.7 বা তার পরেও সেটিংটি সরান।
অতীতে, বহু লোক বিশেষত sslverify = মিথ্যা প্যারামিটার যুক্ত করেছিল কারণ তাদের পিএইচপি ইনস্টল করা শংসাপত্রটি সঠিকভাবে যাচাই করতে অক্ষম ছিল।
সাধারণত, এটি ছিল কারণ সিএ রুট শংসাপত্রগুলির সর্বশেষ কপি সহ পিএইচপি ইনস্টল আপডেট হয়নি। রুট শংসাপত্রগুলি প্রায়শই প্রায়শই পরিবর্তিত হয় এবং সাধারণত আপনি এই পরিবর্তনটি লক্ষ্য করেন না কারণ এটি সাধারণ ব্রাউজার আপডেটে ঘটে। ঠিক আছে, যখন আপনার পিএইচপি https ইউআরএলগুলি পুনরুদ্ধার করতে ব্রাউজারের মতো কাজ করে, তখন এটির জন্য এই রুট শংসাপত্রের আপডেটগুলিও দরকার। এবং বেশিরভাগ হোস্ট কখনও পিএইচপি আপডেট করে না, বা এর কোনও নির্দিষ্ট অংশ আপডেট করে না (শংসাপত্রের ফাইলের মতো)।
ওয়ার্ডপ্রেস 3.7 সংস্করণে অটো-আপডেটিং কার্যকর করেছে, তখন সুরক্ষিত যোগাযোগের প্রয়োজনে WordPress.org API গুলি আপগ্রেড করার প্রয়োজন হবে বলে দৃ .় সংকল্পবদ্ধ হয়েছিল। এই সময়ে, ওয়ার্ডপ্রেস নিজেই মোজিলা থেকে প্রাপ্ত সিএ রুট শংসাপত্রগুলির ফাইলের একটি অনুলিপি সহ শুরু করেছিল। ওয়ার্ডপ্রেস ৩.7 থেকে, তাই, ডাব্লুপিএইচটিটিপি এপিআই ফাংশনগুলি এই ফাইলটি শংসাপত্র যাচাই করতে ব্যবহার করে, এবং পুরানো বা পুরানো সংস্করণটি আপনার পিএইচপি ইনস্টলেশনের সাথে প্যাকেজযুক্ত নয়।
অতএব, হ্যাঁ, ওয়ার্ডপ্রেস ৩.7 বা তারপরের পরে, এস্লাইভারাইফাই প্যারামিটারটি সরিয়ে ফেলা এবং HTTP ফাংশনগুলিকে যথাযথ শংসাপত্র যাচাইয়ের অনুমতি দেওয়ার পরামর্শ দেওয়া হচ্ছে। পরিচিত সিএ এর একটিতে স্বাক্ষরিত কী সহ এসএসএল চালিত যে কোনও আধুনিক সার্ভার সঠিকভাবে যাচাই করা হবে। ডাব্লুপিএইচটিটিপিতে সর্বশেষতম শংসাপত্রগুলির একটি অনুলিপি থাকা উচিত এবং মূল প্রকল্পটি সাধারণ আপডেটের সাথে ওয়ার্ডপ্রেসে সেই শংসাপত্রগুলির ফাইল আপডেট করবে।
এমন অনেকগুলি কারণ রয়েছে যা একটি এসএসএল যাচাইকরণ ব্যর্থ হতে পারে। অনেকগুলি পুনর্নির্দেশ থেকে ভুল .iniফাইল / সেটআপগুলি শুরু করা বা কেবলমাত্র শংসাপত্র বা সাব ডোমেনগুলি অনুপস্থিত। যাইহোক, আপনাকে এর কারণ অনুসন্ধান করতে হবে এবং এটি ঠিক করতে হবে । এর আশেপাশে কোনও উপায় নেই ।
তবে সেই সমস্যাটি সাময়িকভাবে কাজ করার জন্য (আসুন আপনাকে ধরে নিন যে আপনার কোডটি আরও বিকাশ করা এবং পরে এসএসএল ত্রুটিটি পরে ঠিক করা দরকার), আপনি একটি ফিল্টার ব্যবহার করতে পারেন:
add_filter( 'https_ssl_verify', '__return_false' );আপনি যেমন রিমোট অনুরোধ চলাকালীন এটি চালাচ্ছেন, আপনার এটিকে এইচটিটিপি অনুরোধ চলাকালীন ট্রিগারযুক্ত ফিল্টারের সাথে সংযুক্ত একটি কলব্যাকে মুড়িয়ে ফেলা উচিত। আপনি সত্যিকারের ক্ষেত্রে সঠিক যাচাইকরণ অপসারণ করছেন কিনা তা নিশ্চিত করে দেখুন - এবং নিশ্চিত করুন যে আপনি অন্য অনুরোধগুলি সুরক্ষিত না করে কেবল একবার এটি চালিয়েছেন।
add_filter( 'http_request_args', function( $params, $url )
{
// find out if this is the request you are targeting and if not: abort
if ( 'foo' !== $params['foo'] )
return $params;
add_filter( 'https_ssl_verify', '__return_false' );
return $params;
}, 10, 2 );যদি এটি সর্বজনীনভাবে বিতরণ করা প্লাগইন হয়, তবে আপনি এটিকে কোনও সাধারণ বিকল্পের সাথে সংযুক্ত করতে চাইতে পারেন যা ব্যবহারকারী চালু বা বন্ধ করতে পারে। আপনি প্রথমে যাচাইকৃত অনুরোধটি চেষ্টা করে দেখতে পারেন এবং তা না হলে (এবং যদি ব্যবহারকারী স্বাক্ষরিত অনুরোধটি বেছে নিয়েছেন), তবে সম্ভাব্য অনিরাপদ অনুরোধে স্যুইচ করুন।
চলতি নিয়ম:
ডু আপনার ব্যবহারকারী এটি করতে সম্মত না হয়ে এবং ঝুঁকিগুলি সম্পর্কে অবগত না হওয়া পর্যন্ত কোনও অনিরাপদ অনুরোধ না ।
ওয়ার্ডপ্রেস নেটওয়ার্ক অনুরোধ সম্পাদন করতে অন্তর্নিহিত সার্ভার সফ্টওয়্যার (সাধারণত সিআরএল) উপর নির্ভর করতে পারে। সংক্ষেপে বলা যায় কারণ এটি সেই সফটওয়্যারটি ভাল এবং এর জন্য রয়েছে।
কিছু সার্ভারে বিভিন্ন কারণে (আমি নিজের দিকে তাকাতে কখনই বিরক্ত করিনি) সার্ভার সফ্টওয়্যারের পক্ষে নিরাপদ সংযোগগুলি "যাচাইকরণ" করতে সক্ষম না হওয়া, ত্রুটি তৈরি করে বলা বেশ সাধারণ।
তাই: