xx系統登入之後，偶爾在使用者那會出現這個現象：
登入的邏輯是這樣的：
登陸主介面之後，在主介面html執行到最後的時候，使用
windows.open開啟乙個彈出視窗，去
伺服器取一些需要的
資料。但是偶爾使用者那會出現彈出視窗又定位到登陸視窗了（
summer中使用filter對請求過濾，發現沒有登陸的話會重新定位到登陸視窗）。
這裡明明是的剛登陸的程式，卻出現沒有登陸的現象。。這個現象在使用者那一直就存在，一直也沒找到原因。
今天在和三期應服推廣人員的溝通中無意了解到，使用者習慣使用給登陸介面建立乙個桌面快捷方式，一般操作如下：
在ie位址列輸入「http://localhost:8080/spxt」，這個時候請求完成之後定位到了登陸
頁面，但是ie位址列已經變成
此時直接在這個ie視窗登陸是沒有
問題的。而使用者一般都是在這個頁面點右鍵，選擇建立快捷方式，
這個時候就有乙個問題，使用者的快捷方式超
鏈結實際上指向的是後面那個帶有jsessionid的很長很長的url。
sessionid去掉就沒有問題了。（這裡描述不是很準確，比如重啟一次tomcat的話就又不會復現了）。
後來在後台列印每次使用的sessionid，發現如果從快捷方式登陸的話，真正的登入session就是jsessionid所代表的那個session，而後來ajax
請求的是和伺服器新建了連線，發現session沒有登陸資訊就定位到登陸頁面了。
這裡在伺服器端「可能」是產生兩個session的概念：乙個是本次真正登入的session；另外是乙個空的session。而在ajax非同步請求的時候，
實際上用的就是後面這個空的session，這樣發現沒有登陸就重新定位到登陸頁面了？
解決問題可以這樣：1、幫使用者把那個快捷方式的jsessionid去掉。
2、寫乙個filter，對於是登陸請求的，把jsessionid去掉。
ps：以上問題對於收藏夾存在同樣問題。
看了帖子終於明白jsessionid是怎麼來的了~多謝
在struts的org.apache.struts.action.requestprocessor.processforwardconfig()中找到了如下**：
response.sendredirect(response.encoderedirecturl(uri));
不過感覺一般情況還是不要去掉jsessionid比較好，對於特殊情況的需要特殊去掉，基本還是利大於弊。
url中的jsessionid解釋
jessionid通過這樣的方式來從客戶端傳遞到伺服器端,從而來標識session。注意一點，jsessionid跟一般的url引數傳遞方式是不同的，不是作為引數跟在 後面，而是緊跟在url後面用 來分隔。這樣在使用者禁用cookie的時候我們也可以傳遞jsessionid來使用session了，只...
url中的jsessionid所引起的問題和解決
jsessionid所引起的問題 jsessionid considered harmful cookie和會話狀態的工作原理及cookie欺騙 cookie,會話狀態,cookie欺騙 jsessionid的危害及去除解決方案,原文 其實就是加個filter擷取所有url並進行重寫 然後是web....
python中引包機制
python從下面3個路徑引包，比如引包 import a 1.首先從當前目前下查詢是否有 a.py 檔案，2.到pyhton安裝目錄 c python36 lib 下面去找是否有 a.py 檔案,3.最後到環境變數sys.path下面去找。1.test.py檔案中呼叫cls a.py檔案中的方法 ...