বেলেগ বেলেগ user session-ৰ বাবে PHP cURL cookie jar
PHP cURL cookie persistence-ক remote session-ৰ চাৰিওফালে ডিজাইন কৰা, trusted file name, explicit save আৰু concurrent request সহ।
এটা PHP application-এ Alice আৰু Bob-ক সেৱা আগবঢ়ায়, আৰু দুয়ো ইয়াৰ server-side cURL client ব্যৱহাৰ কৰি proxy ৰ জৰিয়তে একে remote website-ত উপনীত হয়। যদি প্ৰতিটো requestে cookies.txt load কৰে, তেন্তে দুয়োজন userে একে remote login উত্তৰাধিকাৰ কৰিব পাৰে। সিহঁতৰ proxy address সলনি কৰিলেও সেই file পৃথক নহয়।
file name বাছনি কৰাৰ আগতে cookie ৰ গৰাকী বাছনি কৰক। সাধাৰণতে ই application-ৰ logical remote session: এজন local user, এটা নিৰ্দিষ্ট remote account আৰু প্ৰয়োজনত এটা পৃথক workspace। proxy endpoint এটা routing বাছনি, বিশ্বাসযোগ্য session identifier নহয়। কেইবাজনো userে এটা endpoint share কৰিব পাৰে, আৰু এটা endpointে exit rotate কৰিব পাৰে।
একে session-ৰ jar load আৰু save কৰক
application-এ তাৰ authenticated session-ক server-এ সৃষ্টি কৰা file key-লৈ map কৰিবলৈ দিয়ক। এটা private cookie directory আৰু বিশ্বাসযোগ্য $sessionKey ৰ সৈতে, cURL configuration এ এই ৰূপ লয়:
$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,
]);
public intermediary অনুমোদন কৰা network-ত অনুমোদিত public-site session test ৰ বাবে, HTTP proxy list-এ candidate endpoint যোগান ধৰে। configured proxy authentication বা সংৰক্ষিত proxy credential নথকা handle ব্যৱহাৰ কৰক, আৰু cookie state ইয়াৰ উদ্দেশ্যিত session-লৈ নিৰ্ধাৰিত ৰাখক। এই fragment এ এটা handle configure কৰে; application-এ transfer সম্পন্ন কৰে আৰু স্বাভাৱিক request flow ৰ জৰিয়তে ফলাফল পৰীক্ষা কৰে। COOKIEFILE এ session-ৰ আগৰ cookie load কৰে। COOKIEJAR এ নিৰ্বাচন কৰে handle-এ তাৰ সংৰক্ষিত cookie ক'ত লিখিব। কেৱল output file নিৰ্ধাৰণ কৰিলে আগৰ login load নহয়।
এটা নতুন session file নোহোৱাকৈ আৰম্ভ হ'ব পাৰে। তাৰ প্ৰথম transfer-ক উদ্দেশ্যিত jar path দিয়ক, website-ক cookie প্ৰতিষ্ঠা কৰিবলৈ দিয়ক, আৰু পৰৱৰ্তী request ৰ বাবে ফলস্বৰূপ state save কৰক। cookie directory application-ৰ worker-এ লিখিব পৰা হ'ব লাগিব আৰু public-ভাৱে served document tree ৰ বাহিৰত ৰাখিব লাগিব। visitor-এ যোগান ধৰা username বা path-ক file name-লৈ নপৰিণত কৰিব; server-ত বিশ্বাসযোগ্য key বিচাৰি উলিয়াওক।
save কৰিবলৈ request lifecycle-ত ঠাই লাগে
libcurl এ সাধাৰণতে handle cleanup ৰ সময়ত jar লিখে। যদি application-এ remote exchange ৰ পিছত explicit save point লাগে, ই অনুৰোধ কৰিব পাৰে:
curl_setopt($ch, CURLOPT_COOKIELIST, 'FLUSH');
ই handle-এ বৰ্তমানে জনা cookie ক তাৰ configured jar-লৈ লিখে। সেই session ৰ বাবে handle ব্যৱহাৰ কৰি শেষ কৰক, তাৰ পিছত ইয়াক অসম্পৰ্কিত কামত নিয়োগ কৰক। যি handle-এ ইতিমধ্যে Alice ৰ cookie ধৰি ৰাখিছে তাত কেৱল jar pathname সলনি কৰা Bob ৰ পৰিষ্কাৰ session সৃষ্টি কৰাৰ সমতুল্য নহয়।
সফল download আৰু সফল persistence-কো পৃথক কৰক। cookie-jar documentation-এ উল্লেখ কৰে যে cleanup ৰ সময়ত write failure সাধাৰণ transfer error হিচাপে ঘূৰাই নিদিয়ে। যেতিয়া এটা request ৰ বাবে login কাম কৰে আৰু পৰৱৰ্তীটোত নোহোৱা হয়, তেতিয়া directory ownership, permission আৰু application-ৰ diagnostic output পৰীক্ষা কৰক।
concurrent request-এ আন এটা সীমা আনে। দুজন workerে একে পুৰণি jar load কৰিব পাৰে, স্বতন্ত্ৰভাৱে সিহঁতৰ in-memory state সলনি কৰিব পাৰে, আৰু তাৰ পিছত ভিন্ন ফলাফল save কৰিব পাৰে। যদি দুয়োটা requestে এটা remote login share কৰে, তেন্তে per-session lock বা সমতুল্য serialization-এ গোটেই load, exchange আৰু save ক্ৰমটো সামৰি ল'ব লাগিব; কেৱল শেষৰ write lock কৰিলে সিহঁতৰ আগৰ snapshot মিলাই নিদিয়ে। ভিন্ন session-ৰ ভিন্ন file আৰু স্বতন্ত্ৰ lock থাকিব লাগিব।
logout ৰ সময়ত, উদ্দেশ্যিত remote session শেষ কৰক আৰু application-ৰ policy অনুসৰি তাৰ local cookie state অৱসৰ কৰাওক। তাৰ পিছত নতুনকৈ বাছনি কৰা proxy ক user-এ আৰম্ভ কৰা যিকোনো নতুন session-ৰ সৈতে সংযুক্ত কৰিব পাৰি, proxy address-ক memory-ত কোনৰ login আছে তাক নিৰ্ণয় কৰাৰ দায়িত্ব নিদিয়াকৈ।