WordPress اپنی ہی سائٹ کو پراکسی سے باہر رکھتا ہے

WP_PROXY_HOST اور WP_PROXY_PORT مقرر ہیں۔ بیرونی API کی طرف درخواست پراکسی استعمال کرتی ہے، لیکن WordPress کے اپنے ہوسٹ نام کی طرف واپس جانے والی درخواست نہیں کرتی۔ یہ HTTP API کی مقصود بائی پاس پالیسی ہو سکتی ہے۔

WP_HTTP_Proxy فیصلہ کرتا ہے کہ کوئی مخصوص URI پراکسی سے گزرنا چاہیے یا نہیں۔ اس کی طے شدہ منطق localhost اور سائٹ کے ترتیب شدہ siteurl سے حاصل ہونے والے ہوسٹ نام کو بائی پاس کرتی ہے۔ یہ محض یہ فیصلہ کرنے سے الگ ہے کہ پراکسی مستقل موجود ہیں یا نہیں۔

وہ URL دیکھیں جس کا WordPress نے جائزہ لیا

درخواست کردہ ہوسٹ نام، ترتیب شدہ سائٹ URL اور WP_PROXY_BYPASS_HOSTS کو اکٹھا رکھیں۔ عوامی ہوسٹ نام کی طرف درخواست اور اندرونی عرف کی طرف درخواست مختلف فیصلے کر سکتی ہیں، چاہے دونوں ایک ہی ایپلیکیشن تک پہنچیں۔

WP_PROXY_BYPASS_HOSTS ترتیب شدہ ہوسٹ استثناؤں کی فہرست شامل کرتا ہے۔ یہ دور دراز پراکسی کی اجازت کردہ منزلوں کا مجموعہ نہیں ہے، اور یہ بصورت دیگر مسدود بیرونی درخواست کو جائز نہیں بناتا۔

طے شدہ خود سائٹ استثنا مفید ہو سکتا ہے: یہ مقامی لوپ بیک قسم کی ایپلیکیشن درخواست کو کسی واسطے کی طرف لے جانے سے بچاتا ہے۔ لیکن ایسی تنصیب جس میں عوامی سائٹ ہوسٹ نام صرف کسی مخصوص منظور شدہ راستے سے پہنچا جا سکتا ہے، کو مختلف سوچا سمجھا فیصلہ درکار ہو سکتا ہے۔

معاون ہک پر فیصلہ بدلیں

pre_http_send_through_proxy فلٹر فی URI فیصلے کو اوور رائیڈ کر سکتا ہے۔ کسی بھی اوور رائیڈ کو تنگ رکھیں اور اسے اس ہوسٹ یا شرط سے ملا دیں جسے اسے سنبھالنا ہے۔ ہر URI کے لیے ایک مقررہ جواب واپس کرنا پوری HTTP API کی پالیسی بدل دیتا ہے۔

منتخب شدہ ترسیل کا بھی جائزہ لیں۔ الگ SDK یا خام PHP نیٹ ورکنگ فنکشن کو کال کرنے والا کوڈ خود بخود WordPress کے HTTP API اور اس کے فلٹر کا استعمال نہیں کرتا۔

اس راستے کی تشخیص کرتے وقت، مکمل درخواست دلائل کو عوامی طور پر پھیلائے بغیر بائی پاس فیصلہ ریکارڈ کریں۔ ان میں کوکیز، اکاؤنٹ کی معلومات اور پراکسی راز ہو سکتے ہیں۔ مماثل درخواست کے بغیر پراکسی لاگ بائی پاس سے مطابقت رکھتا ہے، لیکن کبھی نہ کی گئی درخواست سے اسے الگ کرنے کے لیے اکیلے کافی نہیں۔