嘗試使用cURL避免ASP.NET會話

我正在使用來自提供者的網絡服務，該提供者正在對進行太有助於預測我的需求。他們給了我一個HTML片段來粘貼在我的網站上，供用戶點擊觸發他們的服務。我寧願編寫這個過程的腳本，所以我有一個php腳本，將cURL請求發佈到相同的URL，如適用。但是，此提供程序正在查看我的會話，並將每個新請求解釋爲第一個請求的更新，而不是每個都是唯一的請求。嘗試使用cURL避免ASP.NET會話

關於我的問題，我已經聯繫了提供商，他們竟然告訴我他們的系統按預期工作，並且我不可能避免每個人都使用相同的ASP.NET會話隨後的cURL請求。雖然我最喜歡的選擇是切換到不同的供應商，但目前看來這不是一種選擇。有沒有一種可靠的方式來獲得每個cURL請求的新ASP.NET會話？

我嘗試了以下一組CURLOPT的的，都無濟於事：

//initialize curl 
$ch = curl_init($url); 

//build a string out of the post_vars 
$post_str = http_build_query($post_vars); 

//set the necessary curl options 
curl_setopt($ch, CURLOPT_TIMEOUT, 30); 
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); 
curl_setopt($ch, CURLOPT_FAILONERROR, 1); 
curl_setopt($ch, CURLOPT_POST, 1); 
curl_setopt($ch, CURLOPT_POSTFIELDS, $post_str); 
curl_setopt($ch, CURLOPT_FAILONERROR, 1); 
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1); 
curl_setopt($ch, CURLOPT_COOKIESESSION, 1); 
curl_setopt($ch, CURLOPT_FRESH_CONNECT, 1); 
curl_setopt($ch, CURLOPT_FORBID_REUSE, 1); 
curl_setopt($ch, CURLOPT_USERAGENT, "UZ_".uniqid()); 
curl_setopt($ch, CURLOPT_REFERER, CURRENT_SITE_URL."index.php?newsession=".uniqid()); 
curl_setopt($ch, CURLOPT_HTTPHEADER, array("Pragma: no-cache", "Cache-Control: no-cache")); 

//execute the call to the backend script, retrieve the results 
$xmlstr = curl_exec($ch);

來源

2010-08-19 Andrew Rueckert

您是否嘗試過手動將'CURLOPT_COOKIE'設置爲空字符串？或者可能指定'CURLOPT_COOKIEFILE'和'CURLOPT_COOKIEJAR'，並在請求之間解除文件鏈接？ – grossvogel 2010-08-29 16:03:09

好給您正在使用的選項，看來你已經把你的基礎知識。你能找出他們的會話是如何設置的嗎？

如果你知道他們如何設置會話，IE使用什麼（如果它是IP或什麼），然後你可以找出解決辦法。另一個選項是嘗試將Cookie設置爲不同的Cookie文件：

CURLOPT_COOKIEFILE - 包含cookie數據的文件的名稱。 cookie文件可以是Netscape格式，也可以是簡單的HTTP風格的頭文件轉儲到文件中。

但是，如果他們所做的只是檢查Cookie，您當前的代碼應該可以工作。如果你能弄清楚cookie的名字是什麼，你可以傳遞一個空白的自定義cookie，看看是否有效。但是，如果你能從他們那裏獲得關於他們會話工作方式的信息，那最好。

來源

2010-08-19 21:13:07

使用這兩個行處理會話：

curl_setopt($ch, CURLOPT_COOKIEJAR, "path/to/cookies.txt"); // cookies.txt should be writable 
curl_setopt($ch, CURLOPT_COOKIEFILE, "path/to/cookies.txt");

來源

2010-08-29 06:56:07

普通Asp.net會議是由一種叫做ASP.NET_SessionId的cookie跟蹤。這個cookie是在對第一個請求的響應中發送的。所以只要你的curl請求不發回這個asp.net cookie，你的每一個請求都不會互相連接。使用curl -c選項可查看您和他們之間正在飛行的餅乾。如果您確認這裏使用的是正常的asp.net會話，則應使用cookie文件覆蓋此cookie。

對於使用會話的服務來說很差（http有更多清潔的方式來維護ReST利用的狀態），所以我不會完全排除供應商切換選項。

來源

2010-08-29 07:35:37 llevera

檢查完我的cookies後，似乎我從一開始就正確地做了所有事情。我每次都收到不同的ASP.NET_SessionId。我正在推銷供應商開關。這些人是合作的噩夢。 – 2010-09-01 16:50:02

如果cURL幫助不大，爲什麼不嘗試其他方法來調用腳本中的服務，如php的file()函數或file_get_contents()。

如果您看不到任何區別，那麼服務提供商可能會使用您的IP來跟蹤您的請求。嘗試使用一些代理進行測試。

來源

2010-08-31 12:53:43 Samnan

經過進一步測試，似乎他們實際上並未使用ASP_NET的會話，這很奇怪，因爲我也相當肯定他們沒有使用我的IP。如果我將GET參數輸入到Chrome瀏覽器和Chrome（隱私模式）瀏覽器的地址欄中，它會給我兩個不同的會話。如果我在瀏覽器中輸入GET參數，請清除所有Cookie和緩存文件，然後在同一瀏覽器中再次輸入它們，我的會話仍然存在。我不知道他們是如何管理這個技巧的...... – 2010-09-01 16:53:23

我想這看起來是基於get參數和瀏覽器標識字符串來創建會話。這就是爲什麼它可能在不同瀏覽器的相同參數上創建不同的會話。你可以嘗試使用命令行curl來模擬這種行爲並找出是否是這種情況。 – Samnan 2010-09-09 08:12:23

嘗試使用cURL避免ASP.NET會話

回答

相關問題