轉載自??禁用Cookie后，Session怎么樣使用

在上篇中更多的是在分析通過Session Cookie這一方式，在每次請求時都將

sessionId以Cookie的形式發到服務端，來保持一致。這也是許多人印象中的

Session在瀏覽器關閉之后就失效這一說法的來源。

其實本質上是瀏覽器在關閉之后，應用對應的SessionCookie被清除了，再次打開瀏覽器請求應用時，之前的SessionId對應的Cookie不存在，所以就會重新創建一個Session。而服務端原來的Session其實還是存在的，只是沒人與之對應，就默默的等著超時時間一到，被清除了。

而對于Cookie，我們都知道其是瀏覽器保存客戶端本地的，安全問題暫且不說，但Cookie是可以在瀏覽器中配置后關閉的。關閉之后，服務器就不能再向瀏覽器寫Cookie的，此時我們基于SessionCookie的實現方式就遇到了問題。

雖然每一次仍然通過response將Set-Cookie添加到header里，但發到瀏覽器的時候，不能再寫Cookie，后續的請求依然是重新發一個sessionId為null的請求，導致每次仍是重新創建session對象，并沒有解決交互狀態的問題。

為了解決這個問題，服務器提供了另外一種方式：

URL重寫，即英文的URLrewrite。

這一方式，其本質上是在每次請求的url后面append 上一個類似于jsessionid=xxxx這樣的參數，在服務端解析時，獲取到jsessionid對應的值，并根據其獲取到對應的Session對象，從而保證了交互狀態一致。

一句話就說明白了。

但這一句話背后，有一些事情還是需要注意的，

例如，我們可以自己在url后面寫上jsessionid=當前session的id值。這種類似于硬編碼，因為服務端獲取這個session的id是通過jsessionid這個參數名來獲取的，而這個參數我們在前一篇文章中了解到，是可以配置的，當改了之后，后面的sessionId就獲取不到了。

其次，為了保證各類url規則的一致，服務端提供了response API來處理，只需要直接使用，就可以完成jsessionid的參數追加。

我們看代碼中的實現邏輯：

/*** Return <code>true</code> if the specified URL should be encoded with* a session identifier. This will be true if all of the following* conditions are met:* <ul>* <li>The request we are responding to asked for a valid session* <li>The requested session ID was not received via a cookie* <li>The specified URL points back to somewhere within the web* application that is responding to this request* </ul>** @param location Absolute URL to be validated*/ protected boolean isEncodeable(final String location) {if (location == null) {return (false);}// Is this an intra-document reference?if (location.startsWith("#")) {return (false);}// Are we in a valid session that is not using cookies?final Request hreq = request;final Session session = hreq.getSessionInternal(false);if (session == null) {return (false);}if (hreq.isRequestedSessionIdFromCookie()) {return (false);}// Is URL encoding permittedif (!hreq.getServletContext().getEffectiveSessionTrackingModes().contains(SessionTrackingMode.URL)) {return false;}return doIsEncodeable(hreq, session, location);}

代碼中會根據是否使用SessionCookie來決定是否要繼續，

之后會繼承判斷可使用的Session tracking Mode里都有哪些，是否包含URL。

在doIsEncodeable方法中，最終實現是這一行代碼

String tok = ";" +SessionConfig.getSessionUriParamName(request.getContext()) +"=" + session.getIdInternal();

也就是我們上面提到的硬編碼jsessionid到url后面不太好的原因，這里就是在讀取它的配置。

public static String getSessionUriParamName(Context context) {String result = getConfiguredSessionCookieName(context);if (result == null) {result = DEFAULT_SESSION_PARAMETER_NAME;}return result;}

另外，我們上面提到的Session tracking Mode，是在Tomcat啟動的時候判斷的，而服務端并不可能得知以后要連接的瀏覽器中，哪些是不允許Cookie的，所以對于Sesion tracking mode,URL無論如何都是可以使用的，而Session cookie是否要使用，是通過在Context組件中配置的其cookies屬性為false時禁止的

private void populateSessionTrackingModes() {

// URL re-writing is always enabled by default

defaultSessionTrackingModes = EnumSet.of(SessionTrackingMode.URL);

supportedSessionTrackingModes = EnumSet.of(SessionTrackingMode.URL);

if (context.getCookies())?{ //此處讀取Context組件的cookies配置，如果為false，則不使用SessionCookie

defaultSessionTrackingModes.add(SessionTrackingMode.COOKIE);

supportedSessionTrackingModes.add(SessionTrackingMode.COOKIE);?}

?

總結下，即為了防止客戶端禁用Cookie導致的Session狀態不一致的情況，我們可以采用UrlRewrite的方式來保證。

這一過程，我們可以使用response的encodeURL方法來使sessionid添加到url后面，不過是需要先在Context組件中聲明不使用cookies。

?

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的禁用Cookie后，Session怎么样使用的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。