الگ صارف سیشنز کے لیے PHP cURL کوکی جارز
ریموٹ سیشن کے گرد PHP cURL کوکی برقرار رکھنے کا ڈیزائن: قابلِ اعتماد فائل نام، واضح محفوظ کاری اور بیک وقت درخواستیں۔
ایک PHP ایپلیکیشن Alice اور Bob کی خدمت کرتی ہے، اور دونوں پروکسی کے ذریعے اسی ریموٹ ویب سائٹ تک پہنچنے کے لیے اس کے سرور سائیڈ cURL کلائنٹ کا استعمال کرتے ہیں۔ اگر ہر درخواست cookies.txt لوڈ کرے، تو دونوں صارفین ایک ہی ریموٹ لاگ اِن وراثت میں لے سکتے ہیں۔ ان کے پروکسی پتے بدلنے سے وہ فائل الگ نہیں ہوتی۔
فائل کا نام چننے سے پہلے کوکی کا مالک چنیں۔ عام طور پر یہ ایپلیکیشن کا منطقی ریموٹ سیشن ہوتا ہے: کوئی مقامی صارف، کوئی مخصوص ریموٹ اکاؤنٹ اور ضرورت پڑنے پر الگ ورک اسپیس۔ پروکسی اینڈ پوائنٹ راستے کا انتخاب ہے، قابلِ اعتماد سیشن شناخت نہیں۔ کئی صارفین ایک اینڈ پوائنٹ شیئر کر سکتے ہیں، اور اینڈ پوائنٹ خارجی راستے بدل سکتا ہے۔
اسی سیشن کا جار لوڈ اور محفوظ کریں
ایپلیکیشن اپنے تصدیق شدہ سیشن کو سرور کے بنائے ہوئے فائل کی سے منسلک کرے۔ نجی کوکی ڈائریکٹری اور قابلِ اعتماد $sessionKey کے ساتھ، cURL کنفیگریشن کی یہ شکل ہوتی ہے:
$jar = $cookieDirectory . '/' . $sessionKey . '.cookies';
$ch = curl_init('https://service.example.net/account');
curl_setopt_array($ch, [
CURLOPT_PROXY => 'http://proxy.example.net:8080',
CURLOPT_RETURNTRANSFER => true,
CURLOPT_COOKIEFILE => $jar,
CURLOPT_COOKIEJAR => $jar,
]);
عوامی ثالث کی اجازت دینے والے نیٹ ورک پر اجازت یافتہ عوامی سائٹ سیشن ٹیسٹ کے لیے، HTTP پروکسی فہرست امیدوار اینڈ پوائنٹس فراہم کرتی ہے۔ ایسا ہینڈل استعمال کریں جس میں کنفیگر شدہ پروکسی تصدیق یا محفوظ شدہ پروکسی اسناد نہ ہوں، اور کوکی کی حالت کو اس کے مطلوبہ سیشن کے لیے مختص رکھیں۔ یہ ٹکڑا ایک ہینڈل کنفیگر کرتا ہے؛ ایپلیکیشن منتقلی کرتی ہے اور اپنے معمول کے درخواست بہاؤ سے نتیجہ جانچتی ہے۔ COOKIEFILE سیشن کی پچھلی کوکیز لوڈ کرتا ہے۔ COOKIEJAR منتخب کرتا ہے کہ ہینڈل اپنی محفوظ کوکیز کہاں لکھے۔ صرف آؤٹ پٹ فائل مقرر کرنے سے پچھلا لاگ اِن لوڈ نہیں ہوتا۔
نیا سیشن فائل کے بغیر شروع ہو سکتا ہے۔ اس کی پہلی منتقلی کو مطلوبہ جار راستہ دیں، ویب سائٹ کو کوکیز قائم کرنے دیں، اور اگلی درخواست کے لیے نتیجے کی حالت محفوظ کریں۔ کوکی ڈائریکٹری ایپلیکیشن کے ورکر کے لیے قابلِ تحریر ہونی چاہیے اور عوامی طور پر پیش کیے جانے والے دستاویزی درخت سے باہر رکھنی چاہیے۔ مہمان کا دیا ہوا صارف نام یا راستہ فائل کا نام نہ بنائیں؛ سرور پر قابلِ اعتماد کی تلاش کریں۔
محفوظ کاری کو درخواست کے زندگی چکر میں جگہ چاہیے
libcurl عام طور پر ہینڈل کی صفائی کے دوران جار لکھتا ہے۔ اگر ایپلیکیشن کو ریموٹ تبادلے کے بعد واضح محفوظ کاری کا مقام چاہیے، تو وہ درخواست کر سکتی ہے:
curl_setopt($ch, CURLOPT_COOKIELIST, 'FLUSH');
یہ ہینڈل کی موجودہ معلوم کوکیز کو اس کے کنفیگر شدہ جار میں لکھتا ہے۔ اس سیشن کے لیے ہینڈل کا استعمال ختم کریں، پھر اسے غیر متعلق کام کے لیے مختص کریں۔ ایسے ہینڈل پر صرف جار کا راستہ بدلنا جو پہلے ہی Alice کی کوکیز رکھتا ہے، Bob کا صاف سیشن بنانے کے برابر نہیں۔
کامیاب ڈاؤن لوڈ اور کامیاب برقراری میں بھی فرق کریں۔ کوکی جار کی دستاویزات بتاتی ہیں کہ صفائی کے دوران تحریر کی ناکامی عام منتقلی خرابی کے طور پر واپس نہیں کی جاتی۔ جب لاگ اِن ایک درخواست کے لیے کام کرے اور اگلی میں غائب ہو جائے، تو ڈائریکٹری کی ملکیت، اجازتیں اور ایپلیکیشن کی تشخیصی آؤٹ پٹ جانچیں۔
بیک وقت درخواستیں ایک اور حد لاتی ہیں۔ دو ورکر ایک ہی پرانا جار لوڈ کر سکتے ہیں، آزادانہ طور پر اپنی میموری حالت بدل سکتے ہیں، اور پھر مختلف نتائج محفوظ کر سکتے ہیں۔ اگر دونوں درخواستیں ایک ہی ریموٹ لاگ اِن شیئر کرتی ہیں تو فی سیشن لاک یا مساوی ترتیب پوری لوڈ، تبادلہ اور محفوظ کاری کی ترتیب کو ڈھانپنا چاہیے؛ صرف آخری تحریر کو مقفل کرنا ان کے پچھلے اسنیپ شاٹس کو ہم آہنگ نہیں کرتا۔ مختلف سیشنز کے مختلف فائلز اور آزاد لاک ہونے چاہئیں۔
لاگ آؤٹ پر، مطلوبہ ریموٹ سیشن ختم کریں اور ایپلیکیشن کی پالیسی کے مطابق اس کی مقامی کوکی حالت ریٹائر کریں۔ نئے منتخب کردہ پروکسی کو پھر صارف کے شروع کردہ کسی بھی نئے سیشن سے منسلک کیا جا سکتا ہے، بغیر پروکسی پتے کو یہ فیصلہ کرنے کا ذمہ دار بنائے کہ میموری میں کس کا لاگ اِن ہے۔