2013-01-31 61 views
9

我遇到了跨域AJAX請求的問題。

三臺服務器都參與了這一問題。我們可以稱它們爲A1,A2B

A1A2運行相同的應用程序代碼。它們是同一個Web應用程序的兩個分段實例。 B是另一個Web應用程序。

我們需要執行從 web應用到應用跨域AJAX請求。我們嘗試啓用CORS,但在IE < = 8中難以令人滿意地工作,所以現在我們使用的是nginx代理規則。因此,該流程是:瀏覽器AJAX請求 - >A1A2 - > nginx的代理 - >

是有狀態的,並且需要用戶的會話cookie起作用。

我們所看到的是,這個使用服務器當A1,但使用服務器A2不能拔出cookie時工作正常。

我已經看過來自A1A2的請求的標題,它們是相同的。兩人都在標題中的Cookie線,都具有相同的起源等

我們看到的是,$ _COOKIE [「session_key可以」]是空當請求來自A2但正確填寫當請求來自A1

奇怪的是,它只是缺少從頭中的cookie中提取一個特定的Cookie密鑰,並且只有當請求來自A2時。它解析頭文件中的所有其他cookie,從A2罰款,它只是不能解析用戶的會話cookie由於某種原因,但它可以很好,如果請求來自A1

我已經使用了tcpdump,並且對它們中的每一個都採用了pcap,並對它們進行了區分,並且頭文件中沒有任何內容看起來特別不同。

我發現這個堆棧溢出的問題,人們說這是因爲他的cookie頭字符串太長:What could cause cookie to not be set in $_COOKIE when it's in $_SERVER我不認爲這太長,因爲我的只有249個字符長,在成功和失敗的情況下。

我在考慮從$ _SERVER中取出cookie並手動解析它們,但這聽起來很蠢,我寧願找出潛在的問題。

+0

在A1和A2服務器上是否爲用戶設置了會話?會話數據是如何在服務器上創建的?他們是同一臺機器嗎? – voncox

回答

0

PHP在這裏沒有錯。

我們正在使用Kohana,它有一些代碼在初始化時運行,以嘗試向會話cookie添加額外的安全性。相關代碼驗證了服務器端會話中記錄的IP地址與請求標頭中發送的IP地址相匹配。

由於我們的網絡配置,我在聯繫服務器B時總是收到外部IP,聯繫A2時收到內部IP,聯繫A1時收到外部IP。

當A2轉發請求與內部IP給B,它引發的Kohana基於IP的cookie的保護餅乾與我的外部IP創建,但現在正試圖通過我的內部IP使用。

0

使用IE < = 8的一個問題是P3P。我發現,掉落在P3P頭成接受你的AJAX/JSON請求(在您的實例的服務器B)頁面會解決這個問題:

header('P3P: CP="NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM"'); 

至於server A2不發送$_COOKIE請求server B,我會建議使用_GET將請求發送到server B上的某種init頁面。這樣它可以被處理,並存儲在server B。然後,對於必須出現此信息的所有剩餘頁面,您可以查看server B以確定信息是否已發送,或者將_GET數據連續發送至每個頁面,並將其與現有信息進行比較。提醒一下,這個信息應該被嚴格監控,因爲修改起來要容易得多。

我很抱歉,我意識到這不能解決問題,但可以提供一種替代解決方案。

+1

這發生在所有瀏覽器中,而不僅僅是IE。我認爲一個解決方法是手動解析$ _SERVER ['HTTP_COOKIE_VARS'],只有當請求被A2轉發時,但我更願意找到潛在的問題 – ashgromnies

+0

P3P頭部更改不起作用的另一個原因是因爲我們'在這種情況下重新運行是IE的XDomainRequest對象的限制。它*根本不支持cookies。它被打破了,所以我們必須做代理。 – ashgromnies

0

前段時間,我不得不做cross-domain ajax請求。很顯然,當我嘗試使用IE設置標題爲「允許x域ajax」(不記得確切的標題名稱)時,我遇到了同樣的問題。

我這樣做是爲了在服務器的ajax之間使用CURL。因此,通過這種方式,我的ajax腳本(用PHP編寫)能夠通過JSON + CURL通過服務器交換數據,通過執行CURL POST發送數據並通過CURL GET進行數據回放,而不管涉及哪些域。

請原諒,也許這不完全是你需要的答案,但是,國際海事組織,這可以幫助尋找跨站點ajax的人。

0

在服務器之間使用GET;就這樣。並建立散列方式,以便如果服務器未能完成請求,用戶看不到實際的cookie內容被拉動

相關問題