2014-02-07 44 views
0

我在兩臺Ubuntu服務器虛擬機上使用PHP 5.4.9在雲中託管了許多不同的域/子域,這意味着許多頁面意味着大量的Windows Azure和Magento Enterprise從大量機器人爬行。 70%的流量必須是漫遊爬行。使用PHP獲取重複session_id

幾周前我們開始有一個奇怪的問題,用戶開始看到其他用戶的帳戶。我們激活會話驗證(檢查IP /用戶代理)。如果會話不匹配,則使用新的session_id重定向到主頁。

在任何時候我們有50k的會話被存儲(機器人會話只有2分鐘),96%是機器人會話。

由於某些未知原因,我們正在獲取已提供給其他用戶或bot的會話,我們沒有更改與會話相關的Magento代碼,PHP是生成session_id的代碼。會話存儲在Redis中,但我們嘗試將它們存儲在MySQL和具有相同問題的文件中。

任何想法是值得歡迎的。

+0

當你檢查IP /用戶代理,你檢查數據庫而不是PHP會話對象? – developerwjk

+0

IP /用戶代理將存儲在每個會話中,並與每個請求進行比較 – zzarbi

+0

@zzarbi您能找出造成這種情況的根本原因嗎?我面臨着類似的問題。 – gaurav

回答

0

如果你在使用Redis和Magento,那麼你需要啓用Cm_Redis模塊。它包含在CE1.8和EE1.13中,但您需要爲早期版本下載它。

如果您使用低於1.13的EE,請嘗試使用Collin Mollenhour(Cm_RedisSession中的CM)模塊。

https://github.com/colinmollenhour/Cm_RedisSession

我意識到,你似乎有或無的Redis,但如果你有會話問題的唯一地方是Magento的話,好像就像你有一個配置問題存在有問題。通過此模塊啓用Redis可能會有所幫助。

+0

我使用這個模塊,也安裝了php redis擴展。這並沒有解決問題。 – zzarbi

0

就我而言,最終並不是redis。基本上嘗試檢查所有的PHP請求(包括ajax的)頭,並嘗試找出有問題的會話cookie請求標頭值與響應頭cookie值不同。

注意:在登錄/註冊請求的情況下,此行爲沒有問題。除此之外,它不應該發生(在我的情況下captha請求是錯誤的)。