關於Shiro的退出請求是如何關聯到登入請求的思考

2021-09-25 10:58:36 字數 2375 閱讀 1502

先給出結論,是因為本身是很簡單的道理。假設我們沒有使用任何認證授權的框架,就簡單的使用cookie和httpsession,那麼使用者登入後的每乙個請求是如何關聯上這個使用者的呢?答案很簡單,由於每個請求tomcat使用乙個單獨執行緒來處理,但是http請求時是有cookie的,那麼一般來說是在cookie中加入sessionid,後台服務根據sessionid去查詢httpsession,這樣就可以關聯起來了。這本是很基礎的內容,為什麼在使用shiro的時候還有這個疑問呢?

起初我的認知:

shiro為每乙個使用者建立了乙個subject(這個實際並不是每乙個使用者,只是之前是這樣認為的),這個subject是使用threadlocal繫結的。

shiro的退出是直接使用的subject.logout()方法,也可以通過subject獲取session、token等認證授權資訊。

以上兩點是我之前對shiro有的認知,所以我以為乙個使用者登入之後會有乙個subject。因此我就發現這裡就有乙個疑問的地方,如果乙個使用者乙個subject,那subject又是和執行緒繫結的,使用者每乙個請求都是乙個單獨的執行緒,那麼使用者的請求是如何與登入請求關聯上獲取到同乙個subject的呢?

這裡就直接開始的跟蹤原始碼分析,首先我想的是檢視獲取subject相關的原始碼,跟蹤到threadcontext類中關鍵**,兩部分

public static subject getsubject() 

public static object get(object key)

object value = getvalue(key);

if ((value != null) && log.istraceenabled())

return value;

}//這裡是最終獲取到subject的地方,resource為inheritablethreadlocalmap物件

private static object getvalue(object key)

另外乙個地方

private static final logger log = logge***ctory.getlogger(threadcontext.class);

public static final string security_manager_key = threadcontext.class.getname() + "_security_manager_key";

public static final string subject_key = threadcontext.class.getname() + "_subject_key";

private static final threadlocal> resources = new inheritablethreadlocalmap>();

可以看到,subject確實是從inheritablethreadlocalmap物件中取出來的。但是為什麼是inheritablethreadlocalmap,這樣的話,子執行緒是**產生的?

然後從shiro裡層的過濾器開始跟蹤**,發現在abstractshirofilterdofilterinternal方法中有關鍵**:

try 

});} catch (executionexception ex) catch (throwable throwable)

在這裡可以知道了,這裡是另起執行緒來處理之後的事情。並且subject是每一次請求都會建立乙個,那麼請求之間的subject是如何關聯起來的呢?跟蹤createsubject方法,找到關鍵**defaultsecuritymanagercreatesubject方法

public subject createsubject(subjectcontext subjectcontext)
在這個**之前還有一些處理,主要的包括,將request和response物件放入之前的inheritablethreadlocalmap物件中。這裡的**主要是將securitymanage例項、session物件以及登入之後的認證資訊principals存入subjectcontext。然後在docreatesubject方法中將這些內容都賦值給subject。這樣,雖然每一次請求都是乙個新的subject,但是subject裡面的內容都是一致的。最後在subject.logout()方法中,刪除掉session即可實現退出功能。

Kafka 請求是怎麼被處理的

kafka broker 端處理請求的全流程 1.順序處理請求。while true 這個方法吞吐量太差,只適用於請求傳送非常不頻繁的系統。每個請求使用單獨執行緒處理。為每個入站請求都建立乙個新的執行緒來非同步處理。while true thread.start 該方法為每個請求都建立執行緒的做法開...

關於shiro的猜測

記錄一下自己的猜測,等到有能力閱讀原始碼的時候,再驗證一下猜測是否成立 最近研究了一下shiro整合jwt,上網查了一些資料,寫了乙個簡單的實驗專案。我使用的測試工具是postman,之前在沒有整合jwt之前,我發現如果不登入的情況下直接訪問授權資源是不被允許的,後來我嘗試著在登入之後,改掉post...

如何退出 如何面對退出時的糾結。。。

錢兒爸說 這學期開學,雖然只有短短幾個星期的時間,但是我已經明顯感覺出錢兒時間不夠用了,他放學的時間晚了一小時,學校裡課程的科目和種類明顯多了,作業也多了,學校的要求也多了,包括各種活動也多了,這直接導致乙個問題,課外課的取捨。熟悉我們的朋友都知道,錢兒學花滑,一周差不多四到五次,每次光去冰場來回也...