XX系統(tǒng)登錄之后，偶爾在用戶那會出現(xiàn)這個(gè)現(xiàn)象：
 
登錄的邏輯是這樣的：登陸主界面之后，在主界面html執(zhí)行到最后的時(shí)候，使用windows.open打開一個(gè)彈出窗口，去服務(wù)器取一些需要的數(shù)據(jù)。
但是偶爾用戶那會出現(xiàn)彈出窗口又定位到登陸窗口了（summer中使用filter對請求過濾，發(fā)現(xiàn)沒有登陸的話會重新定位到登陸窗口）。
這里明明是的剛登陸的程序，卻出現(xiàn)沒有登陸的現(xiàn)象。。這個(gè)現(xiàn)象在用戶那一直就存在，一直也沒找到原因。
今天在和三期應(yīng)服推廣人員的溝通中無意了解到，用戶習(xí)慣使用給登陸界面建立一個(gè)桌面快捷方式，一般操作如下：
在ie地址欄輸入“http://localhost:8080/spxt”，這個(gè)時(shí)候請求完成之后定位到了登陸頁面，但是ie地址欄已經(jīng)變成
“http://localhost:8080/spxt/common/summer/jsp/login/register03.jsp;jsessionid=CA0CA7E455535994E523B01357B42214”
此時(shí)直接在這個(gè)ie窗口登陸是沒有問題的。而用戶一般都是在這個(gè)頁面點(diǎn)右鍵，選擇創(chuàng)建快捷方式，
這個(gè)時(shí)候就有一個(gè)問題，用戶的快捷方式超鏈接實(shí)際上指向的是后面那個(gè)帶有jsessionid的很長很長的url。
如果此時(shí)從桌面點(diǎn)擊這個(gè)超鏈接的快捷方式打開ie進(jìn)行登陸，就很容易復(fù)現(xiàn)文章開始的那個(gè)截圖現(xiàn)象了，如果我修改快捷方式屬性，把超鏈接的
sessionid去掉就沒有問題了。（這里描述不是很準(zhǔn)確，比如重啟一次tomcat的話就又不會復(fù)現(xiàn)了）。
后來在后臺打印每次使用的sessionid，發(fā)現(xiàn)如果從快捷方式登陸的話，真正的登錄session就是jsessionid所代表的那個(gè)session，而后來ajax
請求的是和服務(wù)器新建了連接，發(fā)現(xiàn)session沒有登陸信息就定位到登陸頁面了。

這里在服務(wù)器端“可能”是產(chǎn)生兩個(gè)session的概念：一個(gè)是本次真正登錄的session；另外是一個(gè)空的session。而在ajax異步請求的時(shí)候，
實(shí)際上用的就是后面這個(gè)空的session，這樣發(fā)現(xiàn)沒有登陸就重新定位到登陸頁面了？

后面原因的分析完全是自己的猜測，具體望大家指教一下：）

解決問題可以這樣：1、幫用戶把那個(gè)快捷方式的jsessionid去掉。
                  2、寫一個(gè)filter，對于是登陸請求的，把jsessionid去掉。

ps：以上問題對于收藏夾存在同樣問題。


看了帖子終于明白jsessionid是怎么來的了~多謝
在struts的org.apache.struts.action.RequestProcessor.processForwardConfig()中找到了如下代碼：
response.sendRedirect(response.encodeRedirectURL(uri));
不過感覺一般情況還是不要去掉jsessionid比較好，對于特殊情況的需要特殊去掉，基本還是利大于弊。