Mga garapon ng cookie ng PHP cURL para sa magkahiwalay na session ng user
Idisenyo ang pagpapanatili ng cookie ng PHP cURL sa paligid ng remote na session: mapagkakatiwalaang pangalan ng file, tahasang pag-save at magkasabay na kahilingan.
Isang aplikasyong PHP ang naglilingkod kina Alice at Bob, at parehong ginagamit ang client ng cURL sa panig ng server upang maabot ang parehong remote na website sa pamamagitan ng proxy. Kung bawat kahilingan ay naglo-load ng cookies.txt, maaaring mamanahin ng dalawang user ang parehong remote na pag-login. Ang pagpapalit ng kanilang mga address ng proxy ay hindi naghihiwalay sa file na iyon.
Piliin ang may-ari ng cookie bago piliin ang pangalan ng file. Karaniwan itong ang lohikal na remote na session ng aplikasyon: isang lokal na user, isang partikular na remote na account at, kung kailangan, isang hiwalay na workspace. Ang endpoint ng proxy ay isang pagpipilian sa routing, hindi isang maaasahang identifier ng session. Maraming user ang maaaring magbahagi ng isang endpoint, at ang endpoint ay maaaring magpalit ng mga labasan.
I-load at i-save ang garapon ng parehong session
Hayaang i-map ng aplikasyon ang authenticated na session nito sa isang file key na ginawa ng server. Sa isang pribadong direktoryo ng cookie at isang mapagkakatiwalaang $sessionKey, ganito ang hugis ng configuration ng 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,
]);
Para sa isang pinapayagang pagsubok ng session sa pampublikong site sa isang network na tumatanggap ng pampublikong tagapamagitan, ang listahan ng HTTP proxy ay nagbibigay ng mga kandidatong endpoint. Gumamit ng handle na walang naka-configure na authentication ng proxy o itinagong mga kredensyal ng proxy, at panatilihing nakatalaga ang estado ng cookie sa nilalayong session. Ang fragment na ito ay nag-configure ng handle; ang aplikasyon ang gumagawa ng transfer at sinusuri ang resulta sa normal nitong daloy ng kahilingan. Ang COOKIEFILE ay naglo-load ng mga naunang cookie ng session. Ang COOKIEJAR ay pumipili kung saan isinusulat ng handle ang mga itinagong cookie nito. Ang pagtatakda lamang ng output file ay hindi naglo-load ng naunang pag-login.
Ang bagong session ay maaaring magsimula nang walang file. Bigyan ang una nitong transfer ng nilalayong landas ng garapon, hayaang itatag ng website ang mga cookie, at i-save ang resultang estado para sa susunod na kahilingan. Ang direktoryo ng cookie ay dapat na maisusulat ng manggagawa ng aplikasyon at itago sa labas ng dokumentong punong inihahain sa publiko. Huwag gawing pangalan ng file ang username o landas na ibinigay ng bisita; hanapin ang mapagkakatiwalaang key sa server.
Ang pag-save ay nangangailangan ng lugar sa lifecycle ng kahilingan
Karaniwang isinusulat ng libcurl ang garapon habang naglilinis ng handle. Kung kailangan ng aplikasyon ng tahasang save point pagkatapos ng remote na palitan, maaari itong humiling:
curl_setopt($ch, CURLOPT_COOKIELIST, 'FLUSH');
Isinulat nito ang mga cookie na alam ng handle sa kasalukuyan sa naka-configure nitong garapon. Tapusin ang paggamit ng handle para sa session na iyon bago ito italaga sa walang kaugnayang gawain. Ang pagpapalit lamang ng landas ng garapon sa isang handle na mayroon nang mga cookie ni Alice ay hindi katumbas ng paggawa ng malinis na session ni Bob.
Iba-ibahin din ang matagumpay na pag-download sa matagumpay na pagpapanatili. Sinasabi ng dokumentasyon ng garapon ng cookie na ang pagkabigo sa pagsulat habang naglilinis ay hindi ibinabalik bilang ordinaryong error sa transfer. Suriin ang pagmamay-ari ng direktoryo, mga pahintulot at diagnostic na output ng aplikasyon kapag gumagana ang pag-login sa isang kahilingan at nawawala sa susunod.
Ang magkasabay na kahilingan ay nagdadala ng isa pang hangganan. Dalawang manggagawa ay maaaring mag-load ng parehong lumang garapon, malayang baguhin ang kanilang estado sa memorya, at pagkatapos ay mag-save ng magkaibang resulta. Kailangang saklawin ng lock kada session o katumbas na serialization ang buong pagkakasunod-sunod ng load, palitan at save kung parehong kahilingan ay nagbabahagi ng isang remote na pag-login; ang pag-lock lamang sa huling sulat ay hindi nagpapatugma sa kanilang mga naunang snapshot. Ang magkaibang session ay dapat may magkaibang file at malayang lock.
Sa pag-logout, tapusin ang nilalayong remote na session at ipagpaliban ang lokal nitong estado ng cookie ayon sa patakaran ng aplikasyon. Ang bagong piniling proxy ay maaaring ikabit sa anumang bagong session na sinimulan ng user, nang hindi ginagawang responsibilidad ng address ng proxy ang pagpapasya kung kanino ang pag-login sa memorya.